agents-md-mapper

star 104

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.

alchemiststudiosDOTai By alchemiststudiosDOTai schedule Updated 3/12/2026

name: agents-md-mapper description: 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. allowed-tools: - Read - Write - Edit - Glob - Grep - Bash(git:) - Bash(ls:) hard-guards: - Treat AGENTS.md as a map, not a dump - Update only from repository evidence: files, docs, CI, commands, and git history - Prefer stable paths and exact commands over prose-heavy explanation - Keep AGENTS.md roughly under 100 lines unless repo complexity clearly requires more - Omit weak or speculative claims - Never include secrets, tokens, credentials, or environment values

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
Install via CLI
npx skills add https://github.com/alchemiststudiosDOTai/harness-engineering --skill agents-md-mapper
Repository Details
star Stars 104
call_split Forks 12
navigation Branch main
article Path SKILL.md
More from Creator
alchemiststudiosDOTai
alchemiststudiosDOTai Explore all skills →