agentleFS
JordanCoinJordanCoin/codemap/.claude/skills/config-setup/SKILL.md

config-setup

Skill710 starsChanged 8 months agoMITView on GitHub

Set up or tune .codemap/config.json so Codemap focuses on code-relevant parts of the repo. Use when config is missing, boilerplate, noisy, or mismatched to the stack.

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 10 are distinctive, and 10 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 10

    Very specific

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

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

    Run codemap config show to see the current state.

    line 12
  2. Very specific:

    Write or tune .codemap/config.json using the workflow below: keep source extensions in only, add exclude for real noise, set depth if the …

    line 13
  3. Very specific:

    Verify one known cross-file dependency still resolves with codemap --importers <file>.

    line 15
  4. Very specific:

    Write or improve .codemap/config.json so future Codemap calls stay focused on the code that matters for this repo.

    line 21
  5. Distinctive:

    Read the root and applicable nested AGENTS.md files before deciding ownership or scope

    line 33
  6. Very specific:

    Read language workspace manifests such as Cargo.toml.

    line 34
  7. Very specific:

    If needed, run codemap --deps .

    line 36
  8. Distinctive:

    Write a conservative code-first config

    line 45
  9. Very specific:

    Keep primary source-language only values when they help

    line 46
  10. Very specific:

    Add exclude entries for obvious non-code noise

    line 47
  11. Distinctive:

    Avoid overfitting or excluding real source directories

    line 49
  12. Distinctive:

    If config already looks curated, do not replace it wholesale

    line 60
  13. Very specific:

    If the repo still looks noisy, refine exclude and possibly depth

    line 65
  14. Very specific:

    Only rerun codemap --deps .

    line 66
  15. Distinctive:

    Verify at least one known cross-layer dependency remains discoverable after tuning

    line 67
  16. Distinctive:

    Prefer directory exclusions over extension-only exclusions when the directory is clearly not core to the codebase

    line 72
  17. Distinctive:

    Do not exclude tests just because they are large

    line 73
  18. Distinctive:

    Do not exclude docs that are part of routing or subsystem understanding

    line 74
  19. Distinctive:

    Keep the first config conservative.

    line 75
  20. Distinctive:

    After tuning config, briefly report:

    line 101

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

Codemap Config Setup

When this skill is matched at score 100, do this BEFORE the user's task, then continue the task

A score of 100 means a hook found the config missing, empty, malformed, or boilerplate. Fix it first; it takes under a minute and every later Codemap answer depends on it.

  1. Run codemap config show to see the current state. If it says missing, run codemap config init (most commands now do this for you).
  2. Write or tune .codemap/config.json using the workflow below: keep source extensions in only, add exclude for real noise, set depth if the tree is wide.
  3. Rerun codemap . and confirm the tree is dominated by source, not assets.
  4. Verify one known cross-file dependency still resolves with codemap --importers <file>.

Then return to the user's task. Do not skip this because the task looks small.

Goal

Write or improve .codemap/config.json so future Codemap calls stay focused on the code that matters for this repo.

Use this when

  1. .codemap/config.json is missing
  2. The existing config looks like a bare bootstrap instead of a real project policy
  3. Codemap output is dominated by assets, fixtures, generated files, vendor trees, PDFs, screenshots, models, or training data
  4. The project stack is obvious, but Codemap is not prioritizing the right parts of the repo

Workflow

  1. Inspect the repo quickly before writing config
    • Read the root and applicable nested AGENTS.md files before deciding ownership or scope
    • Read language workspace manifests such as Cargo.toml; preserve every declared workspace member
    • Run codemap .
    • If needed, run codemap --deps .
    • Note the stack markers (Cargo.toml, Package.swift, *.xcodeproj, go.mod, package.json, pyproject.toml, etc.)
    • Identify large non-code directories and noisy extensions
  2. Decide whether config is missing, boilerplate, or tuned
    • Missing: no .codemap/config.json
    • Boilerplate: only generic only values, no real shaping, no excludes despite obvious noise
    • Tuned: contains intentional project-specific includes/excludes, depth, or routing hints
  3. Write a conservative code-first config
    • Keep primary source-language only values when they help
    • Add exclude entries for obvious non-code noise
    • Set a moderate depth when the repo is broad
    • Avoid overfitting or excluding real source directories
  4. Prefer stack-aware defaults
    • Rust: focus src, tests, benches, examples; de-prioritize corpora, sample PDFs, training data, large generated artifacts
    • For Cargo workspaces, keep all workspace members' src, tests, benches, and examples trees unless repository evidence explicitly excludes one
    • iOS/Swift: focus app/framework source, tests, package/project manifests; de-prioritize .xcassets, screenshots, snapshots, vendor/build outputs
    • TS/JS: focus src, apps, packages, tests; de-prioritize dist, coverage, Storybook assets, large fixture payloads
    • Python: focus package roots, tests, tool config; de-prioritize notebooks, data dumps, models, fixtures when they overwhelm code
    • Go: focus packages, cmd, internal, tests; de-prioritize generated assets, sample data, vendor-like noise
  5. Preserve user intent
    • If config already looks curated, do not replace it wholesale
    • Make minimal edits and explain why
  6. Verify immediately
    • Rerun codemap .
    • If the repo still looks noisy, refine exclude and possibly depth
    • Only rerun codemap --deps . after tree output looks reasonable
    • Verify at least one known cross-layer dependency remains discoverable after tuning

Heuristics

  • Exclude giant non-code directories before narrowing source extensions further
  • Prefer directory exclusions over extension-only exclusions when the directory is clearly not core to the codebase
  • Do not exclude tests just because they are large
  • Do not exclude docs that are part of routing or subsystem understanding
  • Keep the first config conservative; optimize further only if the output remains noisy

Example outcomes

Rust library with large fixture data

{
  "only": ["rs", "toml", "md"],
  "exclude": ["training-data", "test-pdfs", "*.pdf"],
  "depth": 4
}

iOS app with asset bloat

{
  "only": ["swift", "m", "mm", "h", "plist", "md"],
  "exclude": [".xcassets", "Snapshots", "Screenshots", "DerivedData"],
  "depth": 4
}

Output expectations

After tuning config, briefly report:

  1. Why the old config was missing or too noisy
  2. What exclusions or depth choices you added
  3. Whether future Codemap runs should now be materially cleaner

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.