agentleFS
alchemiststudiosDOTaialchemiststudiosDOTai/harness-engineering/skills/agents-md-mapper/SKILL.md

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.

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
  1. Distinctive:

    Create a new AGENTS.md for a repository that does not have one

    line 29
  2. Distinctive:

    Update the map after tooling, tests, CI, docs, or ownership signals changed

    line 31
  3. Distinctive:

    Add lightweight checks that detect drift between AGENTS.md and repository reality

    line 33
  4. Distinctive:

    Prefer roughly 90 to 100 lines

    line 39
  5. Distinctive:

    Prefer bullets over paragraphs

    line 40
  6. Distinctive:

    Prefer concrete paths and commands over abstract advice

    line 41
  7. Distinctive:

    Read the repository tree before writing claims about structure

    line 46
  8. Distinctive:

    Read actual config files before listing commands

    line 47
  9. Distinctive:

    Read CI workflows before describing validation

    line 48
  10. Distinctive:

    Read docs and architecture references before summarizing boundaries

    line 49
  11. Distinctive:

    Read recent git history before carrying forward old paths or retired modules

    line 50
  12. Distinctive:

    Remove stale or duplicated sections aggressively

    line 56
  13. Distinctive:

    If evidence is weak, omit the claim

    line 61
  14. Distinctive:

    If a detail is volatile, point to its source doc instead of embedding it

    line 62
  15. Distinctive:

    If two docs disagree, prefer the one supported by current code and CI

    line 63
  16. Distinctive:

    Check whether new docs or generated references replaced older explanations

    line 96
  17. Distinctive:

    Check whether CI or task runners added or removed validation steps

    line 97
  18. Distinctive:

    Verify that listed paths still exist

    line 101
  19. Distinctive:

    Verify that listed commands still exist and still match task runner or CI usage

    line 102
  20. Distinctive:

    Verify that architecture or package boundaries still match current layout

    line 103
  21. Distinctive:

    Verify that linked docs still exist and remain the best source of truth

    line 104
  22. Distinctive:

    Keep only high-value navigational content

    line 108
  23. Distinctive:

    Remove outdated paths, retired tools, and stale historical detail

    line 111
  24. Distinctive:

    Remove duplicate or unsupported claims

    line 116
  25. Very specific:

    If a section grows past a few bullets, move detail to docs/ or another source doc and link to it

    line 142
  26. Distinctive:

    If commands differ between docs and CI, prefer the version backed by current config

    line 143
  27. Distinctive:

    If the repository already has a strong docs index, make AGENTS.md point to it rather than restating it

    line 144
  28. Distinctive:

    If a repo has no evidence for ownership or architecture boundaries, do not invent them

    line 145
  29. Very specific:

    Use the compact outline in references/agents-md-outline.md as a starting point when the repository supports those sections.

    line 154
  30. Distinctive:

    Every listed path exists

    line 158
  31. Distinctive:

    Every listed command is defined in current repo config or CI

    line 159
  32. Distinctive:

    Every linked source-of-truth doc exists

    line 160
  33. Distinctive:

    No secrets or environment values appear in the file

    line 163
  34. Distinctive:

    When automation is requested, add lightweight drift checks such as:

    line 167
  35. Distinctive:

    Consider the skill successful when:

    line 176
  36. Distinctive:

    Every listed path and command matches the current repository

    line 179

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
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.md for a repository that does not have one
  • Refresh an existing AGENTS.md that 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.md at new architecture docs, runbooks, or generated references that became the source of truth
  • Add lightweight checks that detect drift between AGENTS.md and 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.md if 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.md point 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.md no 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.md is 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.md as a reliable repository map

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.