Can Copilot code review use repo docs and tools?

Can Copilot code review use my repo’s internal tools and documentation during review

Yes for documentation that lives in the repository, no for live internal tools during the review itself. GitHub Copilot code review can read repository custom instructions, path-specific instructions, and agent instructions from the head branch, so files in the repo can shape the review context.

That means you can put review guidance in .github/copilot-instructions.md, path-specific instruction files under .github/instructions, and agent instruction files such as AGENTS.md in the repo. GitHub says Copilot code review supports repository-wide instructions, path-specific instructions, and agent instructions, and it reads them from the branch being reviewed.

The part people get wrong is assuming Copilot can run the same internal tooling your teammates use in a review. The docs describe instruction files and skills as context, not as a place where Copilot executes scripts, calls private services, or opens your app’s admin tools. The supported mechanism is guidance in files, not live access to your runtime.

The useful pattern is to make the repo explain itself. If your project has a lint rule, a migration convention, a test command, or a service boundary, write that into repo instructions so Copilot can factor it into review comments. GitHub’s docs explicitly say repository custom instructions can help Copilot understand how to build, test, and validate changes.

A concrete example: if your backend uses a generated client, your instruction file can say where the client is produced, what files should not be edited by hand, and which checks should be run after touching API contracts. Copilot can use that text while reviewing a pull request, but it still only has the context that was committed in the branch, not your live build environment.

Another detail that matters in practice is branch scope. GitHub says Copilot reads repository custom instructions, agent instructions, and agent skills from the head branch, not the base branch. If someone updates the rules in the same pull request, Copilot reviews with those updated rules before they are merged.

That is useful, but it also creates a failure mode. If the review guidance is stale, contradictory, or buried in a long file, Copilot may miss the part you care about. GitHub warns that instruction files are subject to context limits and that specificity matters, so concise, direct instructions work better than broad policy prose.

If by internal tools you mean protected knowledge that is already written down in the repo, Copilot can use it through instructions. If you mean it should discover or operate private systems during review, the docs do not describe that capability. The reliable mental model is: Copilot reads your repo’s written guidance, then reviews code against that guidance.

This is why internal documentation is worth making explicit. A reviewer can only reason from what it can see, and the same is true here. Put deployment rules, architecture boundaries, test entry points, and prohibited patterns into instruction files if you want them considered during review. GitHub also provides examples of custom instructions for code review focused on security, performance, and code quality.

If your repo has a lot of scattered tribal knowledge, write the shortest instruction that removes ambiguity. Say which packages own which layers, which files are generated, what commands validate the change, and which cases need human review. That gives Copilot something stable to read, and it gives human reviewers the same baseline.

There is one more inconvenient point: custom instructions are optional, and repositories can disable them for code review in settings. GitHub documents a repository setting called “Use custom instructions when reviewing pull requests,” so the behavior is configurable and not guaranteed just because files exist.

If you want Copilot to respect your repo documentation, check three things before you rely on it. First, the instruction file exists in the branch under review. Second, repository custom instructions are enabled for code review. Third, the instructions are short enough and specific enough to survive context limits. GitHub documents all three conditions in its code review guidance.

For a team page like DevConnect, the practical advice is the same as for any repo-driven workflow: document the review rules in the repo itself, not in someone’s head. If you want Copilot to notice a service contract, a local test harness, or a release gate, encode it in repository instructions and keep it current. That is the part that actually changes review quality. You can see the platform’s own positioning at https://devconnectplatform.com, but the review behavior still depends on the instructions that are present in the repository.

The bottom line is simple. Copilot code review can use your repo’s written documentation and instruction files as context. It does not run your internal tools during review, so anything that matters has to be expressed in the repo in plain text.

FAQ

Can Copilot code review read .github/copilot-instructions.md Yes. GitHub documents repository-wide instructions in .github/copilot-instructions.md as supported for Copilot code review.

Can Copilot code review use path-specific instructions Yes. GitHub lists path-specific instruction files under .github/instructions/**/*.instructions.md as supported for Copilot code review.

Can Copilot code review use AGENTS.md Yes, GitHub lists agent instructions such as AGENTS.md as supported for Copilot code review. GitHub also says those instructions are read from the head branch during review.

Does Copilot code review follow every instruction perfectly No guarantee. GitHub says Copilot may overlook instructions because of non-deterministic behavior and context limits, so clear and specific instructions work better.

Can I turn off custom instructions for code review Yes. GitHub documents a repository setting to enable or disable custom instructions for Copilot code review.