Microsoft AB-100: GitHub Copilot Code Review Workflows

GitHub Copilot code review is most useful when it becomes part of an existing pull-request workflow rather than a replacement for engineering review. Copilot can inspect changes, suggest issues, and apply repository-specific instructions, while human reviewers remain responsible for architecture, product intent, security context, and final approval.

Current GitHub documentation supports repository-wide custom instructions, path-specific instructions, and agent instructions such as AGENTS.md for Copilot code review. The review reads the relevant instructions from the pull request’s head branch, which means teams can test instruction changes in the same branch before merging them.

That makes code review part of a broader business AI operating model when GitHub Copilot is being adopted across engineering teams.

Use Copilot as an additional reviewer

Copilot can flag likely bugs, missing checks, style issues, or implementation concerns, but it does not know every business requirement or architectural tradeoff.

Keep human review for intent, risk, maintainability, and decisions that depend on context outside the diff.

The strongest workflow uses Copilot to broaden review coverage and free humans to focus on higher-order judgment.

Write repository-wide review instructions

A .github/copilot-instructions.md file can define repository-wide expectations such as coding standards, architectural constraints, testing requirements, and review priorities.

Keep the file concise and concrete. GitHub notes that overly long instruction sets can reduce reliability.

Copilot context should provide standing project knowledge that a reviewer would otherwise need to rediscover repeatedly.

Add path-specific rules where needed

Different parts of a repository can have different conventions. Database migrations, security-sensitive code, UI components, and generated files may need different review guidance.

Path-specific instruction files under .github/instructions/ can scope rules to matching paths.

This is more maintainable than filling the repository-wide file with exceptions for every subsystem.

Use AGENTS.md for shared agent guidance

AGENTS.md can provide standing instructions for AI agents and can also be used by Copilot code review in supported contexts.

This is useful when the organization wants instructions that can be shared across multiple agent tools rather than written only for one Copilot feature.

Keep the guidance focused on durable repository behavior such as build commands, testing, architecture, and known intentional patterns.

Review the head branch instructions

Copilot code review reads custom instructions from the head branch of the pull request.

This has an important workflow advantage: instruction changes can be tested in the same pull request that proposes them.

It also means reviewers should understand that a contributor can change the instructions that guide Copilot’s review of that branch.

Ask for targeted review

Use custom instructions to emphasize risks that matter to the repository: error handling, backward compatibility, authentication, test coverage, query performance, or concurrency.

A vague instruction such as “review carefully” adds little context.

Engineering context improves AI review when the system knows which patterns are intentional and which failures the team considers important.

Keep automated review in the pull-request loop

Copilot review should produce comments that developers can inspect, discuss, accept, reject, or convert into changes.

Do not create an automatic merge path merely because Copilot returned no findings.

The absence of a Copilot comment is not proof that the code is correct.

Measure adoption separately from quality

GitHub tracks code-review usage, including active and passive review users, but adoption does not prove that review comments improved code.

Copilot metrics should combine review activity with pull-request outcomes, developer feedback, escaped defects, and the team’s own quality signals.

Metrics are useful for identifying patterns, not for replacing engineering judgment.

Iterate on review instructions

When Copilot repeatedly misses an important repository-specific issue, consider whether a concise instruction could make the risk visible.

When it produces noisy comments, simplify or narrow the relevant instruction.

For current GitHub Copilot workflows, the durable pattern is to keep AI review inside the normal pull-request process, provide concise repository context, preserve human approval, and evolve instructions based on real review quality rather than novelty.

Review instructions should focus on risks Copilot can observe from code and repository context. Asking it to verify undocumented business behavior or infrastructure it cannot access creates noise. Good instructions point to conventions, security-sensitive patterns, validation requirements, and architectural rules present in the repository.

Path-specific instructions are especially useful in monorepos. A database migration directory can require rollback checks, an API folder can require backward compatibility, and infrastructure code can require policy validation without injecting all of those rules into every frontend change.

Teams should decide when Copilot review is requested manually and when it is assigned automatically. Automatic review can broaden coverage, while manual invocation gives developers more control over when the branch is ready. The choice should fit repository volume and review culture.

Copilot comments should be triaged like other review feedback. Developers can accept, reject, discuss, or convert them into changes. Repeated false positives should lead to instruction refinement rather than teaching developers to ignore the entire reviewer.

Security-critical changes still need appropriate human or specialized automated review. Authentication, cryptography, authorization, infrastructure, and sensitive-data handling often require context beyond what general code review can guarantee.

Review effectiveness can be improved by making build and test commands available in repository instructions. When Copilot understands how the project validates changes, its review can better point developers toward the checks that matter instead of suggesting generic testing advice.

Branch protection and merge policy should remain independent of Copilot’s confidence. Treat AI review as one signal inside the pull-request process. Required human reviewers, CI checks, and security gates should continue to enforce the organization’s risk model.

Use developer feedback to tune the workflow. Ask whether Copilot catches useful issues, whether comments arrive at the right time, and whether instructions create too much noise. The goal is a review system that increases useful coverage without making pull requests harder to understand.

Repository maintainers should periodically sample accepted and rejected Copilot comments. This reveals whether the reviewer is finding meaningful issues, repeating style preferences already enforced by linters, or missing repository-specific risks. Those samples are often more actionable than a raw count of comments.

Instruction changes should be reviewed like code because they affect future AI review behavior. A pull request that changes copilot-instructions.md or path-specific guidance should explain the intended improvement and include examples of review behavior where practical.

Teams should also keep generated or vendored code out of review focus when possible. Asking Copilot to spend attention on files developers never edit can increase noise and reduce trust. Repository instructions can clarify which paths deserve scrutiny and which should normally be ignored.

Finally, use Copilot review to complement existing automation. Linters, static analysis, tests, security scanners, and type systems provide deterministic checks. AI review adds contextual reasoning around the diff. The workflow is strongest when each tool does the work it is best at rather than duplicating the same comments across every pull request.

Review timing matters. An early Copilot review can help a developer catch obvious problems before asking a teammate, while a final review after CI passes can focus on the finished diff. Teams can experiment with where AI review creates the most useful signal without delaying the pull request.

Instruction scope should be tested on real diffs. A repository-wide rule that sounds sensible may produce irrelevant comments in generated code, tests, or infrastructure. Move such rules into path-specific files when only one subsystem needs them.

Keep review suggestions auditable through the normal pull-request history. Developers should apply changes through commits rather than accepting invisible edits outside the branch. This preserves the same accountability as human review feedback.

Use Copilot review to improve standards documentation. If maintainers repeatedly explain the same rule in comments, that rule may belong in a linter, test, repository instruction, or architecture document. AI review can reveal where team knowledge is still implicit.

Do not optimize for comment volume. Fewer high-confidence comments are usually more valuable than a long list of speculative style observations. Review quality should be judged by whether developers act on findings and whether important issues are caught earlier.

The mature workflow therefore treats Copilot as a context-aware automated reviewer inside an existing engineering system. CI remains deterministic, humans retain accountability, instructions capture repository knowledge, and metrics help the team tune where AI review adds real value.

Review policy should remain transparent to contributors. Document when Copilot review runs, which custom instructions apply, and whether any findings are required for merge. Developers are more likely to trust AI review when the workflow is predictable.

Keep review evidence.