Book-Reader-Assist/library/Spec Driven Development/Chapter-08-Hands-on-the-SDD-tools/Chapter-08-chapter-notes.md

Spec Driven Development — Chapter 08: 3 - Hands on: the SDD tools

• Date Created: 2026-10-02
• Status: Complete
• Reading Span: PDF pages 64–75

---

1. Pre-Reading Briefing

• 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?
• Key Points to Watch For:
  • Identify the unit of work each tool uses and the sequence of commands or artifacts it asks you to follow.
  • Compare the amount of governance and ceremony each tool adds; notice which project conditions make that weight useful.
  • Notice why one workflow places a project-wide step before the first feature spec.
  • Separate installation and initialization from actually running a feature through the cycle. What exists after setup, and what still awaits a command?
  • Connect each tool's work unit to Chapter 7's test: can the resulting feature be demonstrated and reviewed as a usable capability?
• Context & Thread from Prior Chapters: Chapters 5–7 established the parts, wording, and scope of a spec. Chapter 7 left a useful distinction to test here: you may implement the UI first, while the spec still promises an end-to-end user action. Watch whether each tool's folders and commands clarify that distinction or blur it.

---

2. Reading Review & Reflections

• Prompt Questions:
  1. What unit of work does spec-kit, OpenSpec, and BMAD use, and when might each approach fit?
  2. Why does Ködel choose spec-kit for this book, and what job does its constitution do?
  3. After project initialization, what has been created and what still needs to happen before someone can use the To-Do app?
• User's Answers:
  1. “one feature at a time . One change at a time, epics and storis”
  2. “he uses it, it has direct mappinf vocabulary, its not the simlesest or the most broad”
  3. “we have to make the constition”
• Scaffolding & Feedback: Correctly recalled the three work units and all three reasons for the book's spec-kit choice: the author's use, direct vocabulary mapping, and its intermediate amount of structure. Added the missing fit: OpenSpec is presented as light for small changes to an existing codebase; BMAD as deep planning for large coordinated projects; spec-kit as the book's structured middle option. Clarified that a constitution sets project-wide decision rules before feature work. Initialization creates scaffolding and an empty constitution file, not a working app; the feature still passes through specify, plan, tasks, implement, and validation (PDF pp. 65–74).

---

3. Chapter Synthesis

• Core Thesis: SDD tools package the same core cycle in different units, commands, and levels of structure; the appropriate choice depends on the project's needs.
• Key Concepts / Mental Models:
  • Unit of work: spec-kit organizes a feature, OpenSpec a change proposal, and BMAD epics and stories. Compare the unit and workflow before comparing command names (PDF pp. 65–66).
  • Tool fit: The book presents spec-kit as a structured middle option, OpenSpec as lighter for incremental changes, and BMAD as heavier planning for large coordinated work (PDF pp. 67–71).
  • Constitution: In spec-kit, project-wide principles constrain later decisions before the first feature specification (PDF p. 67).
  • Initialization versus delivery: specify init creates scaffolding and an empty constitution; it creates no To-Do behavior. A usable feature still requires the later cycle and validation (PDF pp. 71–74).
• Notable Arguments & Evidence: Ködel selects spec-kit because he uses it in software work, its commands map directly to the book's cycle, and its structure sits between OpenSpec and BMAD. These are experience-based and teaching-fit reasons, not a controlled comparison. Tool descriptions and commands reflect the book's June 2026 documentation check; verify current details in official documentation before using them (PDF pp. 70–75).
• Updates to Prior Understanding: Chapter 7's feature boundary remains a user-usable capability. A tool's folders, roles, and commands organize the work around that boundary; they do not make an initialized project a usable app.
• Weekly Action Item: For a small feature such as create-and-list tasks, write the user-visible result in one sentence, then mark what the project setup, constitution, spec, plan, task list, and implementation would each contribute. Stop at the outline; check the current official tool documentation before a real setup.