Free field guide · public repositories
Put each agent rule in the file that can actually reach it.
AGENTS.md vs CLAUDE.md vs Copilot instructions is not a contest. Each file has a different audience. The durable pattern is one shared source of repository truth with thin, tool-specific adapters.
Public evidence only · No login for the preflight · No repository code execution
- Cross-tool repository rules
- AGENTS.md
- Claude-only behavior
- CLAUDE.md
- Copilot-only behavior
- copilot
- Duplicated shared policy
- 0
rule canonical shared facts → thin adapters
Choose by audience
Three files. Three jobs.
Start with the rule’s intended reader. If every coding agent needs it, the rule should not begin life in a vendor-specific file.
Root AGENTS.md
Use it for repository-wide setup, architecture, workflow, verification, ownership, and risky-action gates that should reach multiple agent tools.
Root CLAUDE.md
Use it for Claude-specific imports, hooks, commands, or interaction guidance. Point to shared rules instead of copying them when the harness supports that pattern.
.github/copilot-instructions.md
Use it for repository-wide GitHub Copilot behavior. Keep path-specific guidance in the supported path-scoped instruction surfaces rather than inflating the global file.
-
01
Name the canonical owner
For every repeated rule, choose one file or committed source as authoritative.
-
02
Make adapters visibly thin
Tool-specific files should point, import, or restate only the minimum needed for that harness.
-
03
Keep volatile facts out of copies
Commands, paths, versions, and release rules drift fastest; do not duplicate them casually.
-
04
Check the actual readers
A well-written file is useless when the intended agent never reads that path.
-
05
Fail honestly on missing evidence
Do not invent setup, test, deployment, or approval procedures merely to make guidance look complete.
Review before merge
A five-minute drift check.
- 01
Paths resolve
Every named file, directory, script, and documentation link exists at the reviewed revision.
- 02
Commands are evidenced
Setup and verification commands come from committed public sources, not convention or memory.
- 03
Rules do not conflict
Branch, commit, testing, release, and approval instructions agree across the files agents can read.
- 04
One source owns change
A future maintainer can tell where to edit each shared rule without updating three copies.
Keep sensitive facts outside the repository
Instructions are not a secret store.
Never put secrets, private infrastructure, or undocumented commands into public agent files. Describe the approval boundary, not the credential.
Run the free repository preflight- ✓ Public setup and verification evidence
- ✓ Repository ownership and review boundaries
- ✓ Explicit approval gates for risky actions
- × No credentials, tokens, private URLs, or customer data
- × No invented commands or implied production access
- × No security, legal, privacy, or compliance guarantees
Common decisions
Direct answers.
Should CLAUDE.md duplicate AGENTS.md?
Usually no. Keep shared repository facts canonical and add only Claude-specific behavior that another agent would not need.
Can a repository use all three files?
Yes, when each file has a distinct reader and responsibility. The problem is contradictory ownership, not the file count.
Should undocumented commands be added as recommendations?
No. Mark the evidence gap and ask a maintainer to establish the command in a canonical public source first.
Does the free preflight execute repository code?
No. WrightOps does not clone or execute the target repository. The browser reads public GitHub evidence only.
One repository · one canonical rule set
Check the evidence before adding another instruction file.
Start with the no-login public-repository preflight. If you want a bounded two-file contribution, inspect the $249 service page, sample, boundaries, and written-scope process before requesting work.
This guide is operational information, not a security, legal, privacy, or compliance assessment.