agents-md-mapper
Skill104 starsChanged 8 months agoMITView on GitHub
This skill should be used when creating, refreshing, or validating a repository `AGENTS.md` so it stays concise, current, and grounded in repository evidence. Use when `AGENTS.md` is missing or stale, after refactors or tooling changes, when new docs become the system of record, or when adding lightweight drift checks.
In this repository7 other files it gives its agents.
- ast-grep-setupSkill
- differential-session-runnerSkill
- execute-phaseSkill
- harness-mapSkill
- plan-phaseSkill
- qa-from-executeSkill
- research-phaseSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
36 rules. About 0 are common, 34 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈34
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
Create a new AGENTS.md for a repository that does not have one
- Distinctive: line 31
Update the map after tooling, tests, CI, docs, or ownership signals changed
- Distinctive: line 33
Add lightweight checks that detect drift between AGENTS.md and repository reality
- Distinctive: line 39
Prefer roughly 90 to 100 lines
- Distinctive: line 40
Prefer bullets over paragraphs
- Distinctive: line 41
Prefer concrete paths and commands over abstract advice
- Distinctive: line 46
Read the repository tree before writing claims about structure
- Distinctive: line 47
Read actual config files before listing commands
- Distinctive: line 48
Read CI workflows before describing validation
- Distinctive: line 49
Read docs and architecture references before summarizing boundaries
- Distinctive: line 50
Read recent git history before carrying forward old paths or retired modules
- Distinctive: line 56
Remove stale or duplicated sections aggressively
- Distinctive: line 61
If evidence is weak, omit the claim
- Distinctive: line 62
If a detail is volatile, point to its source doc instead of embedding it
- Distinctive: line 63
If two docs disagree, prefer the one supported by current code and CI
- Distinctive: line 96
Check whether new docs or generated references replaced older explanations
- Distinctive: line 97
Check whether CI or task runners added or removed validation steps
- Distinctive: line 101
Verify that listed paths still exist
- Distinctive: line 102
Verify that listed commands still exist and still match task runner or CI usage
- Distinctive: line 103
Verify that architecture or package boundaries still match current layout
- Distinctive: line 104
Verify that linked docs still exist and remain the best source of truth
- Distinctive: line 108
Keep only high-value navigational content
- Distinctive: line 111
Remove outdated paths, retired tools, and stale historical detail
- Distinctive: line 116
Remove duplicate or unsupported claims
- Very specific: line 142
If a section grows past a few bullets, move detail to docs/ or another source doc and link to it
- Distinctive: line 143
If commands differ between docs and CI, prefer the version backed by current config
- Distinctive: line 144
If the repository already has a strong docs index, make AGENTS.md point to it rather than restating it
- Distinctive: line 145
If a repo has no evidence for ownership or architecture boundaries, do not invent them
- Very specific: line 154
Use the compact outline in references/agents-md-outline.md as a starting point when the repository supports those sections.
- Distinctive: line 158
Every listed path exists
- Distinctive: line 159
Every listed command is defined in current repo config or CI
- Distinctive: line 160
Every linked source-of-truth doc exists
- Distinctive: line 163
No secrets or environment values appear in the file
- Distinctive: line 167
When automation is requested, add lightweight drift checks such as:
- Distinctive: line 176
Consider the skill successful when:
- Distinctive: line 179
Every listed path and command matches the current repository
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
AGENTS.md Mapper
Overview
Maintain a concise, current AGENTS.md for a repository as the codebase changes. Treat the file as a navigational map for future coding agents: show where to start, where important things live, how to validate changes, and which deeper docs outrank the map.
When to Use
- Create a new
AGENTS.mdfor a repository that does not have one - Refresh an existing
AGENTS.mdthat may be stale after refactors, path moves, package splits, or architecture changes - Update the map after tooling, tests, CI, docs, or ownership signals changed
- Point
AGENTS.mdat new architecture docs, runbooks, or generated references that became the source of truth - Add lightweight checks that detect drift between
AGENTS.mdand repository reality
Core Contract
1. Keep the map compact
- Prefer roughly 90 to 100 lines
- Prefer bullets over paragraphs
- Prefer concrete paths and commands over abstract advice
- Link to deeper docs instead of copying them
2. Treat repository evidence as the source of truth
- Read the repository tree before writing claims about structure
- Read actual config files before listing commands
- Read CI workflows before describing validation
- Read docs and architecture references before summarizing boundaries
- Read recent git history before carrying forward old paths or retired modules
3. Optimize for agent legibility
- Surface entry points, domain boundaries, and validation commands first
- Make the navigation order obvious
- Remove stale or duplicated sections aggressively
- Normalize heading order so future updates stay mechanical
4. Omit unsupported detail
- If evidence is weak, omit the claim
- If a detail is volatile, point to its source doc instead of embedding it
- If two docs disagree, prefer the one supported by current code and CI
Inputs to Inspect
Inspect repository evidence, not guesswork:
- Current top-level tree and major subdirectories
- Key top-level files such as
README,pyproject.toml,package.json,Cargo.toml,Makefile,justfile, or task runner configs - Existing
AGENTS.md, if present ARCHITECTURE.md,docs/, runbooks, plans, references, and generated indexes- CI workflows and automation config
- Recent git history, especially merges, path renames, retired modules, and tooling changes
- Ownership signals such as
CODEOWNERS, package manifests, and boundary-enforcement config
Workflow
Step 1: Discover repository shape
- Collect the top-level tree and major subdirectories
- Identify package roots, module roots, and major domain folders
- Locate docs indexes, architecture docs, and runbooks
- Capture build, test, lint, and run entrypoints from real config files
Step 2: Read the current map and deeper docs
- Open
AGENTS.mdif it exists - Open the main onboarding docs first:
README, architecture docs, and docs indexes - Open the exact files that define task runner commands and CI gates
- Note which docs already serve as the system of record
Step 3: Inspect recent change signals
- Review recent git history for renamed paths, new packages, retired directories, and workflow changes
- Check whether new docs or generated references replaced older explanations
- Check whether CI or task runners added or removed validation steps
Step 4: Compare map versus reality
- Verify that listed paths still exist
- Verify that listed commands still exist and still match task runner or CI usage
- Verify that architecture or package boundaries still match current layout
- Verify that linked docs still exist and remain the best source of truth
Step 5: Rewrite for compression and clarity
- Keep only high-value navigational content
- Collapse repeated guidance into one canonical section
- Replace prose-heavy explanations with stable file paths and exact commands
- Remove outdated paths, retired tools, and stale historical detail
Step 6: Validate before finalizing
- Re-check every path and command
- Remove duplicate or unsupported claims
- Confirm the file remains short, scan-friendly, and grounded in current evidence
What to Put in AGENTS.md
Include these sections when repository evidence supports them:
- Project overview
- Where to start
- Repository map
- Build, test, lint, and run commands
- Architecture or package boundaries
- Key docs and sources of truth
- Change rules or contribution guardrails
- Validation checklist
Exclude these unless they directly change navigation or implementation behavior:
- Long architectural essays
- Full style guides already documented elsewhere
- Exhaustive dependency lists
- Historical detail that does not affect current navigation
- Issue triage policy that does not change implementation work
Decision Rules
- If a section grows past a few bullets, move detail to
docs/or another source doc and link to it - If commands differ between docs and CI, prefer the version backed by current config
- If the repository already has a strong docs index, make
AGENTS.mdpoint to it rather than restating it - If a repo has no evidence for ownership or architecture boundaries, do not invent them
Output Modes
Produce one of these outputs:
- A fresh
AGENTS.md - A focused patch for the existing
AGENTS.md
Use the compact outline in references/agents-md-outline.md as a starting point when the repository supports those sections.
Validation Checklist
- Every listed path exists
- Every listed command is defined in current repo config or CI
- Every linked source-of-truth doc exists
- Stale headings and duplicate sections are removed
- The file stays compact and navigable
- No secrets or environment values appear in the file
Recommended Follow-Up Checks
When automation is requested, add lightweight drift checks such as:
- Fail if a linked path in
AGENTS.mdno longer exists - Fail if a listed command disappears from CI or task runner config
- Flag missing references to new top-level domains after major tree changes
- Flag stale sections after large refactors or package moves
Success Criteria
Consider the skill successful when:
AGENTS.mdis short and easy to scan- Every listed path and command matches the current repository
- The file points to deeper sources of truth instead of copying them
- Stale guidance is removed
- Another coding agent can use
AGENTS.mdas a reliable repository map
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

