agentleFS
Ar9avAr9av/obsidian-wiki/skills/code-understand/SKILL.md

code-understand

Skill3.7k starsChanged 7 days agoMITView on GitHub

Map the load-bearing files, symbols, callers, and dependencies of an unfamiliar codebase before making changes. Use for architecture orientation, impact analysis, what-would-break questions, or finding callers. Uses CodeGraph when available and a dependency-free builtin fallback.

  • Installs packages

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Who's talking about Ar9av/obsidian-wiki

The biggest 5 of 27 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 27

Talked about on GitHub and Bluesky (27 times).

On GitHub · 25

20 more on GitHub

On Bluesky · 2

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before editing an unfamiliar module — see what calls it and what it calls before changing its shape.

    line 16
  2. Very specific:

    Not for: summarizing what a project *does* for the wiki (that's wiki-update Step 3b, which calls this same command as part of a bigger sync …

    line 25
  3. Distinctive:

    GUARD: if the command is unavailable or errors, skip it and fall back to your normal exploration (grep/read) — this is an accelerant, not a …

    line 50
  4. Very specific:

    Evidence type matters: When backend: codegraph, focus-map entries are structural facts (real call-graph edges) — cite them directly.

    line 55
  5. Very specific:

    Cite it in your own output: If you explain the architecture back to the user or write it into a PR description/commit message, keep the …

    line 62
  6. Very specific:

    It's a cache, not a deliverable: Never write the raw JSON or .codegraph/ into the wiki vault, a PR description, or committed docs — it's a …

    line 65
  7. Very specific:

    Check obsidian-wiki doctor --project <dir> for the code-understanding.* capability lines (builtin, rg, codegraph, codegraph-index, …

    line 81

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

Code Understand — On-Demand Architecture Focus Map

You are about to work in a codebase you don't fully know yet. Instead of grepping around or reading files at random, ask the local extractor for a focus map: the ranked symbols the architecture hangs on, each with a file:line citation and evidence type. Read only what it points at — this is a map, not a substitute for reading the actual code it cites.

When to reach for this

  • Before editing an unfamiliar module — see what calls it and what it calls before changing its shape.
  • The user asks "how does X work", "what's the impact of changing Y", "who else uses this function" for a codebase, not the wiki.
  • You're about to do a large refactor and want a ranked list of load-bearing files instead of reading the whole tree.
  • You already have a diff or a set of changed files and want to know their blast radius before finishing the change.

Not for: summarizing what a project does for the wiki (that's wiki-update Step 3b, which calls this same command as part of a bigger sync flow) — use this skill directly only when you need the focus map for your own immediate work, not to persist knowledge.

Running it

obsidian-wiki code-understand --project <dir> [--backend auto|builtin|codegraph|graphify] \
    [--changed <file>...] [--since <sha>] [--max-symbols N] [--pretty]
  • --project — defaults to the current directory.
  • No --changed/--since — seeds from every tracked file (full-project scan).
  • --changed <file> (repeatable) — seed from specific files you already know are relevant (e.g. files in the diff you're about to make).
  • --since <sha> — seed from everything changed since a git ref (e.g. --since HEAD~5 or a base branch).
  • --backend — auto (default) uses CodeGraph when installed, then an existing Graphify graph (graphify-out/graph.json, read only — never rebuilt), and falls back to the builtin extractor otherwise; force builtin for the dependency-free path, codegraph to require the enhanced backend (fails loudly if it's not installed rather than silently degrading), or graphify to require the Graphify graph.
  • --max-symbols — cap the focus map size (default 50); keep this small for a quick orientation pass, raise it for a thorough one.

GUARD: if the command is unavailable or errors, skip it and fall back to your normal exploration (grep/read) — this is an accelerant, not a dependency. Don't block work on it.

Reading the output

  1. Evidence type matters. When backend: codegraph, focus-map entries are structural facts (real call-graph edges) — cite them directly. When backend: builtin, defines/ imports/changed-file entries are facts, but rg-reference entries are text-match evidence only — open the file and confirm before treating it as a real relationship.
  2. Open what it cites, nothing else first. The focus map tells you where to read; it never contains source bodies. Go read those file:line locations before forming an opinion on the architecture.
  3. Cite it in your own output. If you explain the architecture back to the user or write it into a PR description/commit message, keep the (file:lines) citations from the focus map or from the source you opened — don't assert structure without a pointer to it.
  4. It's a cache, not a deliverable. Never write the raw JSON or .codegraph/ into the wiki vault, a PR description, or committed docs — it's a disposable sidecar in the project repo (git-ignored). Re-run it fresh next time rather than treating old output as durable.

If CodeGraph isn't installed

auto/builtin still work with zero setup (uses the regex AST extractor + rg). If you want the enhanced cross-file call-graph evidence and the user is fine with installing something:

npm install -g @colbymchenry/codegraph

or point CODE_UNDERSTANDING_CODEGRAPH_BIN at an existing binary. Never install without the user's go-ahead — ask first, then re-run the command.

Check obsidian-wiki doctor --project <dir> for the code-understanding.* capability lines (builtin, rg, codegraph, codegraph-index, codegraph-fresh, codegraph-gitignore) to see what's available before deciding which backend to request explicitly.

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.