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.
In this repository7 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- codemapSkill
- exploreSkill
- handoffSkill
- hub-safetySkill
- refactorSkill
- test-firstSkill
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
- Very specific: line 12
Run codemap config show to see the current state.
- Very specific: line 13
Write or tune .codemap/config.json using the workflow below: keep source extensions in only, add exclude for real noise, set depth if the …
- Very specific: line 15
Verify one known cross-file dependency still resolves with codemap --importers <file>.
- Very specific: line 21
Write or improve .codemap/config.json so future Codemap calls stay focused on the code that matters for this repo.
- Distinctive: line 33
Read the root and applicable nested AGENTS.md files before deciding ownership or scope
- Very specific: line 34
Read language workspace manifests such as Cargo.toml.
- Very specific: line 36
If needed, run codemap --deps .
- Distinctive: line 45
Write a conservative code-first config
- Very specific: line 46
Keep primary source-language only values when they help
- Very specific: line 47
Add exclude entries for obvious non-code noise
- Distinctive: line 49
Avoid overfitting or excluding real source directories
- Distinctive: line 60
If config already looks curated, do not replace it wholesale
- Very specific: line 65
If the repo still looks noisy, refine exclude and possibly depth
- Very specific: line 66
Only rerun codemap --deps .
- Distinctive: line 67
Verify at least one known cross-layer dependency remains discoverable after tuning
- Distinctive: line 72
Prefer directory exclusions over extension-only exclusions when the directory is clearly not core to the codebase
- Distinctive: line 73
Do not exclude tests just because they are large
- Distinctive: line 74
Do not exclude docs that are part of routing or subsystem understanding
- Distinctive: line 75
Keep the first config conservative.
- Distinctive: line 101
After tuning config, briefly report:
≈ “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.
Files
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.
- Run
codemap config showto see the current state. If it says missing, runcodemap config init(most commands now do this for you). - Write or tune
.codemap/config.jsonusing the workflow below: keep source extensions inonly, addexcludefor real noise, setdepthif the tree is wide. - Rerun
codemap .and confirm the tree is dominated by source, not assets. - 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
.codemap/config.jsonis missing- The existing config looks like a bare bootstrap instead of a real project policy
- Codemap output is dominated by assets, fixtures, generated files, vendor trees, PDFs, screenshots, models, or training data
- The project stack is obvious, but Codemap is not prioritizing the right parts of the repo
Workflow
- Inspect the repo quickly before writing config
- Read the root and applicable nested
AGENTS.mdfiles 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
- Read the root and applicable nested
- Decide whether config is missing, boilerplate, or tuned
- Missing: no
.codemap/config.json - Boilerplate: only generic
onlyvalues, no real shaping, no excludes despite obvious noise - Tuned: contains intentional project-specific includes/excludes, depth, or routing hints
- Missing: no
- Write a conservative code-first config
- Keep primary source-language
onlyvalues when they help - Add
excludeentries for obvious non-code noise - Set a moderate
depthwhen the repo is broad - Avoid overfitting or excluding real source directories
- Keep primary source-language
- 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, andexamplestrees 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-prioritizedist,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
- Rust: focus
- Preserve user intent
- If config already looks curated, do not replace it wholesale
- Make minimal edits and explain why
- Verify immediately
- Rerun
codemap . - If the repo still looks noisy, refine
excludeand possiblydepth - Only rerun
codemap --deps .after tree output looks reasonable - Verify at least one known cross-layer dependency remains discoverable after tuning
- Rerun
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:
- Why the old config was missing or too noisy
- What exclusions or depth choices you added
- Whether future Codemap runs should now be materially cleaner
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
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.

