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] \
    [--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, falls back to the builtin
  extractor otherwise; force builtin for the dependency-free path, or codegraph to require
  the enhanced backend (fails loudly if it's not installed rather than silently degrading).
• --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.