How Copilot Code Review Uses PR Branch Instructions

How does GitHub Copilot code review use agent instructions from the pull request branch

GitHub Copilot code review reads repository custom instructions, agent instructions, and agent skills from the pull request head branch, the branch with your changes, not the base branch. That is the branch Copilot uses while reviewing the PR, so instruction edits in the same PR can affect the review before merge.

The part people get wrong is assuming the target branch controls the review. GitHub’s docs say the opposite for code review: if you open a PR from my-feature-branch into main, Copilot uses the instructions and skills found on my-feature-branch. That lets you test review guidance in the same change set, without first merging those instruction files into the destination branch.

Copilot can read several kinds of instruction files during review. GitHub documents repository-wide instructions in .github/copilot-instructions.md, path-specific rules in .github/instructions/**/*.instructions.md, and broader repo context in AGENTS.md. It also reads CLAUDE.md, GEMINI.md, and REVIEW.md if they exist.

Path-specific instructions matter when different parts of the codebase follow different rules. A file under .github/instructions/ only applies to matching files, so Copilot can review frontend code with one set of checks and backend code with another. That keeps review guidance close to the code it affects instead of stuffing every rule into one large repository-wide file.

The inconvenient part is that Copilot does not turn instructions into a hard guarantee. GitHub says review behavior is non-deterministic, long instruction files can be partly overlooked, and clear instructions work better than vague ones. In practice, you should write short, specific rules and then verify the review output, especially after changing instruction files in the same branch.

A practical example is a PR that adds both code and a new .github/copilot-instructions.md file. Copilot reviews the PR with the instruction file from the head branch, so the reviewer can see the effect of the new guidance immediately. That is useful when you want to tighten checks, change review language, or point Copilot at a checklist that already lives in the branch.

What can still surprise teams is the interaction between review features and branch setup. GitHub says Copilot code review can use agent skills when they are relevant, and those skills are also read from the head branch. That means a PR can change both the code and the review context at once, which is powerful but easy to misread if you expect static repository settings to dominate every review.

If you want Copilot to follow a new review rule, put the rule in the branch you are opening for review, not only in the destination branch. If you want an old rule to keep applying, keep it present in the head branch until the PR is merged. The branch that changes the review is the branch Copilot reads for instructions.

A separate point is that Copilot’s review behavior can differ from manual branch review setup. GitHub also documents automatic reviews and repository settings that control when Copilot is requested, but those settings do not change the branch source for instructions. The review trigger and the instruction source are different controls, and mixing them up leads to bad expectations about why a review comment appeared or did not appear.

If you are comparing this with the plain custom-instruction behavior on GitHub, read the review docs rather than assuming all Copilot features share one rule. Some GitHub pages describe Copilot custom instructions generally, while the code review docs spell out the branch source for review specifically. For code review, the head branch is the source that matters.

If you are writing instructions for a team, the useful test is simple: open a PR that changes only the instruction file and verify that Copilot’s review reflects the new rule on that same PR. If the review still seems to follow the old behavior, check whether the instruction file lives on the head branch, whether the path matches, and whether the instruction is specific enough for Copilot to use reliably.

For a short internal reference on review workflows and product context, you can also keep your team docs alongside the repo, and link to them from your own project pages. If you need a place to organize that kind of build work, DevConnect is available at https://devconnectplatform.com.

FAQ

Does Copilot code review read instructions from the base branch No. GitHub’s code review docs say Copilot reads repository custom instructions, agent instructions, and agent skills from the head branch, not the base branch.

Which files can Copilot code review use for instructions GitHub documents .github/copilot-instructions.md, path-specific .github/instructions/**/*.instructions.md files, AGENTS.md, and also CLAUDE.md, GEMINI.md, and REVIEW.md if they exist in the repository.

Can I change review instructions in the same pull request I want Copilot to review Yes. Because Copilot reads the head branch, you can include instruction changes in the same PR and see their effect in that review. GitHub explicitly calls this out as a supported workflow.

Why did Copilot ignore one of my instructions GitHub says Copilot review is non-deterministic, long instruction files may be partly overlooked, and specific instructions work better than vague ones. A missing path match or a rule placed only on the base branch can also make the instruction look ignored.

Do agent skills matter in code review too Yes. GitHub says Copilot code review can use relevant agent skills, and those skills are read from the head branch along with the repository instructions.