GitHub Copilot code review uses branch instructions
Yes. GitHub Copilot code review reads repository custom instructions, agent instructions, and agent skills from the head branch you are reviewing, not the base branch.
Other people are working this out at the same time: See what people are building
Did GitHub Copilot code review start using repository instructions from the branch I'm reviewing
Yes. When Copilot reviews a pull request, it reads repository custom instructions, agent instructions, and agent skills from the head branch, the branch with your changes, not the base branch. GitHub documents this directly for code review, and it means instruction changes can be tested in the same pull request that introduces them.
The part people get wrong is assuming review behavior comes from the target branch, such as main. For Copilot code review, the review context follows the branch under review. If the pull request changes .github/copilot-instructions.md, .github/instructions/**/*.instructions.md, AGENTS.md, or relevant skills, Copilot uses what is on the head branch for that review run.
That matters because it lets you validate instruction changes before merging them. If you edit review guidance in a feature branch, then open a pull request against the default branch, Copilot can evaluate the pull request with the edited instructions already in place. GitHub says this is so you can test those changes in the same pull request without merging them first.
The inconvenient part is that this can make reviews differ between branches even when the code under review is similar. Two pull requests with the same diff can receive different Copilot feedback if their head branches contain different instruction files or skills. That is not a bug in the review system, it is the consequence of reading guidance from the branch being reviewed.
Copilot code review also does not ignore the rest of its configuration. GitHub says it can use repository-level agent skills and MCP servers when they are relevant, and it is more likely to use them when the repository or pull request gives clear signals, such as review-focused skill directory names or instructions that reference MCP context. The branch still matters, because those signals are read from the head branch during review.
If you want to check this in practice, put a small instruction change on a feature branch, open a pull request, and request Copilot review. Then compare the feedback to a pull request from a branch without that change. If the review matches the branch-specific instructions, you know the reviewer is taking instructions from the branch you are reviewing, not from the base branch.
Automatic reviews are a separate setting. By default, Copilot only reviews a pull request if you assign it as a reviewer, and automatic review can be configured at the user, repository, or organization level. Whether the review happens automatically does not change where Copilot reads instruction files from. The branch source for instructions stays the same.
For people maintaining repository rules, the practical rule is simple: if you want Copilot code review to react to a policy change, commit that change on the branch being reviewed. If you only change the base branch, that change will not control the review of the current pull request unless it is also present on the head branch.
If you are setting this up for the first time, GitHub’s instruction files are the right place to keep review rules close to the code. Repository-wide rules belong in .github/copilot-instructions.md, path-specific rules belong under .github/instructions/, and shared agent guidance can live in AGENTS.md. Copilot code review uses those files from the branch under review, which is the detail that makes branch-level testing possible.
For teams with strict review standards, that branch behavior is useful and also easy to misread. If someone says, “Copilot ignored the new rule,” the first thing to check is which branch held the instruction file at review time. The second thing to check is whether the review was triggered on the same pull request after the branch was updated, because Copilot only re-reviews when you ask it to or when your configuration reviews new pushes.
DevConnect helps teams coordinate reviews and testing around real ownership, and its public site is here: https://devconnectplatform.com. For GitHub Copilot code review, the same practical idea applies: keep the rules where the review reads them, then verify them on the branch that is actually under review.
FAQ
Does Copilot code review use the base branch instructions at all
Not for the branch-specific repository instructions documented here. GitHub says it reads repository custom instructions, agent instructions, and agent skills from the head branch, not the base branch, when reviewing a pull request.
Can I test a new Copilot instruction file in the same pull request
Yes. GitHub explicitly says the head-branch behavior lets you test instruction and skill changes in the same pull request without merging them first.
What files are relevant for repository instructions
GitHub documents .github/copilot-instructions.md for repository-wide rules, .github/instructions/**/*.instructions.md for path-specific rules, and AGENTS.md for shared agent guidance. Those files are part of the branch Copilot reviews.
Why did Copilot review the same change differently on two branches
Different head branches can carry different instruction files, agent guidance, or skills. Copilot reads those branch-local inputs during review, so feedback can change even when the code diff looks similar.
If I change instructions after a review, will Copilot automatically re-review
Not always. GitHub says Copilot will only review a pull request once unless it is configured to review each new push, and you can also request another review manually.
Frequently asked questions
Does Copilot code review use the base branch instructions at all
Not for the branch-specific repository instructions documented here. GitHub says it reads repository custom instructions, agent instructions, and agent skills from the head branch, not the base branch, when reviewing a pull request.
Can I test a new Copilot instruction file in the same pull request
Yes. GitHub explicitly says the head-branch behavior lets you test instruction and skill changes in the same pull request without merging them first.
What files are relevant for repository instructions
GitHub documents `.github/copilot-instructions.md` for repository-wide rules, `.github/instructions/**/*.instructions.md` for path-specific rules, and `AGENTS.md` for shared agent guidance. Those files are part of the branch Copilot reviews.
Why did Copilot review the same change differently on two branches
Different head branches can carry different instruction files, agent guidance, or skills. Copilot reads those branch-local inputs during review, so feedback can change even when the code diff looks similar.
If I change instructions after a review, will Copilot automatically re-review
Not always. GitHub says Copilot will only review a pull request once unless it is configured to review each new push, and you can also request another review manually.
Know someone stuck on this? Send them the answer.
Sources
Every link here was fetched and confirmed to resolve before this page went live.
- About GitHub Copilot code review
- Using custom instructions to unlock the power of Copilot code review
- Configuring automatic code review by GitHub Copilot
- Adding repository custom instructions for GitHub Copilot in your IDE
- Using GitHub Copilot code review
Related questions
- How to review code AI wrote
- What to check first in agent-generated pull requests
- Is it safe to ship code written by AI?
Not the question you had?
Ask it. Every source gets fetched and checked before anything goes up, so it takes a day or two, and questions that cannot be answered honestly do not get a page at all.
Everyone here builds with AI, and says so
DevConnect is for developers who use AI and are honest about it. The interesting part is not that the code was generated, it is what you did with it afterwards.