BoilerPrompt

GitHub Copilot Prompts That Actually Work: Inline Chat, Edits, and @workspace

By Sidhant Sinha on

Most GitHub Copilot prompt collections are recycled Cursor prompts with the tool name swapped. They fail for a structural reason: Copilot Chat and Copilot Edits are file-scoped. Claude Code is a terminal agent that reads your repo and runs commands. Cursor Agent mode searches your codebase from inside the editor. Copilot, in its main chat surfaces, works from the context you put in front of it: the current file, your selection, and the references you attach. Prompt it like an autonomous agent and you get confident answers about files it has never seen.

That constraint is not a weakness once you prompt for it. It just means every Copilot prompt has a second job: deciding what Copilot gets to see.

How Copilot builds context

Before patterns, mechanics. In VS Code, Copilot Chat draws on:

  • The active file and your current selection
  • Files you reference explicitly with #file
  • The working set of files you add in Copilot Edits
  • The @workspace participant, which searches an index of your repo to answer questions

What it does not do by default is walk your repository the way a terminal agent does. There is no implicit "read the router, then check the middleware, then look at the tests." If a file matters to the task and it is not open, referenced, or in the working set, assume Copilot cannot see it.

This is why the general rule for prompting agentic IDE tools, short direct prompts with concrete constraints and a verification step, applies to Copilot with one addition: name your context. The best Copilot prompts spend their first line establishing scope, and every line after that on constraints.

Inline chat: single-file edits on a selection

Inline chat, the prompt box you open directly on selected code, is the highest-precision surface Copilot has. The selection does the context work, so the prompt can be short and dense: name the change, state what must not change, define done.

Extract the retry loop in this selection into a helper called
fetchWithRetry(url, options, maxAttempts). Keep the backoff
timing exactly as written. Put the helper at the bottom of
this file, not in a new file. Do not change the exported
function's signature or its error messages, existing tests
assert on both. When done, summarize the change in one
sentence so I can check it against the diff.

Notice what the prompt is not doing. It is not explaining the codebase, not pasting the function back in, not asking for three options. The selection is the context. The words are all constraints.

Two rules of thumb for inline chat:

  • If your prompt describes code you did not select, stop and select it instead.
  • If the change spans more than the file you are in, you are on the wrong surface. Move to Edits.

Copilot Edits: multi-file changes with an explicit working set

Copilot Edits is where multi-file work belongs. You add files to the working set, and Copilot proposes coordinated edits across them. The working set is the whole trick: it is you doing the repo navigation that an autonomous agent would do for itself.

A good Edits prompt has three parts: the change in one sentence, expectations per file, and a verification request.

I have added client.ts, types.ts, and useProjects.ts to the
working set. Add request cancellation to the API client.

- client.ts: every request method accepts an optional
  AbortSignal and passes it through to fetch
- types.ts: extend RequestOptions with signal?: AbortSignal
- useProjects.ts: create an AbortController inside the
  effect, pass its signal to the client call, abort in the
  cleanup function

Do not change error handling except to swallow AbortError.
When you finish, list each file with a one-line summary of
what changed, and name the existing test file that covers
useProjects so I can run it.

Per-file expectations matter because Edits is coordinating, not exploring. If you only say "add request cancellation," Copilot has to guess how the change distributes across three files, and it will guess differently than you would. Listing intent per file turns a vague wish into a reviewable diff.

On verification: Copilot Chat and Edits do not run your test suite. Copilot's agent mode can execute tasks, but the standard surfaces produce edits and text, nothing else. So a verification step here means reviewable output: a per-file summary you can check against the diff, and the name of the test command you will run yourself. In Claude Code you would end the same prompt with "run the tests and paste any failures." In Copilot you end it with "tell me exactly what to run."

@workspace: repo questions, not repo edits

@workspace is Copilot's repo-scale surface, and it answers questions by searching an index of your project. It is built for orientation: where does X live, how does Y flow, which files touch Z. It is not an edit surface. Ask it to refactor across the repo and you get prose about refactoring, not diffs.

Prompt it like a grep with judgment: describe what you are looking for in concrete code terms, and always ask for file paths.

@workspace Where is user session validation implemented?
I am looking for three things: the middleware or guard that
checks the session cookie, the file where the session type
is defined, and any routes that opt out of auth. List file
paths with a one-line description for each. If validation
happens in more than one place, flag it, because it
probably should not.

Asking for paths keeps @workspace honest. A path either exists or it does not, and you can open it in seconds. Prose summaries without paths are where hallucinated architecture hides.

The failure mode: prompting like Copilot can see your repo

Here is the prompt behind most "Copilot is useless" complaints, typed into the chat panel with one file open:

Update all our API endpoints to use the new auth middleware

What happens next is predictable. Copilot edits the one file it can see, or it invents route file names from framework conventions and writes plausible code for files that do not exist. The prompt assumed repo vision the surface does not have. The same prompt would work in an autonomous agent like Windsurf precisely because that agent goes looking for the endpoints first.

In Copilot, the fix is a two-step: find with @workspace, change with Edits.

Step one, in chat:

@workspace Which files define Express route handlers that
call requireUser or read req.session directly? List paths
only, no explanations.

Step two, add those files to the Edits working set and prompt the change with per-file intent, the same shape as the cancellation example above. The whole detour costs about a minute, and it replaces guessing with an explicit file list you approved.

This two-step is the single biggest upgrade for engineers coming to Copilot from agentic tools. The search step that Cursor or Claude Code performs silently becomes your job. Doing it explicitly is slower per prompt and faster per task, because you stop discovering missed files at review time.

A checklist before you hit enter

Four questions, in order:

  • Surface: selection-sized change means inline chat, multi-file change means Edits, a question means @workspace.
  • Context: is every file the task touches either open, referenced with #file, or in the working set?
  • Constraints: is there at least one sentence about what must not change?
  • Verification: what output will let you check the work? A per-file summary, a named test command, file paths you can open.

When a Copilot prompt fails, the fix is usually context, not phrasing. Add the missing file before you rewrite the sentence. And keep the prompts short: the 60 to 160 word range that works across agentic IDE tools holds here too, because the files carry the information and the prompt carries the intent.

We keep a set of Copilot prompts built exactly this way, scoped per surface, with constraints and verification steps written in. Browse the GitHub Copilot hub to copy them directly, or grab the same tasks phrased for other tools from the Cursor hub if you work across editors.