Spec Driven Development — Front-Matter: Front matter (cover, title, contents)
- Source: /library/Spec Driven Development/source-file.pdf
- PDF pages: 1–10
- Pages without text: 1
Spec Driven Development
J.C. Ködel
Spec Driven Development
- About the author
- 0 - Why SDD is essential in the age of AI
- The thesis: knowledge and specification are leverage
- The three arguments: judge, decide, answer
- The 70% and the 30%
- What SDD is, in plain language
- SDD is not exactly new
- The next step
- 0b - Trilogy map: what lives in each volume
- 1 - Fundamentals: where SDD comes from
- Waterfall: the right instinct, the wrong cost
- The agile turn: learning to iterate cheaply
- Scrum, the pillar; XP and Kanban, the support
- What each method taught us
- SDD: the synthesis that only now became viable
- Why AI needs specification
- The cycle, now with a name
- The next step
- 2 - Anatomy of a specification
- From vague intent to a blueprint
- What a spec is (and what it isn't)
- The why part: problem and intent
- The scope part: in, out, and non-goals
- The behavior part: scenarios, rules, and acceptance criteria
- The edges: exceptions, assumptions, and dependencies
- The whole blueprint and what makes a spec good
- The next step
- 2b - Requirement Language: Writing What the AI Executes
Without Guessing
- The Blueprint Is Right, the Handwriting Is Not
- Where Specifications Come From
- Before Anything: Functional or Technical
- EARS: The Syntax That Will Not Let the Condition Stay
Implicit
- Given/When/Then: Behavior as a Scene
- Design by Contract: What Holds Before, After and Always
- ATDD: The Acceptance Criterion Written First
- Which to Use, and When
- What a Badly Formed Sentence Costs an Agent
- 2c - The Scope of a Spec: How Much Fits in One Specification
- The Question That Comes Before Writing
- The Criterion: A Spec Is What Fits in One Lap
- Completing and Reopening Fit Together; Creating and
Deleting Do Not
- When the Feature Is Too Big
- When the Method Does Not Pay Off
- What You Take From Here
- 3 - Hands on: the SDD tools
- From the blueprint to the wall
- Three ways of doing the same thing
- The cycle is the same, the incarnation changes
- The honest comparison
- The choice and why
- Lean setup and first contact
- The bridge to the full cycle
- 4 - speckit constitution: the rules before the first move
- The rules before the first move
- What a project constitution is
- What goes in and what stays out
- Running the constitution step on the To-Do
- The To-Do's constitution, principle by principle
- Why the stack stays out
- Living artifact and the bridge to the first spec
- 4.5 - Appendix: the To-Do constitution
- To-Do Constitution
- Core Principles
- Engineering Standards
- Workflow
- Governance
- 5 - The complete SDD cycle
- Before the first specify , a map
- What you're learning is the cycle, not the app
- The feature lives on a branch: main → branch → merge
- The map in a single figure
- The constitution sits above the loop
- The loop, step by step
- The artifacts talk to each other; that's why you clear the
context
- The map is drawn: the bridge to Ch. 6
- 6 - Create and list tasks: the first complete loop
- From the map to the ground: the first feature
- One feature at a time: the backlog
- Spotlight: specify in action
- The anatomy from Ch. 2, actually filled in
- What is spec and what is plan : the boundary
- The rest of the loop, at a follow-along pace
- Commit, merge, and the bridge to Ch. 7
- 6.5 - Creating and listing tasks in practice: the whole loop, file
by file
- How to read this chapter
- The input: the /speckit-specify prompt
- What specify and clarify returned: spec.md
- The requirements check: checklists/requirements.md
- What plan decided: plan.md
- The plan ‘s design artifacts
- The execution list from tasks : tasks.md
- The code implement generated
- The portrait of the lap
- 6b - Specification Anti-Patterns: Six Ways to Get It Wrong,
Over and Over
- Six Defects, All Taken From This App
-
- A Rule Inherited by Reference
-
- Initial State Left Undeclared
-
- A Verb With Two Owners
-
- A Repeated Edge With No Answer
-
- Scope That Grows Out of Convenience
-
- Fixing at the End of the Chain
- The Checklist, in Six Questions
- 7 - Completing a Task: When the Obvious Hides Decisions
- The state of git, again
- The feature of the moment, and specify at a light pace
- “Completing” seems obvious. It is not.
- The answers go back into the spec
- What changes down the line
- How to distrust the obvious
- End of the loop and the bridge to Ch. 8
- 7.5 - Completing and Reopening a Task in Practice: the Whole
Loop, File by File
- How to read this chapter
- The input: the /speckit-specify prompt
- What specify and clarify returned: spec.md
- What plan decided: plan.md
- The plan ‘s state model: data-model.md
- The tasks execution list: tasks.md
- The code implement generated
- The portrait of the lap
- 8 - Filtering Tasks: The Spotlight on plan and checklist
- The third loop starts on main
specify and clarify , at a light pace
3. The what is already decided; the how is missing
4. Spotlight: plan decides the how
5. The constitution check has teeth
6. Spotlight: checklist as a quality gate
7. Closing the loop, at a light pace
8. The bridge to Ch. 9
9. 8.5 - Filtering Tasks in Practice: the Whole Loop, File by File
- How to read this chapter
- The input: the /speckit-specify prompt
- What specify and clarify returned: spec.md
- The requirements review: checklists/requirements.md
- What plan decided: plan.md
- The plan ‘s view model: data-model.md
- The tasks execution list: tasks.md
- The code implement generated
- The portrait of the lap
- 9 - Deleting a Task: The Spotlight on tasks and analyze
- The fourth loop starts: 004-excluir-tarefa
- The early steps, at a light pace
tasks : the plan turns into a list of steps
4. Why this order: TDD and layers
5.
analyze : reading the three artifacts together
6. A real conflict: the deletion against “completing”
7. Fix at the source, and the cascade it triggers
8. From the branch to the merge, and the bridge to Ch. 10
21. 9.5 - Deleting a Task in Practice: the Whole Loop, File by File
- How to Read This Chapter
- The Input: the /speckit-specify Prompt
- What specify and clarify Returned: spec.md
- The Completeness Check: checklists/requirements.md
- What plan Decided: plan.md
- The analyze Report: analyze-report.md
- The plan ‘s Model of the Operation: data-model.md
- The tasks Execution List: tasks.md
- The Code implement Generated
- The Portrait of the Lap
- 10 - Edit Task: The Spotlight on implement
- The Last Loop Starts on main
- From specify to analyze , at a Light Pace
implement Reads the Artifacts, Not the Chat
4. Red, Green, Refactor
5. Reviewing What the Agent Wrote
6. Loop Closed, App Complete
3. 10.5 - Editing a Task in Practice: the Whole Loop, File by File
- How to Read This Chapter
- The Input: the /speckit-specify Prompt
- What specify and clarify Returned: spec.md
- The Completeness Check: checklists/requirements.md
- What plan Decided: plan.md
- The analyze Report: analyze-report.md
- The plan ‘s Model of the Operation: data-model.md
- The tasks Execution List: tasks.md
- The Code implement Generated
- The Second Iteration, in the Order It Happened
- The Portrait of the Lap, and of the Five
- 10b - Iterative Refinement: The Spec After It Already Exists
- No Document Is Born Finished
- Four Doors the Change Comes Through
- The Chain, in the Order Things Move
- What Changes and What Does Not
- When the Spec Stops Being Trustworthy
- The Document That Outlives the Project
- 11 - The Whole App Was Born From Five Loops
- Stop and Look Back
- The Whole App Is Five Merges Into main
- The Timeline in One Figure
- Each Feature Lit a Spotlight
- Together, They Covered the Whole Cycle
- One Constitution Governed the Five Loops
- The Cycle Is Yours Now
- What If I Did This Without SDD?
- The To-Do Was the Vehicle; the Process Was the
Protagonist
- Canonical Glossary
- Terms
- Rules