Verified against GitHub Copilot Workspace · 2026-07-10
Turn a GitHub issue into an editable plan before Copilot Workspace writes code
A Copilot Workspace brief that forces a reviewable specification and step-by-step plan from an issue before any code gets generated, so a wrong approach gets caught before it becomes a PR.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Open this issue in Copilot Workspace and generate a spec and plan first — do not let Workspace proceed to the implementation step until the spec below has been reviewed and approved. ISSUE Users on the free tier can currently export more than 3 reports per month by editing the request payload directly. ACCEPTANCE CRITERIA 1. Free-tier requests past the 3rd export in a rolling 30 days return a 403 with a clear error message. 2. Paid tiers are unaffected. 3. The limit is configurable, not hardcoded. CONSTRAINTS Must use the existing rate-limit middleware in lib/middleware/rate-limit.ts, not a new library. OUT OF SCOPE Billing-plan changes, upgrade prompts in the UI, and retroactive enforcement on exports already made this month. When Workspace proposes the spec, check that it names every file it intends to touch, explains its approach in plain language before any diff appears, and flags anywhere the acceptance criteria above are ambiguous rather than silently picking an interpretation. Only advance to the plan step once the spec accurately reflects this issue, and only advance to code once the plan's steps map one-to-one onto the acceptance criteria above.
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Copilot Workspace's entire design is spec, then plan, then implementation as three separate, individually editable steps rather than issue-in, PR-out in one shot — the point of the tool is to let a human validate the spec and the plan before a single line of code is written. An issue that never separates what must be true (acceptance criteria) from what must not change (constraints and out-of-scope) gives Workspace nothing to slow down for, so it collapses those steps back toward one pass, generating a spec that just restates the issue title with more words. Naming acceptance criteria and out-of-scope explicitly gives the spec stage concrete claims to check itself against instead of a paraphrase. Telling it to flag ambiguity in the spec rather than guess counters the tendency of any spec-generation step to quietly resolve an unclear requirement with whichever reading is easiest to implement — and because the spec is the artifact you review before plan or code exist, an ambiguity surfaced here costs a comment, not a wasted PR.
What you get back
Spec (excerpt): Add a rolling 30-day export counter per free-tier user, checked in the existing rate-limit middleware before the export handler runs. Files to touch: lib/middleware/rate-limit.ts (add export-count check), lib/config/limits.ts (new configurable EXPORT_LIMIT_FREE_TIER constant), app/api/reports/export/route.ts (surface the 403 with the specified error message). Flagged ambiguity: acceptance criteria 3 says configurable — assuming this means an environment-variable-backed constant, not a per-user database override, since no admin UI was mentioned. Confirm before proceeding to plan.
Verified against
GitHub Copilot Workspace GA, 2026 · 2026-07-10
Changelog
- 2026-07-10 — Initial publish, verified against GitHub Copilot Workspace GA.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
