One word, one meaning
No ambiguity for teammates, and none for the agent reading your specs.
The problem
Coding with AI breaks down in four predictable ways
None of them are model-quality problems. They are all context problems — and context is something you can engineer.
Every session starts from zero
You paste the same architecture explanation again. Or you dump the whole repo in and watch the context window fill with things this task will never touch.
The agent edits what it shouldn't
One small feature request, and it quietly refactors three modules you never mentioned. Without stated boundaries, everything looks in scope.
Docs die the moment you write them
Specs drift from code within a week. Nobody updates them, so nobody trusts them, so the agent gets fed stale truth — confidently.
Keeping the model current is work
If staying in sync means hand-editing documents after every commit, it will not happen. The model has to maintain itself, or it dies.
Context-Centric
Model your product as contexts, not as documents
A context is a bounded area where every word means exactly one thing. Inside it you model entities and usecases; connections between contexts are derived from @mentions between usecases — never hand-drawn.
- A context owns its own language. "Order" in Ordering and "Order" in Delivery can safely mean different things.
- Every change lands inside one context — so its blast radius across the system is computable, not guessed.
- Your model exports as dspecs.json and Markdown — it is your data, not a row in someone's database.
Context
Ordering
Order· total, items
Place Orderwrite
List My Ordersread
Context
Delivery
Order· address, courier
Prepare Delivery
Place Order@Prepare Delivery
auto-derived from the @mention — never hand-drawn
Change stays local
DSpecs derives which contexts a change actually affects — by traversing the graph, not by asking an LLM.
Right-sized AI context
Smaller prompts, fewer hallucinations, and no context window wasted on unrelated code.
The model keeps itself honest
A linter flags specs that drifted or went thin; anything the agent wants to rewrite in your prose comes back as a proposal you approve.
Compile & Ship
DSpecs writes your specs — and ships them to Claude, Codex, Cursor, and more
You maintain the model; specs are a build artifact. One click compiles CLAUDE.md, AGENTS.md, Cursor rules and JSON — with your Constitution on top — and ships them over remote MCP or the CLI.
One model → every format
compile — one model, every format
$ dspecs pull ✓ CLAUDE.md (17.8 KB) ✓ AGENTS.md ✓ .cursor/rules/ (10 files) ✓ dspecs.json ## 0. Project Constitution Stack: Next.js · Prisma · PostgreSQL ## 1. Context: Ordering #### Entity: Customer ⭐ root #### Usecase: Checkout — actor: Buyer
Connect your agent — one URL + token
terminal
$ claude mcp add --transport http dspecs \ https://dspecs.com/api/v1/mcp \ --header "Authorization: Bearer dsp_xxx" # 13 tools available: # get_project_overview · get_context # get_usecase · get_specs · search_specs # list_updates · get_update_delta # set_update_status · propose_spec_change # get_sync_plan · import_model_map # finish_code_map · get_mapping_status
Works withClaude CodeCodex CLICursorGitHub Copilotand any MCP-compatible tool
Code Graph
Your specs know where the code lives
Every context, entity and usecase carries a codeRef — the real files and symbols that implement it. Your agent maps the repository itself; you review the drift. Nothing is ever deleted without you.
- Delta prompts carry a Code Map: the files this change touches, plus an explicit "files not listed here are unaffected — do not modify them."
- Your agent writes the usecase body from the code it just read — the validation rules, the inputs, the error cases. Specs stop being a list of names.
- No git required. DSpecs never sees your repository and stores no commit id — it tracks how fresh each context is on its own, and asks the agent to re-scan only what went stale.
- Drift review in one click: new, moved and renamed elements apply as a batch. Deleted ones are never removed automatically — a partial scan looks identical to a deletion.
The agent maps your repo — you accept
delta — code map
## 2. Code Map Modify only what section 1 requires; read the rest for context. Files not listed here are unaffected — do not modify them. - src/ordering/coupon.service.ts - src/ordering/order.entity.ts
Drift, reviewed and applied
2 new1 moved1 renamedApply 4 safe
Delta Update
The loop evolves.
Only the delta ships.
Change the model and DSpecs captures exactly what is different — then compiles a focused prompt: what changed, which files it touches, and the minimal surrounding context. No full re-compile, no re-explaining.
740-token delta vs 8.2K full — 91% smaller (illustrative example)
Full spec
~8.2K tokens
Delta Update
~740 tokens
DELTA-checkout-update.md — compiled by DSpecs
## 0. Constitution Stack: Next.js · Prisma · PostgreSQL ## 1. What Changed #### UPDATED Usecase: Checkout - contentText: "..." → "...award 1 point per $10" + CREATED Field: Customer.loyaltyPoints (int ≥ 0) ## 2. Relevant Context #### Entity: Customer ⭐ root #### Usecase: Award Loyalty Points · write ## 3. System Map - Ordering ← affected
The Loop
Model → Compile → Build → Sync back
The model sits at the centre and the loop closes in both directions: you change specs, the agent builds, then the agent syncs the code map back so the model never falls behind.
01
Model & Map
Point your agent at the repo and it maps your codebase into contexts, entities and usecases — each bound to real files. Or start from a document, or from scratch.
02
Compile & Constitution
Model plus your project rules compile into CLAUDE.md, AGENTS.md and Cursor rules — Constitution always rendered first, so a thin slice never loses your conventions.
03
Build
The agent pulls exactly what it needs over MCP: one usecase, one context, or a delta for the update it is implementing.
04
Sync back
When the work is done, the agent asks DSpecs what to re-scan — a work order computed from what changed in the model, not from your git history — and pushes the refreshed code map. You review the drift and accept.
Constitution
Your rules ride with every prompt
Stack, architecture, conventions, non-negotiables — kept as a library of named rules rather than one wall of text, and injected at the top of every compile and every delta.
- Each rule is a named markdown block you can edit independently.
- Mark a rule default and it rides on every compile automatically.
- Pick exactly which rules ship with a full or delta compile.
- Always rendered first, so even a thin delta never loses your conventions.
- DSpecs seeds one system rule that tells your agent to refresh the code map after implementing — turn it off any time.
constitution — rules library
✓ stack.md default · Next.js · Prisma · PostgreSQL ✓ conventions.md default · DDD, event-driven, i18n ○ legacy-api.md optional · pick per compile $ compile --delta ## 0. Project Constitution ### stack ### conventions ## 1. What Changed …