# Spec Driven Development — Chapter 08 Memory: 3 - Hands on: the SDD tools
- **Stage**: Complete
- **Next Step**: Preview Chapter 9, "spec-kit constitution: the rules before the first move," when the reader is ready.
- **Reading Span**: PDF pages 64–75
- **Source Text**: /library/Spec Driven Development/Chapter-08-Hands-on-the-SDD-tools/Chapter-08-source-text.md (read instead of PDF when needed)
- **Full Record**: /library/Spec Driven Development/Chapter-08-Hands-on-the-SDD-tools/Chapter-08-chapter-notes.md (create at preview)
- **Last Updated**: 2026-10-02

## Carried-in Context (from earlier chapters)
- Ch1: Author experience motivates SDD but does not establish broad effectiveness; reader wants to test the method.
- Ch2: A spec sets a target for judging AI output; people still decide and review. The 70/30 split is illustrative.
- Ch3: SDD addresses what/why, FOCUS Architecture where rules live, and Context Engineering what the agent sees. Reader expects cross-references to explain needed ideas in place.
- Ch4: Short feedback cycles and cheap AI code rewrites are claimed without project-level change-cost data; reader said revised code must be tested against the spec.
- Ch5: A spec records purpose, scope, behavior, criteria, and edges; technical choices belong in the plan. Precise terms matter (non-space vs. non-whitespace).
- Ch6: EARS, Given/When/Then, Design by Contract, and ATDD sharpen requirements. Edit-task self-comparison defect remained a learning point.
- Ch7: One spec = one usable capability, reviewable in one sitting. Split by complete path through needed layers. Reader knows the three scope checks and why complete/reopen pair; proposed UI specs first, so revisit spec scope vs. implementation order with a concrete example. Delete later as a separate spec was understood.
- Open cross-book thread: maintenance and information structure in FOCUS Architecture and Context Engineering; stand-alone cross-reference promise remains under observation.

## This Chapter
- **Core Question**: How do SDD tools turn the same specify-plan-tasks-implement cycle into a working project process, and what makes one tool a good fit for this example?
- **Watch-For Themes**: Unit of work and command sequence for each tool; tradeoffs in governance and ceremony; why one tool adds a step before specifying; what initialization creates versus what remains for later chapters; how a tool's unit of work relates to Chapter 7's usable-capability boundary.
- **Core Thesis**: SDD tools package the same cycle in different work units, commands, and levels of structure; choose for project fit.
- **Key Concepts**: spec-kit=feature; OpenSpec=change; BMAD=epic/story. Constitution sets project-wide principles. Init creates scaffolding, not usable behavior.
- **Notable Arguments / Evidence Limits**: Author chooses spec-kit for personal use, direct cycle vocabulary, and middle structure (pp. 70–71); comparison is experiential, not controlled. Tool details checked June 2026, so current setup needs official-doc verification.
- **Action Item**: Map one small usable feature through setup, constitution, spec, plan, tasks, implementation, and validation before running a tool.

## Reader State
- **Pending Questions**: None; review complete.
- **Reader's Answers (paraphrase)**: Correctly named all three units and the author's three selection reasons; said constitution must be made after init. Did not state tool fit, constitution's purpose, or that init only creates scaffolding.
- **Misconceptions / Feedback Given**: Filled those omissions with project-fit examples, constitution as project-wide guardrail, and the distinction between setup files and a usable feature. Reinforced Chapter 7's capability boundary.
- **Personal Threads**: Reader may try a small task-text spec; during review, use a concrete feature to reinforce capability vs. layer and distinguish a tool's artifact structure from the feature boundary.

## Open Threads
- What evidence would show SDD overhead pays off in the reader's work?
- Check whether Chapter 9 makes the constitution concrete without requiring another book.