GitHub Copilot Code Review: Complete Guide

Copilot code review reads a pull request and comments on it, with suggested fixes you can apply directly. It is the most immediately useful control in this cluster, and the one whose limitations matter most — because a review a team over-trusts changes their behaviour for the worse. They stop looking.

What it is

Copilot reviews a pull request, identifies issues and suggests fixes that can be applied in a couple of clicks. It works across languages and comments from several angles at once — correctness, error handling, clarity, and whatever your instructions tell it to prioritise.

When to reach for it

Not every pull request benefits equally, and knowing which ones do keeps the credit spend and the comment volume proportionate.

Worth a review: changes in areas with a history of mistakes, infrastructure and configuration, anything touching authorisation or data scoping, contributions from someone new to the codebase, and agent-authored pull requests. These are the cases where a mechanical second pass reliably finds something a busy reviewer would have skimmed past.

Rarely worth it: a one-line constant change, a documentation typo, a dependency bump with no code change, or a revert of something reviewed last week. These produce comments without producing information, and they are where the habit of skimming review output gets learned.

Genuinely a judgement call: large refactors. The review will have plenty to say and most of it will be about the mechanical transformation rather than whether the refactor was a good idea, which is the actual question.

Requesting a review

The manual path is one action: open the pull request, add Copilot in the reviewers section, and choose the review effort. The review arrives as comments on the diff, in the same place a colleague’s would.

That placement is worth noticing. The output is not a report in a separate tool — it is pull request comments, which means your existing habits for reading, resolving and arguing with review comments already apply. It also means the output is visible to everyone on the pull request, which is a mild but real incentive to configure it well.

What arrives

The review appears as comments on the diff, with suggested changes you can commit directly where the fix is mechanical. Some comments are questions, some are defects, and the format does not distinguish them — which is why the instructions file above asks for that distinction explicitly.

There is no separate dashboard to check and no report to file. Everything lands where review already happens, which is the design decision that makes the feature easy to adopt and easy to over-trust in equal measure.

Effort levels

Lite is the standard default and is the right choice for most pull requests. Balanced exists for changes where the logic is genuinely intricate, and GitHub notes it consumes more AI credits and may use marginally more GitHub Actions minutes.

What it supports

The limitations panel is the part to read twice. Three of the four are easy to forget in the moment.

Not guaranteed to spot all problems. GitHub says this directly. It is a second pass, not a gate.

Some file types are excluded. Dependency management files, log files and SVG files are not reviewed. Dependency files being excluded is the one that surprises people, since a changed lockfile is exactly the kind of thing worth a look — that check belongs to dependency review, not here.

Content-excluded files are not reviewed. Which means a directory you excluded for confidentiality reasons is also a directory Copilot will not help you review. That is the correct behaviour and it is a trade-off worth making deliberately.

Customizing what it looks for

Out of the box the review is generic. The value comes from telling it what your team actually cares about, and there are five documented mechanisms.

.github/
├── copilot-instructions.md          repository-wide, every review
├── instructions/
│   ├── security.instructions.md     scoped to paths you choose
│   └── terraform.instructions.md
└── skills/
    └── code-review/
        └── SKILL.md                 procedural review knowledge

AGENTS.md                            cross-tool conventions, repo root
Copy

Each answers a different question, and putting content in the wrong one is the usual mistake.

.github/copilot-instructions.md holds rules that apply to every review in the repository. Keep it short — it is carried on every request.

.github/instructions/ holds path-specific rules. A Terraform rule that would be noise on a React component belongs here, targeted at the paths it applies to.

AGENTS.md holds conventions shared across tools rather than review-specific guidance.

.github/skills/ holds procedural knowledge — how this team reviews, in the sense of an ordered process rather than a list of rules.

MCP servers can supply outside context where MCP is configured and the organisation permits it.

Writing instructions that change the output

The instructions that work are specific to your codebase. The ones that do not are the ones that could have been written about any codebase.

When reviewing code:

Prioritise, in order:

1. Correctness
2. Security
3. Error handling
4. Test coverage
5. Backward compatibility

For infrastructure changes, flag:
- IAM permissions broader than the resource requires
- new public network exposure
- hard-coded credentials
- anything that destroys or replaces a stateful resource

Notice what makes that useful: an explicit priority order, and infrastructure rules that name the four things this team has actually been bitten by. Compare with “review for security issues and code quality”, which produces comments that could apply to any repository on GitHub.

Reading the output well

Copilot review comments arrive looking exactly like a colleague’s, and that resemblance is misleading in a specific way.

A colleague’s comment carries an implicit claim: I read this, I understood the surrounding system, and I think this is wrong. A generated comment carries the first part only. It read the diff. Whether it understood what the code is for is not established by the comment being fluent and specific — fluency is the default output, not evidence.

Three habits make the difference between a useful second reader and a source of noise.

Verify before acting. A finding is a claim about the code. Open the line. A confident comment about code that does not do what the comment assumes is common enough to expect, and applying its suggested fix without checking is how a working function acquires a subtle bug with an authoritative-looking commit message.

Separate defects from questions. “This could be a problem if the input is null” deserves five seconds and usually ends there. “This does not release the connection on the error path” deserves a fix. Both arrive in the same voice.

Notice what it does not comment on. Silence is not clearance. GitHub says the review is not guaranteed to spot all problems, and the categories it misses tend to be the ones requiring knowledge of the wider system — which is precisely the knowledge a diff does not contain.

Managing noise

A review that comments on everything gets skimmed, and a skimmed review is worse than no review because it creates the impression of coverage.

Four levers, roughly in order of effect.

Tell it what not to report. The single most effective instruction most teams add. Formatting the formatter owns, preferences without consequences, refactors of code the change did not touch — naming these gives the review somewhere to put the impulse to produce output.

Keep pull requests small. A review of a six-hundred-line diff covers the first part carefully and the rest at a skim, the same failure a human reviewer has, arriving faster.

Prune the instructions file. Rules your linter now enforces are rules the review should stop restating. Instruction files accumulate; nobody prunes them without deciding to.

Use Lite unless the logic warrants otherwise. A higher-reasoning model on a straightforward change produces more commentary, not better commentary.

Where it belongs in the pipeline

The ordering principle: anything deterministic runs first. A linter catches its rule every time; a review catches it usually. Spending review attention on something a tool already enforces is waste, and worse, it dilutes the comments that matter.

A worked instructions set

The abstract advice above, applied to a real service. This is the shape that survives contact with a team.

.github/copilot-instructions.md — short, repository-wide, and mostly about what this codebase has actually got wrong:

# Review guidance

This is a multi-tenant FastAPI service. Every request is scoped to a
tenant, and the most expensive bugs we have shipped were scoping bugs.

## Always check

- Every route under `/api/` uses the `require_tenant` dependency.
- Database sessions come from `with get_session() as session:`.
  Sessions opened outside a context manager have leaked connections
  in production twice.
- Queries that join to another table filter by tenant on both sides.
- Timestamps are timezone-aware.

## Do not report

- Formatting. Ruff owns it.
- Suggestions to refactor code this change did not touch.
- Import ordering.

## Output

Order findings by severity. If a finding is a question rather than a
defect, say so. If there is nothing worth reporting, say that in one
line rather than listing minor observations.

.github/instructions/terraform.instructions.md — narrower, and only loaded for the paths it targets:

For Terraform changes, flag:

- IAM policies granting broader permissions than the resource needs,
  and any use of `"*"` in an action or resource.
- Security group rules opening a port to 0.0.0.0/0.
- Resources missing the tags defined in `infra/modules/tags`.
- Any plan-affecting change that replaces a stateful resource —
  databases, volumes, stateful sets. Say what is lost.
- Module sources pinned to a branch rather than a tag.

Two things make these work. The repository file explains why for its rules, which lets the review generalise to variants nobody wrote down. The Terraform file is scoped, so a front-end pull request never carries it.

Verifying it works

An instructions file that has never been tested is a hope. Testing one takes ten minutes.

Write a change that violates a rule. Open a database session outside a context manager. Add an IAM policy with a wildcard action.

Request a review, and count. Did it flag the thing you planted? If not, the rule is not landing — usually because it is too abstract, or the file is too long, or it is in a path-specific file that does not target the path you edited.

Then run it on a clean change. The correct output is close to nothing. If a clean change produces a page of comments, you have a noise problem to fix before anyone forms a habit of ignoring the review.

Keep both changes. A tiny branch containing one planted defect and one clean change is a regression test for your review configuration, and it costs seconds to re-run after editing the instructions.

Security review, specifically

Copilot review is often adopted with security in mind, and it repays being explicit about what that can and cannot mean.

It is genuinely good at pattern-shaped security issues visible in a diff: a query built by string concatenation, a missing authorisation dependency, a credential in a config file, an overly broad IAM action, a bare except swallowing an error path. These are exactly the things that are tedious for a human to check on every pull request and easy for a pattern matcher to catch every time.

It is structurally unable to catch several categories that matter more.

Design-level flaws. An authorisation model that is coherently implemented and wrong is not visible in a diff. Neither is a missing check that should exist in a file the change did not touch.

Cross-change interactions. Two pull requests that are individually safe and jointly introduce a race are outside what reviewing one diff can see.

Anything requiring the threat model. Whether a given endpoint should be reachable without authentication is a question about your system, not about the code in front of it.

Reviewing agent-authored changes

Cluster 7 produces pull requests written by the cloud agent. Copilot reviewing Copilot’s work is a reasonable question, and the answer is more useful than it first appears.

It helps, but not for the reason people expect. The value is not a second opinion from the same underlying capability — where the generation was confidently wrong, the review frequently agrees with it. The value is that the review is reading a diff rather than working from an instruction, and diffs make some problems visible that intent does not: files touched that were not mentioned, a test whose assertion was weakened, a dependency added quietly.

So the practical guidance splits.

Keep the review on agent pull requests. It catches mechanical problems and costs little.

Do not treat two AI passes as equivalent to human review. The failure mode that matters for agent output — a correct implementation of the wrong task — is exactly the one neither pass detects, because both are evaluating the change rather than the premise.

Read the agent’s own summary against your request first. That comparison, which takes ten seconds, catches the expensive category before you read a line of diff or a single review comment.

Where it fits against your existing tools

Teams already running static analysis reasonably ask what this adds, and the answer is a genuine difference in kind rather than degree.

Linters and type checkers enforce rules exhaustively and identically every time. Anything they cover should not be in an instructions file, and anything a review comments on repeatedly is a candidate for becoming a lint rule.

Static analysis and code scanning find known vulnerability patterns with a tuned false-positive rate. They are deterministic in the same useful way.

Copilot review reads a diff and comments on what it notices, which includes things no rule was written for — a comment that no longer matches the code, an error path that silently differs from its neighbour, a test asserting something weaker than its name claims. That category is genuinely uncovered by everything else, and it is where the value is.

The corollary is that its weakness is consistency. It will notice something on one pull request and miss the same thing on the next. Anything that must be caught every time belongs in a tool that catches it every time.

Common questions

Can it review code it did not write? Yes — it reads the diff, and the origin of the change makes no difference to how it is evaluated. That includes code written by another AI tool entirely.

Does it re-review after I push? A manually requested review is a one-off, so pushing a fix does not automatically produce a fresh review. Reviewing every push is a setting on the automatic path, covered in the next lesson.

Does an instructions file affect anything besides review? Yes — repository instructions inform Copilot generally, which is a feature rather than a side effect. A rule that improves reviews usually improves generation too.

Why did it ignore my instructions file? Check the path first — .github/copilot-instructions.md for repository-wide, .github/instructions/ for path-specific. Then check length: a very long instructions file competes with the diff for attention.

Does it see the whole repository or just the diff? It reviews the pull request. Repository context informs it, but a problem whose evidence lives entirely in an unchanged file is not something a diff review is positioned to find.

Should every repository have an instructions file? Every repository where the review runs, yes — otherwise the comments are generic. It does not have to be long; ten specific rules beat fifty general ones.

What happens with a very large pull request? Coverage degrades in the same way a human reviewer’s does. The fix is the pull request, not the setting.

Can I stop it reviewing certain paths? Content exclusion keeps files out of review, though that is a blunt instrument since it also removes them from suggestions and Chat. For narrower shaping, path-specific instructions telling it what matters in those paths is usually the better tool.

Can it approve a pull request? It reviews and comments. Approval that satisfies branch protection remains a human action, which is the property that makes the whole arrangement safe.

Rolling it out to a team

The technical setup takes minutes. The part that determines whether it works is how it arrives.

Introduce it as a first pass, not a gate. Teams told “Copilot now reviews your pull requests” hear “a machine is judging my work”. Teams told “there is a first pass that catches the mechanical stuff before a colleague reads it” hear something accurate and considerably less threatening.

Start on a single repository. Preferably one where a couple of people who will give honest feedback do most of the work.

Let the team write the instructions file. The rules that matter are the ones they are tired of repeating in review. Handing them a file written elsewhere produces a file nobody maintains.

Ask after two weeks whether the comments are useful. Not whether they like it — whether any comment has changed a change. If the honest answer is no, the configuration is wrong and expanding it will multiply the problem.

Watch for the drift. The failure to look for is human reviewers approving faster because something already looked. Nobody decides this and it happens anyway. Saying out loud that the Copilot pass covers the mechanical layer only, and repeating it, is most of the defence.

Cost, briefly

Manual review is invoked deliberately, so the volume is bounded by how often someone asks — which makes the cost easy to reason about and easy to ignore.

The published Lite range is roughly $0.05 to $1 per review; Balanced runs $0.25 to $5. Both scale with diff size, which is the variable actually under your control.

Two implications worth holding.

A large pull request costs more and reviews worse. The same fix addresses both, which makes “keep changes small” the rare piece of advice that is simultaneously a quality argument, a review argument and a cost argument.

Balanced is a targeted tool. On a straightforward change the higher-reasoning model produces more commentary rather than better commentary, at five times the price. Reserve it for the code where intricate logic genuinely justifies it.

Next

If the question you actually have is whether this replaces a human reviewer rather than how to configure it, Copilot Code Review vs Human Review covers what automated review structurally cannot do and how to sequence the two.

Automatic code review covers running this without anyone remembering to ask — which is a ruleset decision rather than a settings toggle, and one that generates real noise if configured carelessly.