Spec-driven development
Spec-driven development

Turn a request into a contract, then into verified code.

CafeKit keeps the important truth outside chat. The assistant first writes the contract, then implements one approved task packet, then proves and syncs the result.

01
Request

A human asks for a change.

02
Spec

C1/C2 scope, a plan, and flat tasks become durable files.

03
Develop

The assistant implements one approved task packet.

04
Verify

Real commands and runtime proof check the result.

05
Review

A separate pass checks compliance and risk.

06
Sync

State moves only after evidence exists.

The simple version#

The spec is the durable contract, not chat memory. New work stores that contract in specs/<feature>/plan.md and flat task-NN-*.md files.

The loop CafeKit wants every feature to follow
1. Specify

Write down what should happen before code changes.

2. Build narrowly

Implement only the approved task boundary.

3. Prove it

Run commands and record exact evidence.

4. Sync state

Update task Status and inline Receipt after proof.

What each artifact answers#

What lives inside specs/<feature>/
plan.md

Accepted C1/C2 scope, task index, ownership, dependencies, and completion boundary.

task-NN-*.md

One flat implementation packet with Outcome, Scope, Acceptance, and Verification Plan.

inline Receipt

Exact command, exit, current Base/Head, and non-empty current output.

ArtifactQuestion
plan.mdWhat outcome, scope, exclusions, acceptance, decisions, and task map were approved?
task-NN-*.mdWhat single outcome is executable now, who owns it, and what exact proof is required?
Final inline ## ReceiptWhat current command and output prove the task passed?

Working rule#

  1. Use brainstorm only while intent or architecture is unresolved.
  2. Specs opens C1, writes the plan and tasks, then presents C2 findings.
  3. Planning stops. Start work only with a new explicit develop invocation.
  4. Develop executes one unblocked task; test and code review verify it.
  5. Sync only observed Status and proof. The user decides completion at C3.
Why this is different from normal prompting
Ad-hoc prompting
Chat is the source of truth
Scope changes silently
The assistant guesses missing details
Review checks only the final diff
CafeKit SDD
Repo files are the source of truth
C1 scope makes changes explicit
Missing details route back to the plan
Review compares code against the contract

Use the full path for substantial, risk-elevated, multi-file, runtime, data, auth, package, or handoff-sensitive work. Clear isolated one- or two-file routine changes may use direct work.

Read Core workflow for routing and Spec lifecycle for the full contract.