agentleFS
duthahoduthaho/skillhub/.claude/skills/map/SKILL.md

map

Skill9 starsChanged 15 days agoMITView on GitHub

Codebase orientation for an unfamiliar or large repo — "map this before I work in it." Fans out read-only Explore sub-agents that navigate the code (keyless — grep/glob/read, no embeddings to go stale) along the order that matters: entry points, build/test/lint commands, architecture and key abstractions, conventions and gotchas, test layout. Distills the findings into a lean AGENTS.md at the repo root — the cross-tool standard file many agents auto-load — where every claim points to a real file and nothing survives that isn't load-bearing. Human-in-the-loop: it drafts, you approve, and it never writes or commits into your repo without an explicit yes. Stamps the map with date + commit so /map refresh regenerates only what went stale. Use before working in a repo you or the agent don't know — e.g. "/map", "/map the auth subsystem", "generate an AGENTS.md", "/map refresh". Run it upstream of feature or bugfix; for the end-of-session shipping gate use done.

31 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ultragoal, cost and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Yeachan-HeoSkill

    ultragoal

    Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.

    Also in 3 projects that use this

  • maxvaegaSkill

    cost

    Estimate what Claude Cowork / Claude Code conversations would cost if run on the pay-per-token Claude API instead of the subscription. Reports token counts and cache-aware API cost in USD and EUR, for the current conversation or for the whole history (cost per conversation). Trigger when the user asks things like "how much would this conversation cost on the API", "API cost of my Cowork conversations", "token usage / token count", "cost per conversation", "/cost", or wants to compare subscription vs API pricing.

    Also in 3 projects that use this

  • marylinSkill

    recover

    Recover work from a crashed or interrupted session. Use when Claude crashed mid-task, after an unexpected exit, when you see 'stale sessions detected', or when you lost context and need to figure out what was happening.

    Also in 3 projects that use this

  • thoughtbotSkill

    trace

    Run a scenario and record what actually happened.

    Also in 4 projects that use this

  • iovisorSkill

    evolve

    Evolve uBPF through a gated spec-first workflow that propagates approved changes through requirements, design, validation, implementation, and RFC alignment artifacts.

    Also in 5 projects that use this

  • POSTTTTSkill

    tidy

    Clean up and organize a project's file structure — group loose files into logical folders (images/, scripts/, styles/, etc.), remove empty directories, and delete genuinely unnecessary files. Use when the user asks to "clean up the project", "organize the files", "tidy the directory", "sort these into folders", "remove empty folders", or "get rid of junk files". Always understands the project and updates references BEFORE moving anything, never deletes load-bearing files, and gets approval before changing the file tree.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 22 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Existing agent files?: Check for AGENTS.md, CLAUDE.md, .cursor/rules, .github/copilot-instructions.md.

    line 35
  2. Distinctive:

    Prefer signatures and paths over paragraphs.

    line 93
  3. Distinctive:

    Evidence is a path: No landmark, convention, or command without a locator or the command itself.

    line 156

“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “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

map — orient the agent to an unfamiliar codebase

/map — map the whole repo into a lean AGENTS.md at its root /map <subsystem> — deep-map one area, into a scoped section /map refresh — re-check an existing map and update only what went stale

Answer one question: what would a competent engineer need to know before touching this repo — and nothing more? The strongest lever in agentic coding isn't a smarter model, it's better orientation: an agent that knows the entry points, the build commands, and the load-bearing conventions makes the right change; one that guesses edits the wrong layer.

Step 0 — Scope, and respect what exists

First, look before generating:

  • Existing agent files? Check for AGENTS.md, CLAUDE.md, .cursor/rules, .github/copilot-instructions.md. If one exists, this is a REFRESH, not a fresh write — read it, and update in place rather than duplicating. If a CLAUDE.md already carries the knowledge, offer to have AGENTS.md @import it instead of restating it. If the existing map carries a stamp and HEAD has moved past it, state the drift in one line when naming the mode — "map is N commits behind (touched: X, Y)" via git rev-list --count + git diff --stat over <stamped-commit>..HEAD — and offer the refresh unless this run already is one. A stamp that no longer resolves (rebase, shallow clone) is itself the staleness signal: report it and offer a fresh map. Staleness surfaces at every touch, never only when someone remembers /map refresh.
  • Size the repo (git ls-files | wc -l, top-level layout) to scale the fan-out: a small repo maps in one pass inline; a large or polyglot one gets the full parallel sweep below.
  • A subsystem argument (/map the payment flow) narrows every step to that area and produces a scoped section, not a whole-repo rewrite.

State which mode you picked (NEW / REFRESH / FOCUS) and why.

Step 1 — Fan out along the read-first order

Dispatch read-only Explore sub-agents — one per lens — navigating by grep/glob/read and following imports (no embeddings, no pre-index; always fresh). This is the order practitioners converge on; run the lenses concurrently:

  1. Entry points & structure — how does execution start (main, routes, CLI, handlers)? Top-level module/package layout and what each directory is for.
  2. Build / test / lint commands — the knowledge no amount of code-reading reveals cheaply: the exact commands, from package.json scripts, Makefile, pyproject.toml, CI config. This is the single highest-value section.
  3. Architecture & key abstractions — the main entities/types, the layers and their boundaries, how data flows through, the 3–5 files that matter most.
  4. Conventions & gotchas — patterns the repo follows that deviate from the language default; footguns; "don't touch X"; implicit invariants a newcomer would break.
  5. Tests & fixtures — how tests are organized, where fixtures/factories live, the command that runs a single test.

Lossless hand-off: each sub-agent writes its full findings to out/map/.work/<lens>.md and returns a compact summary; you synthesize from the files, not the relay. Every finding names a file path — a landmark without a locator is a guess, and a guess in a map is worse than a blank.

Step 2 — Distill to a LEAN AGENTS.md

Now cut. A bloated agent file gets ignored — the failure this skill must not cause. For every candidate line apply the litmus test: would removing it make the agent make a mistake? If not, cut it. Keep:

  • What can't be guessed from reading code (commands, non-obvious conventions, gotchas, the "why" behind a structure).

Drop:

  • Anything a read of the code trivially reveals, generic best-practices, restated language docs, and prose where a file path would do.

Prefer signatures and paths over paragraphs. Target well under ~200 lines — shorter is stronger. Structure:

# AGENTS.md
<!-- mapped 2026-07-09 @ <commit sha> · regenerate with /map refresh -->

## What this is
<one paragraph: what the project does, its shape>

## Build, test, run
<the exact commands — the part no one can guess>

## Architecture
<layers, key abstractions, data flow — each with a file path>

## Conventions & gotchas
<the load-bearing, non-default rules; the footguns>

## Landmarks
<entry points, core files, where tests/fixtures live — as paths>

Step 3 — Approve, then write (never unprompted)

This file lands in the user's repo, so nothing is written without a yes:

  1. Show the full drafted AGENTS.md in chat and invite edits — cuts as much as additions.
  2. On approval, write it to the repo root (or update the existing file), stamped with today's date +%F and the current commit sha.
  3. Offer, don't perform, the commit — draft a message per the repo's convention, but committing and pushing wait for an explicit yes, same as every other skill here.
  4. Note that feature and bugfix will now read this file at the start of their runs — the map pays off downstream.

Auto mode (under autopilot): the draft→approve gate becomes write-and-log — the map is written and stamped, the run's log.md records what was generated and why, and committing still follows the run's charter.

On REFRESH: diff the map's claims against the current tree — flag sections whose cited files moved, changed shape, or vanished; regenerate only those; re-stamp. Don't rewrite what's still true. Command-shaped claims are re-proven by running them, not by checking that the paths they mention still exist — a command that no longer runs as claimed is stale even when every cited file is in place; update the claim to what actually happened. Read-only commands (test, lint, validate) run directly; state-changing ones (install, deploy, migrate) only via an explicit dry-run flag — no dry-run mode means the claim is marked unverified, never executed.

Guardrails

  • A wrong map is worse than none. A confident-but-stale line actively degrades the agent's reasoning. Every claim cites a file that exists; when unsure, leave it out and say so.
  • Lean or it's ignored. The litmus test is non-negotiable — cut ruthlessly.
  • Never write or commit unprompted. The output modifies the user's repo; draft → approve → write, and commit only on an explicit yes. (In auto mode, the autopilot charter is the prompt — the write is logged, not asked.)
  • Navigate, don't index. Keyless by design — grep/glob/read/LSP, no embeddings to leak or go stale. Re-derived-but-fresh beats cached-but-wrong.
  • Evidence is a path. No landmark, convention, or command without a locator or the command itself. The map is a set of verifiable pointers, not prose.
  • Respect what's there. An existing AGENTS.md/CLAUDE.md is updated, not bulldozed; manual edits by the user are preserved.

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.