atddlisted

# Acceptance Test Driven Development Enforce the ATDD workflow for feature development. This methodology is adapted from Robert C. Martin's acceptance test approach. ## Core Principle > "The two different streams of tests cause Claude to think much more > deeply about the structure of the code." > — Robert C. Martin Two test streams constrain development: - **Acceptance tests** define WHAT the system does (external observables) - **Unit tests** define HOW the system does it (internal structure) Both must pass. Neither alone is sufficient. ## Workflow Follow these steps strictly, in order. Do not skip steps. Before Step 1, create one TodoWrite todo per step of this workflow (Steps 1–7), all at once — the full list up front, as a roadmap. Flip each todo to `in_progress` / `completed` as you go. See `${CLAUDE_PLUGIN_ROOT}/references/progress-indicator.md`. ### Step 1: Understand the Feature Before writing anything, understand what is being built: - Ask clarifying questions about the feature's purpose - Identify the domain language (what terms do users/stakeholders use?) - Determine success criteria: what observable behavior proves it works? - Scope it: "just enough specs for this sprint" — do not design the whole system ### Step 2: Write GWT Acceptance Specs Write the feature's `spec.md` in **standard Gherkin** (DAE Foundation §7): ```gherkin Feature: <feature name> Scenario: <behavior being specified> Given <precondition in domain language> And <another preco