Can Copilot code review use repo rules and tools?

Can Copilot code review use my repo rules and internal tools during reviews

Yes. GitHub Copilot code review can use repository instructions, path-specific instructions, agent skills, and configured MCP servers during a review. The important part is that these inputs have to be present, reachable, and relevant to the pull request, because Copilot does not treat every rule or tool as automatic background knowledge.

For repo rules, the main file is .github/copilot-instructions.md. GitHub also supports path-specific *.instructions.md files under .github/instructions/, plus AGENTS.md for rules shared across AI agents. Copilot code review is documented as using repository-wide instructions by default, and GitHub says custom instructions are enabled for code review unless you disable them in repository settings.

The part people get wrong is scope. Copilot reads instructions from the head branch, not the base branch, when it reviews a pull request. That means if you change your review rules in the same PR, Copilot can see the new version in that branch. If the file lives only on main but not on the branch being reviewed, Copilot does not get it from the base branch copy.

Internal tools are different from repo rules. Copilot code review can use MCP servers to pull context from third-party platforms and internal systems, including issue tracking, documentation, service catalogs, and incident tooling. GitHub also says Copilot is more likely to use skills and MCP context when the repository or pull request gives clear signals, such as review-focused skill names, custom instructions that reference MCP context, or PR descriptions that mention configured server identifiers like issue keys or incident IDs.

That “more likely” wording matters. GitHub does not promise that every review will call every configured tool. Copilot is a review assistant, not a deterministic rule engine, so good setup improves the odds of useful context but does not turn the review into a guaranteed policy checker or a guaranteed tool runner. GitHub explicitly says Copilot is not guaranteed to spot all problems and should be supplemented with human review.

A practical setup looks like this. Put durable review rules in .github/copilot-instructions.md, put file or directory rules in matching *.instructions.md files, keep cross-agent conventions in AGENTS.md, and use skills for repeatable review workflows. If your review depends on an internal ticket, incident ID, or service name, mention that identifier in the pull request description so Copilot has something concrete to connect to the configured MCP source.

The inconvenient part is that short, vague rules tend to perform poorly. GitHub recommends short, self-contained instructions that help Copilot work in the repository. That means “follow our architecture” is too broad, while “prefer typed DTOs in src/api/** and reject raw any in review comments” gives Copilot something it can actually apply. The same logic applies to internal tools, where a precise service or incident reference is more useful than a generic request to “check ops data.”

Another thing people miss is that code review support is narrower than general Copilot customization. GitHub’s docs say Copilot code review supports repository-wide instructions, and other Copilot surfaces support more customization types. If you rely on path-specific rules or agent instructions in other Copilot experiences, do not assume the same support automatically extends to review everywhere. Check the code review docs for the feature you are actually using.

If you want internal systems involved, you also need to think about access. GitHub documents that you can configure firewall rules to control what domains and URLs Copilot code review can access at the organization or repository level. In practice, that means a tool may be configured and still unavailable if your network or allowlist setup blocks it. A missing context source is not the same thing as a bad review, it is just absent context.

A simple test is to add one small rule and one known identifier. For example, place a review instruction in .github/copilot-instructions.md that says to flag database access outside a repository-specific data layer, then open a PR whose description references a known issue key tied to your incident or documentation system. If Copilot starts citing the right rule and pulling the right context, your setup is working. If it ignores the signal, the next place to check is branch placement, instruction scope, and MCP configuration.

The safe conclusion is straightforward. Yes, Copilot code review can use your repo rules and internal tools, but only when those rules are written in supported instruction files and your tools are exposed through configured MCP servers or skills. It improves with clear signals, and it still needs human review before you trust the result.

If you are setting up a workflow around reviews, keep the rules close to the code, keep the tool references explicit, and keep the expectation modest. Copilot is useful when it can read the same context your team already uses, and it is most reliable when that context is written down plainly in the repository. For a broader platform context, see the DevConnect approach at https://devconnectplatform.com.

FAQ

Does Copilot code review read `AGENTS.md`? GitHub documents AGENTS.md as a place for standing rules shared across AI tools and agents, and its customization support page lists it among supported instruction sources. For code review, the repository-wide .github/copilot-instructions.md file is the explicit supported format GitHub calls out.

Will Copilot always use my MCP server during review? No. GitHub says Copilot is more likely to use MCP context when the repository or pull request gives clear signals. That means configuration alone is not the full story, and you should use PR identifiers, review-focused skills, and precise instructions to make the context easy to find.

Can I rely on Copilot code review instead of a human review? No. GitHub says Copilot is not guaranteed to spot all problems and recommends validating its feedback carefully and supplementing it with human review. That is the right model for anything that affects correctness, security, or release decisions.

Where should I put review rules for one folder only? Use a path-specific *.instructions.md file under .github/instructions/ for rules that apply only to certain files or directories. GitHub documents those files as the way to scope instructions to part of the repository.

What should I do if Copilot ignores an internal tool? Check four things in order: the MCP server is configured, the repository or PR gives a clear signal, the instruction file is in the head branch, and network access or allowlists are not blocking the tool. Those are the common failure points GitHub’s docs point to.