Understand Codebase

Help a developer understand an unfamiliar codebase by building a persistent, interlinked knowledge graph of markdown notes — one concept per note, cross-linked with [[wikilinks]] — and, optionally, by provisioning tools to explore that graph.

The output is not a one-off chat summary that evaporates when the session ends. It is a durable set of notes that lives in the target project, opens in any markdown/wiki reader (Obsidian, Foam, Quartz), grows as the code grows, and lets the developer — or a future Claude session — answer "how does this fit together?" by traversing links instead of re-reading the whole repo.

Synthesises three ideas: a staged scan → extract → link → tour analysis pipeline; the persistent-wiki discipline where the valuable work is the bookkeeping (cross-links, backlinks, freshness) and raw sources stay separate from generated notes; and a graph view front-end so the web of notes is browsable.

Two principles that govern everything below

1. Portable first, viewer optional. Always produce plain markdown with [[wikilinks]] and YAML frontmatter. The text is readable anywhere, but [[wikilinks]] render as clickable links only in wiki-aware tools (Obsidian, Foam, Quartz) — GitHub's web view and standard doc generators (MkDocs/Docusaurus/VitePress/Hugo) show them as literal text unless converted or plugin-enabled. A graph viewer (Quartz) is an additive, opt-in convenience, never a dependency. See references/note-format.md → "Portability" for the support matrix and conversion guidance.
2. Adaptive, not a fixed pipeline. Do not bulldoze through a heavy end-to-end process. Ask which capabilities the user wants (see Step 2) and provision only those. A user who only wants notes should never get a git hook installed.

This skill is read-only against the target's source code. It writes notes into a knowledge folder inside the target project; it never edits the project's source, and never writes into this skills repo.

Step 1 — When to use / when not to use