Code review guardrails for GitHub Copilot

Use this when

You want Copilot to review a change set with a higher signal-to-noise ratio — especially when repository instructions or path-specific instructions already exist and you want the review held against them rather than against generic best practice.

It applies both to Copilot Chat review and to Copilot's automated pull-request review, which reads the same instruction files.

The problem: an ignored reviewer is worse than none

Automated review has one failure mode that matters, and it isn't missing bugs. It's producing enough low-value comments that people stop reading. Once a team has learned to scroll past the bot, the two real findings it produces per month scroll past too — and the PR now carries a green check that means nothing.

So the goal is not "find more". It's precision: fewer comments, each one worth reading.

Review brief

Paste this into Copilot Chat before asking for a review:

Review these changes for behavior regressions, incorrect assumptions, missing tests, and places where the diff violates repository instructions. Ignore cosmetic style unless it hides a real maintenance risk.

For each finding, give: the file and line, the concrete failure mode (specific inputs or state → wrong result), and the smallest useful fix. If you cannot describe a concrete failure, don't report it.

Before reporting, check whether each issue is already handled — by a guard clause, the type system, framework validation, or an existing test. Read the test rather than assuming it exists.

Also tell me what this diff removed. A deleted check is the highest-risk thing a change can contain.

Follow-up prompts

Run these as separate turns. They're where most of the value is — the first review is a draft.

1. Which findings are most likely to cause production bugs? Rank them.
2. Which findings are only style or preference, and can be ignored?
3. Which repo instruction or local convention does each finding rely on? Quote it.
4. What is the most important missing test?
5. For your top finding, write the strongest argument that it is NOT a bug. Then decide.
6. What did this diff remove or weaken?

Prompt 3 is the sharpest tool here: a finding that can't name the convention it's enforcing is usually the model's taste rather than your team's rule.

What good output looks like

• File-aware — cites path:line, not "in the auth code"
• Behavior-first — a failure scenario, not a quality adjective
• Severity-ordered — the thing that will page someone is first
• Explicit about uncertainty — "I could not find the caller; if X is reachable from an unauthenticated route, this is high severity"
• Grounded in your rules — quotes the instruction it's applying

What bad output looks like

• Generic praise ("nice refactor!")
• Style nitpicks with no user impact
• "Could be improved" / "consider extracting" with no failure case
• Findings that restate the diff back at you
• Suggestions the repository instructions explicitly contradict
• Confident claims about code it didn't open

Make it stick: put the rules in the repo

Chat prompts are per-session; instruction files apply to every review including the automated ones. In .github/copilot-instructions.md:

## Code review

Report only findings with a concrete failure mode: specific inputs or state producing
a wrong result, a crash, a data loss, or a security consequence.

Do not report:
- style the linter already enforces
- naming preferences
- "consider extracting" suggestions with no stated problem
- missing tests, unless the untested path is actually wrong

Before reporting, verify the issue is not already handled upstream, and check
whether an existing test covers it — read the test, do not assume.

Always report anything the diff removed or weakened: a deleted check, a loosened
type, a widened permission, a disabled test.

Path-scoped rules go in .github/instructions/*.instructions.md with an applyTo glob, so your front-end conventions aren't in context while it reviews a migration.

Tuning it over a sprint

Treat the reviewer as something you calibrate, not something you install:

1. Turn it on for one repository.
2. For two weeks, keep a tally: comments that changed the PR vs comments that didn't.
3. Every comment in the "didn't" column is a rule for the instructions file — usually a don't.
4. Only once the hit rate is respectable should it become a required reviewer. Making a noisy bot mandatory is how teams learn to rubber-stamp.

Failure modes

• It reviews the whole file, not the change. Scope it: "only issues introduced or exposed by this diff."
• It flags framework-handled concerns. Add one line to the instructions naming your stack's guarantees — parameterized queries, model validation, automatic escaping.
• Findings are vague on large PRs. Review quality falls off with diff size. Split the PR; this is good advice independent of the tooling.
• It contradicts the repo instructions. Attach them explicitly as references in the chat, and ask prompt 3 — a finding that can't cite a rule usually shouldn't exist.
• Nothing found, on a risky change. Ask a targeted question instead of a general one: "walk the authorization check for this endpoint from request to query."

Why it works

Copilot can produce genuinely useful review feedback, but only if the target is narrow. Left broad, it optimizes for looking thorough — and thoroughness is exactly the wrong objective for a reviewer whose comments compete for a human's attention.