SpecGraph runs a multi-agent pipeline that reads your codebase, generates structured spec files for every layer, and stitches them into a navigable knowledge graph.
The main agent reads the entire codebase. Identifies languages, frameworks, tooling, libraries. Then spawns parallel researcher agents — one per category — to build rubric items for how that specific technology should be documented.
Main agent receives all rubric compilations, groups them by domain (e.g., auth system, data layer, UI components), then spawns spec-writer agents — one per cluster. Each writes structured spec files covering architecture, lifecycle, and feature mapping.
Main agent waits until all spec files are written, then reads every one. Cross-references are resolved. Dependencies are annotated. The output is a unified spec graph where each document knows and references the others — not just files on disk, but a living knowledge map.
Most tools generate isolated documents. SpecGraph's stitcher reads all outputs and resolves the web of dependencies — so auth.spec.md references the token schema in db.spec.md, and api.spec.md links to the session lifecycle in auth.spec.md. No orphan docs. No guesswork.
Every spec follows a consistent structure: architecture overview, lifecycle diagrams, feature mapping, and dependency list. Readers always know where to look.
Rubric items adapt to what your codebase actually uses — not generic descriptions. React gets hooks documentation. NestJS gets module metadata. Python gets class and decorator mapping.
No more manually linking docs. The stitcher reads all specs and injects cross-references — so auth.spec.md knows it depends on db.spec.md's token schema and api.spec.md's guard middleware.
Researcher and spec-writer agents run in parallel — not sequentially. A 50-module codebase doesn't mean 50 minutes. Agents operate concurrently against their assigned domain, converging at the stitcher stage.
The final output isn't a flat directory of markdown files. It's a spec graph — with a navigable index that shows which specs depend on which, what changed in the last run, and what to update before making a change.
Re-running SpecGraph on an evolving codebase updates only the specs that changed — not the entire directory. The main agent diffs the last run state against the new codebase state and touches only the affected spec clusters.
Every brownfield codebase is a minefield of implicit knowledge — architecture decisions, dependency patterns, side effects that only the person who wrote them understands. SpecGraph makes that knowledge explicit, structured, and navigable.
Not a documentation tool. An autonomy layer for how your team understands what it actually runs.