Context compiled, not discovered
SpecD resolves scope, dependencies, rules, and constraints into the instruction block for the change being worked on.
Spec-first workflow
SpecD
Spec-Driven Development
Build against intent before code starts drifting.
SpecD compiles the exact context an agent needs for the current change and pairs it with a code graph for impact analysis, search, and hotspot discovery.
Why teams adopt it
Specs stay readable, reviewable, and enforceable.- 01Define the change
Capture requirements and verification before implementation starts.
- 02Design with traceability
Proposal, design, and tasks stay attached to the same change.
- 03Implement and verify
Agents execute against the spec instead of improvising from prompts.
Why SpecD is different
Give agents the right context, not a repo to guess from.
Code graph for impact analysis
Index symbols and relationships across the repo so changes can start with real blast-radius analysis instead of guesswork.
Search symbols, files, and hotspots
Use the built-in graph to find relevant code, inspect hotspots, and move from specs to implementation with less hunting.
Verification stays attached
Requirements, scenarios, design, tasks, and generated API reference stay tied to the same change instead of spreading across tools.
Across coding agents
One workflow above the agent layer.
Agent-agnostic by design
Use the same workflow with any coding agent instead of rewriting the process around one vendor.
Plugins for other coding agents
Add plugins to support other coding agents without changing the underlying workflow or contract model.
Hooks at the right gates
Run checks and automation at the right workflow moments instead of bolting them on after implementation.
How SpecD works
From problem to implementation, one change at a time.
Start by understanding what is broken, missing, or risky before jumping into files.
Capture the intended change clearly so the team can discuss the approach before implementation begins.
Find the specs that already constrain the work instead of rediscovering requirements from code alone.
Add new specs when the capability does not exist yet, or modify the existing ones when it already does.
Define the technical changes, analyze their impact, and break the work into tasks before code starts moving.
Validate the proposal, specs, and design alone or with the rest of the team before execution.
Execute against compiled context, impact analysis, and attached verification instead of improvising from prompts.
Run the verification scenarios and confirm the implementation still matches the agreed contract before closing the work.
For teams
Adopt the workflow without forcing every team into the same repo shape.
Single-repo setups
Keep the full change workflow close to one codebase when a team works in a single repository.
Monorepos with workspace boundaries
Split specs and code roots by workspace so context, ownership, and impact analysis stay scoped correctly.
Multi-repo organizations
Point workspaces at external repositories when shared contracts and cross-team rules need to span multiple codebases.
Approval and signoff gates
Add review checkpoints before implementation or archive so one developer or a full team can approve the change at the right moments.
Start from the right entrypoint