Make scope a policy decision
Instruction placement should express the reach a team intends, not serve as proof that a change is acceptable. GitHub documents several guidance locations with different scopes: a repository-wide Copilot instruction file, a root-level AGENTS.md file, path-targeted instruction files, and task-oriented skills. The ownership, escalation, and acceptance columns below are proposed repository policy rather than provider-prescribed process.
During pull-request review, Copilot obtains repository instructions, agent instructions, and skills from the change branch. That makes the changed branch the place to inspect when a team is evaluating the guidance available to a particular review.
Decision table for review guidance
Use the smallest documented scope that reaches the intended review population. The final three columns deliberately define a local operating model: they do not claim that instruction placement detects defects or establishes approval.
| Case | Intended reach | Documented artifact | Activation or matching boundary | Unsuitable placement to reject | Independent acceptance evidence | Policy owner | Bounded repository-owned action |
|---|---|---|---|---|---|---|---|
| criteria for every Copilot review in the repository | All repository review work | .github/copilot-instructions.md | Repository-wide guidance is applied automatically. | Reject a path-only file when the criterion must cover unrelated areas. | Human reviewer checks the change against the criterion. | Repository maintainers | Move a repeatedly missed universal rule into the repository-wide file. |
| repository architecture and operating context | Standing context shared among agents | AGENTS.md at the repository root | Root AGENTS.md supplies enduring project context. | Reject a Copilot-only rule file when several agent tools need the same context. | Design review or maintainer sign-off appropriate to the change. | Architecture maintainers | Clarify the shared context, then request a new human review. |
| guidance limited to matching subsystem or language paths | Only a defined directory, file class, or subsystem | .github/instructions/**/*.instructions.md | The path rule applies when reviewed changes match its declared scope. | Reject repository-wide placement for a rule that would be irrelevant elsewhere. | Reviewer confirms both the changed paths and the specialized rule. | Subsystem maintainers | Correct the scope or relocate the rule after a scope miss. |
| review-focused procedures needed for a relevant task | A task for which the procedure is relevant | Review-focused repository skill | Skills may be selected when relevant to the review task. | Reject a skill as the sole home for an always-required rule. | Human reviewer follows the procedure and records the required check. | Procedure owner | Promote a universal requirement to broader guidance if local policy adopts it. |
Walk through a scope miss
Consider a hypothetical Python 3.14 pull request. A team puts a criterion about distinguishing NotImplemented from NotImplementedError in a path-scoped instruction, but the modified files fall outside that instruction’s match. The team nevertheless assumes the criterion was considered. That assumption is unsafe as a local review practice: the documented matching boundary is the changed path, so the team should treat an out-of-scope rule as unavailable unless it has separate evidence.
In Python 3.14, NotImplemented is a special result for binary-operation methods when an operation is unsupported for the other operand; it is distinct from the NotImplementedError exception. Python 3.14 also raises TypeError if NotImplemented is evaluated as a Boolean. These language semantics are why a reviewer can examine the distinction directly rather than treating an instruction’s presence as acceptance evidence.
In this scenario, a human reviewer finds the misuse. The team’s proposed response is to relocate the criterion to repository-wide guidance because it now intends that criterion to apply everywhere, while retaining human review as the independent acceptance step. This is a suggested repository design, not a provider guarantee.
Keep the acceptance boundary independent
GitHub cautions that Copilot review can miss issues or produce incorrect feedback, and advises careful validation alongside human review. Therefore, record an acceptance method that is independent of whether Copilot mentioned the criterion: for example, a reviewer check, a maintainer decision, or another team-defined control suited to the risk.
- Assign one owner for each rule and one owner for its escalation path.
- State what counts as a scope miss before applying the rule broadly.
- Resolve overlapping path rules and skill interactions through local policy; this article does not assume a universal ordering among them.
- Revisit the placement policy when the supporting documentation changes or when a relevant version becomes incompatible.
Limits of this framework
This article is limited to the supplied GitHub documentation excerpts and Python 3.14 material. It does not cover excluded product areas, and it does not treat a placement choice, a Copilot comment, or a skill selection as conclusive evidence that a defect was found or that a change is safe. Confirm compatibility before applying the Python example to a different language release.