Specgraph SDD.
Spec-Driven Development (SDD) is the methodology at the core of Specgraph. It turns product ideas into validated, AI-ready specifications before a single line of code is written — and it works equally well for new builds and for extending existing systems.
What is Spec-Driven Development?
SDD is a development discipline where a complete, multi-department specification is produced and approved before implementation begins. The key difference from traditional documentation: the spec is not written for humans to read after the fact. It is structured so AI coding agents can consume it directly and implement it precisely.
Traditional approaches break down in two ways. Waterfall specs go stale the moment a team starts building. Agile teams skip the spec entirely and pay for it in mid-sprint pivots. SDD sits in neither camp — it uses AI to make the specification process fast enough to be practical, and structured enough to drive implementation without interpretation.
The spec is the contract. The agent implements it. A different model reviews the result.
The governed specification method
Specgraph organises the specification into sequential, department-owned phases. Each phase is completed through an AI-led interview — the model asks questions, you answer, and the answers are structured into the spec automatically.
A phase cannot move forward until its owner approves it. Locking a phase makes it immutable for all downstream phases. Any subsequent change requires a formal amendment — which is tracked, audited, and routed to the right reviewer.
Each department sees only what it owns. Business shapes the vision; Product writes the requirements; Engineering designs the architecture. Nobody gets to skip phases because the tool enforces the gate. When P-08 (Handoff Readiness) is green, the full handoff pack is generated and the MCP server begins exposing stories to coding agents.
Building new projects — Greenfield
A greenfield project starts with a single intake conversation. Specgraph asks about your idea — who it's for, what problem it solves, what success looks like, and what is explicitly out of scope. From that conversation, Vision & Scope (P-01) is pre-filled and the specification journey begins.
The AI then guides each subsequent phase as an interview: it asks the right questions for that phase's department, you answer in natural language, and it structures the output. No templates to fill in, no blank pages to stare at.
Because every decision is captured in the spec before coding starts, the implementing agent operates with full context — business rationale, data model, test strategy, security model — before touching a single file. Teams that use SDD for greenfield projects report significantly fewer mid-sprint pivots: the alignment happens at spec time, not in a PR comment at 11 pm.
Evolving existing systems — Brownfield
Legacy systems often have no spec at all — the architecture lives in engineers' heads and tribal knowledge disappears every time someone leaves. Specgraph's discovery skill solves this by reverse-speccing an existing codebase in one automated pass.
Point Specgraph at your repository and it reads routes, schemas, auth flows, API contracts, and test files — then auto-populates a first-draft spec across every phase, flags gaps it found, and surfaces inconsistencies between what the code does and what the comments say it should do.
The team then reviews each section, corrects the AI's inferences, and fills in the gaps. Once the spec is validated, adding a new feature follows the same governed flow as a greenfield project — but the agent also has full context about the existing system, so it won't break what's already there.
When stakeholders request future changes, the wish & amendment workflow lets them propose changes against locked phases formally — no more ad-hoc Slack messages that never make it into the spec. The implementing agent picks up new stories automatically once amendments are merged.
Why it produces precise implementation
A vague prompt produces a vague implementation. SDD removes vagueness at every layer of the stack:
Skills used for implementation
Specgraph relies on two layers of skills: the spec-building skills that fill and validate each phase, and the agent skills that coding tools use at implementation time via the MCP server.
Spec-building skills
The primary input method for every specification phase. The AI asks targeted questions for that department, structures your answers, and populates the phase fields automatically.
Reads a repository — routes, schemas, auth flows, test files — and produces a first-draft spec across all phases. Flags gaps and surfaced inconsistencies for human review.
One-shot AI rewrite triggered from any text field. Useful for polishing a vision statement, clarifying an acceptance criterion, or tightening an architecture decision.
Lets stakeholders propose changes against approved phases. Each amendment is reviewed, merged into the spec, and automatically generates new stories for the agent to pick up.
Agent MCP tools
Once connected to the MCP server, a coding agent (Claude Code, Cursor, Cline, …) has access to these tools. They are the only interface between the agent and the spec — no direct database access, no file mutations outside the story scope.