How the graph gets built
Two passes
Section titled “Two passes”Graft builds the graph in two passes, both powered by a language model:
- Read each file. Every source file is summarized once into a short description of what it does.
- Group into nodes. Those summaries are grouped into a curated set of nodes (subsystems, key files, and concepts) with typed links between them. Graft chooses the right level of detail for you instead of making one node per file, so a big repo becomes a few dozen readable nodes.
Caching
Section titled “Caching”Every pass is cached by content hash — the LLM ones and the tree-sitter parse alike. Re-running only touches the files that changed, so the second build is fast and cheap:
| Scenario | Time |
|---|---|
| Cold build (124 files) | 0.74s |
| One edited file | 0.18s |
| Nothing changed | 0.18s |
graft build --no-reuse forces a cold re-parse.
Auto-refresh
Section titled “Auto-refresh”That cheapness is what lets every query refresh the graph before it answers. A retrieval call stats the tree against the last build’s fingerprint (~3ms), and rebuilds only if something moved — so ask/grep/callers/skeleton/map describe the code as it is right now, including edits that are unsaved to git: uncommitted, unstaged, or staged all look the same to graft, which never reads git at all.
The code graph
Section titled “The code graph”Alongside the markdown graph, graft build builds graft/.graph/wiring.json — a per-symbol code graph — plus a per-file wiring card mirroring your source tree.
| Tier | What it produces | Requires |
|---|---|---|
| Tier 1 (tree-sitter) | Every function, class, and call edge; deterministic | No model, no network |
--deep (LLM) |
One-line summary and a crux excerpt per symbol, cached by body hash | Provider key |