Maintain AGENTS.md from repository evidence
Overview
Create or improve agent instructions that help a coding agent change the
repository correctly without rediscovering its workflow. Base every
repository-specific command, path, and rule on evidence in the current
checkout.
Prefer a focused diff over a wholesale rewrite. There is no universal line
limit, required section list, symlink layout, or commit-attribution policy;
follow the repository's own needs and maintainer intent.
When to Use
- The user asks to create, update, shorten, or audit
AGENTS.md.
- A monorepo needs root instructions plus narrower package-level overrides.
- Existing agent instructions contain stale commands, duplicated policy, or
unsupported claims.
- The user wants to reconcile
AGENTS.md with CLAUDE.md,
.github/copilot-instructions.md, or other repository instruction files.
Use @agents-generator instead when the task specifically calls for its
packaged generation modes, assets, or backup workflow. Use this skill when a
maintainer-readable, evidence-first edit is the primary goal.
How It Works
1. Preserve existing intent
Before writing, read every instruction file that applies to the target path,
including existing AGENTS.md files and relevant tool-specific files such as
CLAUDE.md, GEMINI.md, .github/copilot-instructions.md, and
.github/instructions/*.instructions.md.
- Improve an existing
AGENTS.md in place when possible.
- Preserve accurate maintainer-authored rules and repository-specific policy.
- Do not replace another tool's instruction file with a symlink unless the
user requests it and repository evidence shows identical content is desired.
- Do not silently choose between conflicting instructions. Follow the
higher-priority applicable rule, or ask when the intended policy cannot be
established from the repository.
2. Build a bounded evidence map
Inspect only enough of the repository to establish how work is actually done:
- Read the project overview and contribution guidance, such as
README*,
CONTRIBUTING*, and relevant docs.
- Read manifests, lockfiles, workspace files, task runners, and build config
to identify supported tools and exact commands.
- Read CI workflows to learn required checks. Do not assume every CI or
deployment job is safe or appropriate to run locally.
- Inspect representative source and test files for naming, layout, and test
conventions.
- Identify generated files, migrations, vendored code, large fixtures,
secrets boundaries, and production-only operations.
Prefer rg --files and rg for discovery when available. Track the source of
each non-obvious command or rule so unsupported claims do not enter the final
file.
3. Choose the instruction scope
Use the root AGENTS.md for repository-wide guidance. Add or revise a nested
AGENTS.md only when a subtree has materially different commands,
architecture, conventions, or safety boundaries.
Keep shared rules at the root and only differences in nested files. For tools
that implement the public AGENTS.md convention, the nearest file in the
directory tree controls the working subtree. Do not copy the full root file
into every package.
4. Write high-signal guidance
Choose headings that fit the repository instead of forcing a fixed template.
Include the following only when supported by evidence:
- Repository map: the few directories and boundaries an agent must know.
- Setup and commands: exact install, development, build, lint, type-check,
and test commands, with the working directory when it is not obvious.
- Focused validation: targeted checks for a small change and broader checks
required before handoff.
- Change rules: generated-file ownership, migrations, schemas, APIs,
dependencies, and cross-package coordination.
- Safety boundaries: secrets, production data, destructive commands,
deployments, and operations that require explicit authorization.
- Contribution rules: repository-specific naming, formatting, commit, or
pull-request requirements that affect implementation or handoff.
Write direct, testable statements. Prefer:
- From the repository root, run `npm test -- path/to/file.test.ts` for a focused test.
over:
- Make sure tests pass and follow best practices.
Link to maintained documentation instead of copying it. Distinguish required
checks from optional, slow, privileged, or deployment-only checks.
5. Validate before handoff
- Re-read each changed
AGENTS.md completely.
- Remove contradictions, duplicate rules, placeholders, and stale claims.
- Confirm every mentioned file and directory exists.
- Cross-check commands against manifests or CI, and run safe, proportionate
checks when useful.
- If nested files changed, confirm each contains only subtree-specific rules
and does not conflict accidentally with the root.
- Review the diff as a maintainer: every adde
1---2name: agents-md3description: Create, revise, or audit AGENTS.md files from repository evidence, verified commands, and correctly scoped instructions without overwriting maintainer intent.4---567# Maintain AGENTS.md from repository evidence89## Overview1011Create or improve agent instructions that help a coding agent change the12repository correctly without rediscovering its workflow. Base every13repository-specific command, path, and rule on evidence in the current14checkout.1516Prefer a focused diff over a wholesale rewrite. There is no universal line17limit, required section list, symlink layout, or commit-attribution policy;18follow the repository's own needs and maintainer intent.1920## When to Use2122- The user asks to create, update, shorten, or audit `AGENTS.md`.23- A monorepo needs root instructions plus narrower package-level overrides.24- Existing agent instructions contain stale commands, duplicated policy, or25 unsupported claims.26- The user wants to reconcile `AGENTS.md` with `CLAUDE.md`,27 `.github/copilot-instructions.md`, or other repository instruction files.2829Use `@agents-generator` instead when the task specifically calls for its30packaged generation modes, assets, or backup workflow. Use this skill when a31maintainer-readable, evidence-first edit is the primary goal.3233## How It Works3435### 1. Preserve existing intent3637Before writing, read every instruction file that applies to the target path,38including existing `AGENTS.md` files and relevant tool-specific files such as39`CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`, and40`.github/instructions/*.instructions.md`.4142- Improve an existing `AGENTS.md` in place when possible.43- Preserve accurate maintainer-authored rules and repository-specific policy.44- Do not replace another tool's instruction file with a symlink unless the45 user requests it and repository evidence shows identical content is desired.46- Do not silently choose between conflicting instructions. Follow the47 higher-priority applicable rule, or ask when the intended policy cannot be48 established from the repository.4950### 2. Build a bounded evidence map5152Inspect only enough of the repository to establish how work is actually done:53541. Read the project overview and contribution guidance, such as `README*`,55 `CONTRIBUTING*`, and relevant docs.562. Read manifests, lockfiles, workspace files, task runners, and build config57 to identify supported tools and exact commands.583. Read CI workflows to learn required checks. Do not assume every CI or59 deployment job is safe or appropriate to run locally.604. Inspect representative source and test files for naming, layout, and test61 conventions.625. Identify generated files, migrations, vendored code, large fixtures,63 secrets boundaries, and production-only operations.6465Prefer `rg --files` and `rg` for discovery when available. Track the source of66each non-obvious command or rule so unsupported claims do not enter the final67file.6869### 3. Choose the instruction scope7071Use the root `AGENTS.md` for repository-wide guidance. Add or revise a nested72`AGENTS.md` only when a subtree has materially different commands,73architecture, conventions, or safety boundaries.7475Keep shared rules at the root and only differences in nested files. For tools76that implement the public AGENTS.md convention, the nearest file in the77directory tree controls the working subtree. Do not copy the full root file78into every package.7980### 4. Write high-signal guidance8182Choose headings that fit the repository instead of forcing a fixed template.83Include the following only when supported by evidence:8485- **Repository map:** the few directories and boundaries an agent must know.86- **Setup and commands:** exact install, development, build, lint, type-check,87 and test commands, with the working directory when it is not obvious.88- **Focused validation:** targeted checks for a small change and broader checks89 required before handoff.90- **Change rules:** generated-file ownership, migrations, schemas, APIs,91 dependencies, and cross-package coordination.92- **Safety boundaries:** secrets, production data, destructive commands,93 deployments, and operations that require explicit authorization.94- **Contribution rules:** repository-specific naming, formatting, commit, or95 pull-request requirements that affect implementation or handoff.9697Write direct, testable statements. Prefer:9899```markdown100- From the repository root, run `npm test -- path/to/file.test.ts` for a focused test.101```102103over:104105```markdown106- Make sure tests pass and follow best practices.107```108109Link to maintained documentation instead of copying it. Distinguish required110checks from optional, slow, privileged, or deployment-only checks.111112### 5. Validate before handoff1131141. Re-read each changed `AGENTS.md` completely.1152. Remove contradictions, duplicate rules, placeholders, and stale claims.1163. Confirm every mentioned file and directory exists.1174. Cross-check commands against manifests or CI, and run safe, proportionate118 checks when useful.1195. If nested files changed, confirm each contains only subtree-specific rules120 and does not conflict accidentally with the root.1216. Review the diff as a maintainer: every adde