Corbell

A CLI that generates architecture design specs from a knowledge graph of your own code. Python 3.11+, Apache-2.0, pip install corbell[anthropic]; v1.2.0 (2026-05-23), 435 stars / 46 forks at the time of ingest. Aimed at backend teams running multiple repositories.

Its problem statement is an organizational one, not a coding one: “Every quarter your team re-litigates the same architectural decisions” because those decisions live scattered across Confluence, Slack, and people’s memories, so a new joiner or a dormant service means “starting from scratch.”

The pipeline

Four stages. Graph build — scan the repos with tree-sitter (Python, TypeScript, Go, Java, C#, Rust, Ruby, PHP) and extract service dependencies, typed method signatures, call graphs and execution flows. Embed — chunk the code with sentence-transformers/all-MiniLM-L6-v2 for semantic search. Generate — take a natural-language feature description or a PRD, auto-discover which services it touches, and hand the graph context plus the relevant snippets to Claude or GPT-4o. Review and export — validate the spec against recorded architecture constraints, then push tasks to Linear or Jira.

Everything runs locally: SQLite by default (Neo4j optional), a stdlib HTTP server with a D3.js graph browser at corbell ui serve, and an MCP server so Cursor or Claude Desktop can query the graph. “No servers. No cloud setup. Runs entirely from your laptop against local repos.” Model backends span Anthropic, OpenAI, Ollama, Bedrock, Azure and GCP. A --ci flag puts spec review in the pipeline.

Why it matters here

It is spec-driven-development where the context is mined, not written. spec-kit gives you a constitution and clarification prompts; conductor‘s context-driven-development treats context as a managed artifact a human curates. Corbell derives the context instead — the graph is extracted from the code that exists, so the spec is grounded in what the system actually does rather than in what someone wrote down about it. Two of its signals are ones no human maintains by hand: git change coupling (which files keep changing together) and infrastructure-as-code detection.

That places it next to autowiki-factory and openwiki on the code-understanding-as-artifact axis, but pointed forward rather than backward: AutoWiki derives documentation of what is there, Corbell derives constraints for what you are about to build. Same extraction step, opposite output.

The shape is also the familiar local-first one — a local store queried by agents over MCP, like knowledge-rag and recall — extended here from text and memory to codebase structure. And the multi-repo scope is unusual: most spec tooling assumes one repo, while the decisions this tool targets are exactly the ones that span services.

Read with care

Everything above is self-described. No benchmarks, no evaluation, no user study — nothing measures whether a graph-grounded spec is better than a hand-written one, which is the claim the tool rests on. The “living” in “living knowledge graph” is doing unstated work too: there is no described refresh trigger comparable to autowiki-factory‘s regenerate-on-push, so staleness is a real question against a moving codebase. Small project, one small org, 6 releases. The stated direction is “a fully agentic architecture” with agents selecting tools by feature complexity, which is roadmap, not shipped.

Related

spec-driven-development · spec-kit · conductor · context-driven-development · autowiki-factory · openwiki · knowledge-rag · model-context-protocol