Agent skill
agents-md-mapper
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.
Install this agent skill to your Project
npx add-skill https://github.com/alchemiststudiosDOTai/harness-engineering/tree/main/skills/agents-md-mapper
SKILL.md
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
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
differential-session-runner
Run or continue a differential debugging session between two implementations, traces, captures, or outputs. Record artifact identity, exact commands, first mismatch progression, findings, validation, and next probe in a durable session log.
ast-grep-setup
Set up ast-grep for a codebase with common TypeScript rules for detecting anti-patterns, enforcing best practices, and preventing bugs. Creates sgconfig.yml, rule files, and rule tests. Use when adding structural linting, banning legacy patterns, or implementing ratchet gates.
research-phase
This skill should be used when mapping or researching a codebase to understand its structure, patterns, and architecture. Use when the user asks to "map the codebase", "research how X works", "find all Y patterns", or needs to understand code organization. Produces factual structural maps in .artifacts/research/—no suggestions, no recommendations, just what exists. Uses ast-grep for structural pattern matching.
plan-phase
Generate execution-ready implementation plans from research docs - planning ONLY, no fixing or verifying. North Star is whether a JR developer can execute the plan with zero additional context.
execute-phase
Execute implementation plans from .artifacts/plan/. Focus on EXECUTING ONLY - no planning, no fixes outside plan scope. Uses gated checks, atomic commits, and maintains a single execution log in .artifacts/execute/. Use when the user says "execute this plan" or provides a plan path.
qa-from-execute
Perform quality assurance on code changes after the research-phase -> plan-phase -> execute-phase workflow. STRICTLY QA only—no coding, no fixes, no source-code changes. Focus on changed areas only, emphasizing control/data flow correctness.
Didn't find tool you were looking for?