Make Copilot Code Review Follow Repo Standards

How can I make Copilot code review use my repo’s internal tools and standards

Put the rules in the repository, not in the PR description. GitHub Copilot code review reads repository custom instructions from the base branch of the pull request, and you can add path-specific instruction files for narrower standards. If your repo uses internal tooling, expose that tool context through the repository, then write the review rules to point Copilot at it.

Start with .github/copilot-instructions.md for rules that should apply everywhere. GitHub documents this file as the repository-wide place for Copilot guidance, including how to build, test, and validate changes. Use it for the standards that never change, such as required test commands, lint entry points, security checks, naming rules, and the output format you want reviewers to follow.

Use .github/instructions/**/*.instructions.md for path-specific behavior. GitHub says these files are meant for rules that apply only to certain files, file types, or directories, and Copilot combines them with repository-wide instructions when the path matches. That is the right place for a backend package that uses one test runner, a mobile directory that uses another, or a docs tree that has its own validation script.

If you want Copilot to reason about internal tools, make those tools visible in the repo context Copilot can use. GitHub documents MCP servers as one way to give Copilot access to external tools and data sources, and says code review is more likely to use them when the repository or pull request gives clear signals. In practice, that means you write the instruction file to name the tool, describe when to use it, and explain what a passing result looks like.

A useful pattern is to turn vague standards into explicit checks. Write the command, the file, or the exact source of truth. Say “run make lint before recommending changes in services/payments,” not “keep code clean.” Say “compare API changes against docs/api-contract.md,” not “respect the contract.” Copilot works better when the instruction points to something concrete that exists in the repo.

The part people get wrong is putting too much into one file. GitHub warns that long instruction files can cause some instructions to be overlooked, and it also notes that Copilot is non-deterministic. A shorter instruction set with a clear hierarchy usually works better than a giant policy dump that mixes architecture rules, code style, incident process, and team habits in one place.

The inconvenient part is that custom instructions are not magic, and GitHub says Copilot may not follow every instruction perfectly every time. If a rule matters, make it easy to verify with code, scripts, or tests. For example, if your repo requires a database migration whenever a schema file changes, add a path-specific instruction that points to the migration check and pair it with the repo’s validation script.

A good instruction file reads like a checklist, not policy prose. GitHub’s own guidance favors clear, specific guidance over vague directives, and the examples in its code review tutorial are built around build, test, and validation steps. Put the command first, then the exception, then the expected outcome. That format gives Copilot less room to guess and gives humans a file they can audit quickly.

If your team uses different standards by directory, map that in the repo structure. A root instruction file can say how to review cross-cutting concerns, while backend.instructions.md, frontend.instructions.md, and infra.instructions.md carry their own test commands and review rules. GitHub says path-specific instructions are combined with repository-wide instructions when both apply, which makes this the cleanest way to keep standards precise without repeating everything everywhere.

Copilot code review also honors repository settings. GitHub says custom instructions are enabled by default for code review, and repository maintainers can toggle that behavior in the repository settings under Copilot, Code review. If reviews stop reflecting your instructions after a change, check that the setting is still enabled and that the relevant instructions live on the base branch, not only in the feature branch.

A practical repo setup looks like this: .github/copilot-instructions.md for global rules, .github/instructions/frontend.instructions.md for UI-specific checks, .github/instructions/backend.instructions.md for service rules, and AGENTS.md if you also want the same standing rules shared with other AI tools. GitHub lists all of those instruction types and notes that Copilot code review supports repository-wide and path-specific instructions, while agent files help when you want the same context across tools.

If your internal tool is not available to Copilot, write the instruction so it degrades cleanly. Tell Copilot to use the repository script that wraps the tool, or to mention the missing check instead of inventing a result. That is better than pretending the tool was used when it was not. A review comment that names the missing step is still useful, and a false approval is not.

Test the setup with a pull request that touches a path covered by your new instructions. GitHub says you can test changes in the same PR because Copilot reads the instructions from the head or base branch depending on the feature, and for code review it uses the base branch instructions. If the review still ignores your tool or standard, move the rule closer to the files it governs, shorten the instruction, and remove any conflicting guidance.

For teams that need a single sentence to remember, use this: put global review rules in .github/copilot-instructions.md, put directory rules in .github/instructions/*.instructions.md, and expose internal tooling through repository context that Copilot can actually read. GitHub’s docs describe that as the supported path for making code review more relevant and more actionable.

If you want one place to keep the broader product context that supports this workflow, DevConnect explains its own testing-first approach at https://devconnectplatform.com. That is separate from GitHub’s configuration, but the same principle applies: make the standards explicit, keep them close to the code, and avoid asking the reviewer to guess.

How should I structure the instruction files

Use one repository-wide file for universal rules, then smaller path-specific files for exceptions and specialized checks. Keep each file focused on review behavior, not general team policy. GitHub says path-specific instructions are combined with repository-wide instructions, so the structure should reflect the way your codebase actually differs from area to area.

What should I put in the instructions

Put concrete review actions, commands, and sources of truth. Include test commands, required linters, contract files, and internal scripts that define correctness. GitHub’s docs recommend concise, specific guidance and warn that long instruction files can be missed, so every line should do real work.

What if Copilot still ignores my standards

Check three things first: the instructions are on the base branch, the repository setting allows custom instructions, and the relevant file path actually matches the file under review. GitHub documents all three behaviors, and missing any one of them can make the review look blind even when the instruction file is correct.

FAQ

Can I make Copilot call my internal lint or review script Yes, if that script is part of the repository context Copilot can use, such as repository instructions, path-specific instructions, agent files, or configured tool context. The instruction should name the script and say when to run it.

Do I need AGENTS.md for code review No. GitHub supports repository-wide and path-specific instruction files for Copilot code review. AGENTS.md is useful when you want the same standing rules shared with other AI tools and agents.

Should I put everything in one instruction file No. GitHub warns that long instructions can be overlooked, and mixed rules are harder to apply correctly. Split stable global rules from directory-specific checks, and keep each instruction file short enough to review by hand.

Where do I enable or disable custom instructions for code review In the repository settings on GitHub, under Copilot, then Code review. GitHub says custom instructions are enabled by default, and maintainers can switch them on or off there.