go-tdd-featurelisted

# Go TDD - Feature workflow Spec-driven, red-before-green discipline for new feature work in Tier 1 paths. ## When this skill applies **Use when the user asks to implement/add/build/create new functionality in:** - Any path matching `tier1_path_regexes` in `.tdd/tdd-config.json` **Do NOT use for:** - Doc updates, CHANGELOG, README - `.claude/` config, hook scripts - CI workflow YAML - Test infrastructure - Code outside Tier 1 (use `minimal-go-change`) ## Workflow ### Phase 1 - Spec analysis 1. Read the user's request. If a linked spec exists in `specs/`, read it. 2. Copy `.tdd/templates/feature-plan.md` to `.tdd/current-plan.md`. 3. Fill in: - Summary (one paragraph, why) - User-visible behavior (observable, no implementation) - Acceptance criteria (numbered, testable) - Non-goals (forced explicit) - Test plan - Risks - Implementation sketch (3-5 bullets, do NOT pre-implement) If the request is ambiguous, list questions and STOP. ### Gate 1 - User approval of spec Stop and ask: **"Spec drafted at `.tdd/current-plan.md`. Reply `APPROVED SPEC` (or plain `APPROVED`) to authorize the red phase, or `CHANGES <reason>`."** After APPROVED, set: ``` Human approved spec: yes ``` ### Phase 2 - Red 1. For each test in the test plan: - Write a failing test pinned to the acceptance criterion. - Name it `Test<Behavior>_When_<Condition>_Then_<Expectation>`. - Use existing patterns (table-driven, embed-nil-interface fakes, compile-time interfac