From b8879c62531fc5db17bbf7ee982a9e72000c720b Mon Sep 17 00:00:00 2001
From: Lex Christopherson <lex@glittercowboy.com>
Date: Mon, 15 Dec 2025 10:15:59 -0600
Subject: [PATCH] Add TDD guidance to planning workflow
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- New <test_driven_when_beneficial> principle in references/principles.md
- TDD assessment step in plan-phase.md break_into_tasks
- Pragmatic approach: use TDD when behavior is definable upfront

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---
 get-shit-done/references/principles.md | 33 ++++++++++++++++++++++++++
 get-shit-done/workflows/plan-phase.md  | 12 ++++++++++
 2 files changed, 45 insertions(+)

diff --git a/get-shit-done/references/principles.md b/get-shit-done/references/principles.md
index dd38c6a97..4d44d062f 100644
--- a/get-shit-done/references/principles.md
+++ b/get-shit-done/references/principles.md
@@ -73,6 +73,39 @@ Plans are guides, not straitjackets. During execution:
 5. **Log enhancements** - Nice-to-haves, log to Issues, continue
 </deviation_rules>
 
+<test_driven_when_beneficial>
+
+Use TDD when the work WOULD benefit from it. Not dogma—pragmatism.
+
+**TDD candidates (write test first):**
+- Business logic with defined inputs/outputs
+- API endpoints and handlers
+- Data transformations and parsing
+- Validation rules
+- State machines and workflows
+- Anything where you can describe expected behavior before implementing
+
+**Skip TDD for:**
+- UI layout and styling
+- Exploratory prototyping
+- One-off scripts and migrations
+- Configuration changes
+- Glue code with no logic
+
+**Decision heuristic:**
+Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
+→ Yes: TDD will help
+→ No: Write implementation first, add tests after if needed
+
+**TDD task structure:**
+When TDD applies, structure tasks as test-first:
+1. Write failing test (red)
+2. Implement to pass (green)
+3. Refactor if needed
+
+This is about design quality, not test coverage metrics.
+</test_driven_when_beneficial>
+
 <ship_fast>
 
 No enterprise process. No approval gates.
diff --git a/get-shit-done/workflows/plan-phase.md b/get-shit-done/workflows/plan-phase.md
index 43003d09e..a1cb89b81 100644
--- a/get-shit-done/workflows/plan-phase.md
+++ b/get-shit-done/workflows/plan-phase.md
@@ -422,6 +422,18 @@ Each task must have:
 - **Verify**: How to prove it worked
 - **Done**: Acceptance criteria
 
+**Assess TDD fit for each task:**
+
+TDD produces better design and catches bugs early. Use it when you can define expected behavior upfront.
+
+For each task, ask: Can I write `expect(fn(input)).toBe(output)` before writing `fn`?
+
+→ **Yes** (business logic, APIs, transformations, validation, state machines):
+  Structure test-first. Task action: "Implement X with TDD—write failing test, then implement to pass."
+
+→ **No** (UI layout, config, glue code, exploration):
+  Standard implementation. Add tests after if coverage needed.
+
 **Identify checkpoints:**
 
 - Claude automated work needing visual/functional verification? → checkpoint:human-verify