Verified against GitHub Copilot · 2026-07-23
Configure separate Copilot instructions for commit messages, PR descriptions, reviews, and tests
A VS Code settings.json block wiring distinct instruction sets for commit-message generation, pull-request-description generation, code review, and test generation, so each of Copilot's task-specific generators gets rules suited to what it is actually producing instead of inheriting one general-purpose file uniformly.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Add task-specific Copilot instructions to .vscode/settings.json, one block per generation task, instead of relying on .github/copilot-instructions.md to cover all of them at once — that file is added to every request regardless of what kind of task it is, so a rule that only makes sense for a commit message competes for attention on a totally unrelated code-review pass, and vice versa. SCOPE Workspace settings, checked into .vscode/settings.json so every collaborator on this repo gets the same rules automatically. COMMIT MESSAGE GENERATION Subject line under 72 characters, imperative mood, states the user-facing effect of the change, never the mechanism. PULL REQUEST DESCRIPTION GENERATION Open with the affected user-facing behavior before any implementation detail; always include a manual test-plan checklist. TEST GENERATION Default to Vitest; always include at least one edge-case test per generated function, never only the happy path. CODE REVIEW Weight authorization checks and input validation above stylistic concerns on every reviewed diff. PRODUCE A settings.json fragment with a separate instructions array for each of the four generation settings above, each entry either the literal text or a 'file:' reference to a markdown file under the repo, whichever keeps the rule closer to where it will actually be read and maintained. For any rule long enough to need examples or a bulleted list, prefer a 'file:' reference over an inline string — a long inline instruction string in settings.json is unreadable in a diff and invites someone to edit it sloppily under time pressure. CONSTRAINTS - Do not repeat a rule that already exists in .github/copilot-instructions.md unless the task-specific version is meaningfully different for this generation task — a rule about variable naming belongs in the general file; a rule about how PR descriptions should open with the affected user-facing behavior before any implementation detail belongs only here, because it is not true of every Copilot interaction, only this specific generation task. - If Workspace settings, checked into .vscode/settings.json so every collaborator on this repo gets the same rules automatically. is workspace-level settings checked into the repo, confirm every rule is genuinely team-wide and does not encode one person's personal preference the rest of the team never agreed to — a workspace setting applies to every collaborator who opens this repo, unlike a user-level setting that stays personal. - Flag any rule here that assumes information Copilot cannot actually see for that generation task — for example, a commit-message rule referencing a linked ticket number only works if that ticket ID is actually present in the branch name, the staged diff, or a co-located file Copilot can read; do not write a rule assuming context that has no path into the model's input. OUTPUT The complete settings.json fragment, plus one line per section noting whether the instructions are inline or point to a file, and why.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Copilot exposes commit-message, pull-request-description, test-generation, and code-review instructions as genuinely separate settings, distinct from the repo-wide copilot-instructions.md that is added to every request regardless of task — splitting rules across them this way matters because a rule crammed into the general file for one specific generation task competes for the model's attention on every unrelated request too, diluting the signal on the requests it was actually written for while adding noise everywhere else. The choice between an inline instruction string and a 'file:' reference is not a style preference but a maintainability one grounded in what settings.json actually looks like in a diff — a long inline string reviewed as a single-line JSON value gives a reviewer almost nothing to check a change against, while a referenced markdown file diffs the same way any other prose document does, line by line, which is the difference between a rule someone can actually review being edited and a rule someone approves editing sight-unseen because reading it in that format is unpleasant enough that nobody does. The workspace-versus-user-level distinction has real teeth: a workspace setting checked into the repo is inherited by every collaborator the moment they open it, so a rule encoding one person's personal taste rather than a genuine team agreement becomes something the whole team is opted into without having agreed to it, which is a materially different mistake than the same preference living harmlessly in that one person's own user settings. Flagging rules that assume information a given generation task cannot actually see targets a specific and easy mistake: each of these four generation settings receives a different slice of context by design — a commit-message generator sees the staged diff, a PR-description generator typically sees the fuller set of commits and the diff against the target branch — so a rule written assuming a ticket ID will be visible is only reliable if that ID is actually reachable from what that specific generation task is given, not from what a human happens to know while writing the rule.
Verified against
GitHub Copilot VS Code Copilot Chat 1.270, task-specific generation settings · 2026-07-23
Changelog
- 2026-07-23 — Initial publish, verified against VS Code Copilot Chat 1.270 task-specific generation instructions.
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
