Last reviewed: 2026-07-19
Direct answer
Instruction stack governance means treating every agent-readable instruction file as one coordinated system. Keep a short inventory that maps Claude Code project memory, GitHub Copilot repository instructions, and Codex AGENTS.md guidance to the same operating rules, then test whether each agent surface can restate those rules before assigning real work.
A practical workflow:
- Setup assumptions: the repository has one owner for shared agent instructions, a branch for instruction edits, and access to the current official docs linked below.
- Happy-path request plan: in a throwaway branch, ask each agent surface to summarize the repository rules it will follow for a harmless documentation task. Use
<API_KEY_PLACEHOLDER>anywhere a credential shape is needed. - Error-path check: add a deliberately conflicting instruction in a lower-priority or tool-specific file, then confirm the agent flags the conflict or follows the documented higher-priority source instead of mixing both rules.
- Minimum assertions: the agent identifies the instruction files it used, names any conflict, avoids secrets, and does not claim behavior that is absent from the linked docs.
- Pass/fail logging fields: record date, repository, branch, agent surface, instruction files checked, expected rule, observed summary, conflict result, reviewer, and pass/fail.
- What not to assert: do not assert model availability, pricing, uptime, rate limits, billing behavior, or exact hidden context loading unless the linked official source directly says so.
For related repository-rule patterns, see Instruction File Scope Checks for Coding Agent Repos .
Sanitized log template:
date: YYYY-MM-DD
repository: example-repo
branch: instruction-check
agent_surface: claude-code | github-copilot | codex
instruction_files_checked: [CLAUDE.md, .github/copilot-instructions.md, AGENTS.md]
expected_rule: "Use the documented project test command before proposing a PR."
observed_summary: "Placeholder summary only."
conflict_result: "flagged | followed-higher-priority-rule | failed"
credential_handling: "used <API_KEY_PLACEHOLDER> only"
result: "pass | fail"
notes: "No real prompts, responses, credentials, prices, limits, or availability claims."
Who this is for
This guide is for maintainers who let more than one coding assistant work in the same repository. It fits teams using Claude Code for terminal or IDE work, GitHub Copilot for repository-aware assistance, and Codex-style AGENTS.md files for task rules.
It is most useful when the same safety rule, build command, review handoff, or source-citation requirement must survive across tools instead of living in one assistant-specific file.
Key takeaways
- Put durable project rules in the instruction mechanism each agent is documented to read.
- Keep shared rules short, specific, and testable so agents can repeat them before touching code.
- Maintain one source-of-truth inventory that records which file owns each rule for each agent surface.
- Test conflicts with harmless tasks before using the instruction stack on production changes.
- Keep commercial, credential, model, and account-specific claims out of the instructions unless current official evidence supports them.
Failure modes
- Evidence gap: the agent cannot inspect the failing log, source page, pull request, or local command output. The safe action is to stop and record the missing evidence instead of guessing.
- Scope drift: the agent edits files that are not connected to the observed failure. Keep the repair tied to the failing signal and leave unrelated cleanup for a separate task.
- Environment mismatch: the local check uses different versions, credentials, feature flags, or runtime settings than the hosted path. Record the mismatch before treating the result as proof.
- Unreviewed fallback: the agent changes models, endpoints, permissions, or retry behavior to make a run pass without preserving the review boundary. Treat access and provider failures as operational blockers, not topic failures.
- Weak handoff: the final note says the issue is fixed but omits the command, result, changed files, and remaining uncertainty. That makes the next operator repeat the investigation.
Sources checked
- Official source evidence 1 - accessed 2026-07-19; purpose: verify source-backed claims for this guide.
- Claude Code memory documentation - accessed 2026-07-19; purpose: verify project memory and instruction-file context for agent workflows.
- GitHub Copilot repository instructions documentation - accessed 2026-07-19; purpose: verify repository instruction guidance.
- OpenAI Codex AGENTS.md guidance - accessed 2026-07-19; purpose: verify repository instruction-file context for coding agents.
Contract details to verify
| Area | What to verify | Source URL | Accessed | Safe candidate wording |
|---|---|---|---|---|
| Claude Code operating surface | Whether Claude Code is being used in terminal, IDE, desktop, or web for the repository task. | https://docs.anthropic.com/en/docs/claude-code | 2026-07-19 | “Claude Code can operate across documented coding surfaces, so confirm which surface your team is testing.” |
| Claude Code project instructions | Whether the project uses CLAUDE.md or related rule files for persistent guidance. | https://code.claude.com/docs/en/memory | 2026-07-19 | “Use Claude Code memory files for concise project guidance, then verify the agent restates the relevant rule.” |
| GitHub Copilot repository instructions | Whether repository custom instructions are configured in the documented GitHub location for Copilot. | https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions | 2026-07-19 | “Use GitHub’s repository instruction mechanism for Copilot-specific repository guidance.” |
| Codex repository instructions | Whether AGENTS.md is present and scoped for the work area. | https://github.com/openai/codex/blob/main/docs/agents_md.md | 2026-07-19 | “Use AGENTS.md for Codex-style repository instructions and keep its scope explicit.” |
| Cross-agent consistency | Whether the same safety, build, and review rules appear consistently without unsupported tool claims. | https://code.claude.com/docs/en/memory | 2026-07-19 | “Maintain a rule inventory and test each agent’s summary before assigning real changes.” |
Reader next step
Compare the workflow against Start with CometAPI .
FAQ
Should every instruction file contain the same text?
No. Keep the shared rule consistent, but adapt placement and wording to the instruction mechanism each tool documents. The inventory should explain which file owns each rule.
What is the safest first alignment check?
Ask each agent to summarize the rules it will follow for a harmless documentation task. A pass means the agent can identify the expected rules without touching production code.
How often should the instruction stack be reviewed?
Review it when a repository rule changes, when a new coding assistant is added, or when an agent output shows confusion about build, safety, review, or source-citation expectations.
Can this workflow prove an agent will always follow instructions?
No. It checks observable behavior for a bounded task. Keep the final decision tied to reviewable diffs, source evidence, and human-readable logs.
What should be left out of shared instruction files?
Do not include real credentials, private account details, unsupported model claims, pricing assumptions, or hidden tool behavior. Use placeholders and link to the official source that supports each operational claim.