feat: TDD features use dedicated plans for full context quality

TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. This consumes 40-50% of context for a single feature. Dedicated TDD plans ensure full quality throughout the cycle. - TDD plans use `type: tdd` frontmatter with `<feature>` element - One feature per TDD plan (batching defeats the purpose) - Target ~40% context usage for TDD plans - Standard plans handle non-TDD work with 2-3 tasks 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-05 21:55:36 -06:00
parent 7bc80699f3
commit 85f0ea5c58
7 changed files with 205 additions and 137 deletions
--- a/get-shit-done/references/plan-format.md
+++ b/get-shit-done/references/plan-format.md
@@ -243,42 +243,30 @@ Use for: Technology selection, architecture decisions, design choices, feature p
 See `./checkpoints.md` for comprehensive checkpoint guidance.
 </task_types>

-<tdd_annotation>
-Tasks can include `tdd="true"` attribute when TDD improves quality:
+<tdd_plans>
+**TDD work uses dedicated plans.**

-**Structure:**
-```xml
-<task type="auto" tdd="true">
-  <name>Task N: [Name]</name>
-  <files>[paths]</files>
-  <test-first>[What test to write first - the failing assertion]</test-first>
-  <action>[Implementation to make test pass]</action>
-  <verify>[Tests pass, behavior works]</verify>
-  <done>[Criteria]</done>
-</task>
-```
+TDD features require 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. This is fundamentally heavier than standard tasks and would consume 50-60% of context if embedded in a multi-task plan.

-**When to add tdd="true":**
+**When to create a TDD plan:**
 - Business logic with defined inputs/outputs
 - API endpoints with request/response contracts
 - Data transformations and parsing
 - Validation rules
 - Algorithms with testable behavior

-**When NOT to add tdd="true":**
+**When to use standard plans (skip TDD):**
 - UI layout and styling
 - Configuration changes
 - Glue code connecting existing components
 - One-off scripts

-**Execution flow (when tdd="true"):**
-1. Claude writes failing test from `<test-first>`
-2. Claude implements from `<action>` until test passes
-3. Claude refactors if needed (tests still pass)
-4. Claude commits atomic change
+**Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
+→ Yes: Create a TDD plan (one feature per plan)
+→ No: Use standard plan, add tests after if needed

-See `./tdd.md` for comprehensive TDD guidance.
-</tdd_annotation>
+See `./tdd.md` for TDD plan structure and execution guidance.
+</tdd_plans>

 <context_references>
 Use @file references to load context for the prompt:
@@ -384,25 +372,11 @@ Claude: "How? What type? What library? Where?"
 Claude can implement this immediately.
 </just_right>

-<tdd_example>
-TDD task example:
+<note_on_tdd>
+**TDD candidates get dedicated plans.**

-```xml
-<task type="auto" tdd="true">
-  <name>Task 2: Create email validation utility</name>
-  <files>src/lib/validation.ts, src/lib/validation.test.ts</files>
-  <test-first>
-    Test: isValidEmail returns true for valid emails, false for invalid
-    Cases: "user@example.com" → true, "invalid" → false, "" → false, "user@" → false
-  </test-first>
-  <action>Implement isValidEmail using regex pattern. Handle edge cases: empty string, missing @, missing domain.</action>
-  <verify>npm test -- validation.test.ts passes all cases</verify>
-  <done>Email validation works for all edge cases, tests document behavior</done>
-</task>
-```
-
-Claude executes this with RED → GREEN → REFACTOR cycle, producing atomic commits.
-</tdd_example>
+If email validation warrants TDD, create a TDD plan for it. See `./tdd.md` for TDD plan structure.
+</note_on_tdd>

 <too_detailed>
 Writing the actual code in the plan. Trust Claude to implement from clear instructions.
--- a/get-shit-done/references/principles.md
+++ b/get-shit-done/references/principles.md
@@ -77,7 +77,7 @@ Plans are guides, not straitjackets. During execution:

 Use TDD when the work WOULD benefit from it. Not dogma—pragmatism.

-**TDD candidates (write test first):**
+**TDD candidates (create dedicated TDD plan):**
 - Business logic with defined inputs/outputs
 - API endpoints and handlers
 - Data transformations and parsing
@@ -85,7 +85,7 @@ Use TDD when the work WOULD benefit from it. Not dogma—pragmatism.
 - State machines and workflows
 - Anything where you can describe expected behavior before implementing

-**Skip TDD for:**
+**Skip TDD (use standard plan):**
 - UI layout and styling
 - Exploratory prototyping
 - One-off scripts and migrations
@@ -94,16 +94,20 @@ Use TDD when the work WOULD benefit from it. Not dogma—pragmatism.

 **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
+→ Yes: Create a TDD plan (one feature per plan)
+→ No: Standard plan, 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
+**Why TDD gets its own plan:**
+TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. This consumes 40-50% of context for a single feature. Dedicated TDD plans ensure full quality throughout the cycle.
+
+**TDD plan structure:**
+1. Write failing test (RED) → commit
+2. Implement to pass (GREEN) → commit
+3. Refactor if needed → commit

 This is about design quality, not test coverage metrics.
+
+See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure.
 </test_driven_when_beneficial>

 <ship_fast>
--- a/get-shit-done/references/scope-estimation.md
+++ b/get-shit-done/references/scope-estimation.md
@@ -38,6 +38,27 @@ Why 50% not 80%?
 **When in doubt: Default to 2 tasks.** Better to have an extra plan than degraded quality.
 </task_rule>

+<tdd_plans>
+**TDD features get their own plans. Target ~40% context.**
+
+TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. This is fundamentally heavier than linear task execution.
+
+| TDD Feature Complexity | Context Usage |
+|------------------------|---------------|
+| Simple utility function | ~25-30% |
+| Business logic with edge cases | ~35-40% |
+| Complex algorithm | ~40-50% |
+
+**One feature per TDD plan.** If features are trivial enough to batch, they're trivial enough to skip TDD.
+
+**Why TDD plans are separate:**
+- TDD consumes 40-50% context for a single feature
+- Dedicated plans ensure full quality throughout RED-GREEN-REFACTOR
+- Each TDD feature gets fresh context, peak quality
+
+See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure.
+</tdd_plans>
+
 <split_signals>

 <always_split>
--- a/get-shit-done/references/tdd.md
+++ b/get-shit-done/references/tdd.md
@@ -2,12 +2,14 @@
 TDD is about design quality, not coverage metrics. The red-green-refactor cycle forces you to think about behavior before implementation, producing cleaner interfaces and more testable code.

 **Principle:** If you can describe the behavior as `expect(fn(input)).toBe(output)` before writing `fn`, TDD improves the result.
+
+**Key insight:** TDD work is fundamentally heavier than standard tasks—it requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. TDD features get dedicated plans to ensure full context is available throughout the cycle.
 </overview>

-<detection>
+<when_to_use_tdd>
 ## When TDD Improves Quality

-**TDD candidates (add `tdd="true"`, include `<test-first>`):**
+**TDD candidates (create a TDD plan):**
 - Business logic with defined inputs/outputs
 - API endpoints with request/response contracts
 - Data transformations, parsing, formatting
@@ -16,7 +18,7 @@ TDD is about design quality, not coverage metrics. The red-green-refactor cycle
 - State machines and workflows
 - Utility functions with clear specifications

-**Skip TDD (standard `type="auto"`):**
+**Skip TDD (use standard plan with `type="auto"` tasks):**
 - UI layout, styling, visual components
 - Configuration changes
 - Glue code connecting existing components
@@ -25,32 +27,89 @@ TDD is about design quality, not coverage metrics. The red-green-refactor cycle
 - Exploratory prototyping

 **Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
-→ Yes: TDD will help
-→ No: Implement first, add tests after if needed
-</detection>
+→ Yes: Create a TDD plan
+→ No: Use standard plan, add tests after if needed
+</when_to_use_tdd>
+
+<tdd_plan_structure>
+## TDD Plan Structure
+
+Each TDD plan implements **one feature** through the full RED-GREEN-REFACTOR cycle.
+
+```markdown
+---
+phase: XX-name
+plan: NN
+type: tdd
+---
+
+<objective>
+[What feature and why]
+Purpose: [Design benefit of TDD for this feature]
+Output: [Working, tested feature]
+</objective>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@relevant/source/files.ts
+</context>
+
+<feature>
+  <name>[Feature name]</name>
+  <files>[source file, test file]</files>
+  <behavior>
+    [Expected behavior in testable terms]
+    Cases: input → expected output
+  </behavior>
+  <implementation>[How to implement once tests pass]</implementation>
+</feature>
+
+<verification>
+[Test command that proves feature works]
+</verification>
+
+<success_criteria>
+- Failing test written and committed
+- Implementation passes test
+- Refactor complete (if needed)
+- All 2-3 commits present
+</success_criteria>
+
+<output>
+After completion, create SUMMARY.md with:
+- RED: What test was written, why it failed
+- GREEN: What implementation made it pass
+- REFACTOR: What cleanup was done (if any)
+- Commits: List of commits produced
+</output>
+```
+
+**One feature per TDD plan.** If features are trivial enough to batch, they're trivial enough to skip TDD—use a standard plan and add tests after.
+</tdd_plan_structure>

 <execution_flow>
 ## Red-Green-Refactor Cycle

 **RED - Write failing test:**
 1. Create test file following project conventions
-2. Write test describing expected behavior (from `<test-first>` element)
+2. Write test describing expected behavior (from `<behavior>` element)
 3. Run test - it MUST fail
 4. If test passes: feature exists or test is wrong. Investigate.
-5. Commit: `test: add failing test for [feature]`
+5. Commit: `test({phase}-{plan}): add failing test for [feature]`

 **GREEN - Implement to pass:**
 1. Write minimal code to make test pass
 2. No cleverness, no optimization - just make it work
 3. Run test - it MUST pass
-4. Commit: `feat: implement [feature]`
+4. Commit: `feat({phase}-{plan}): implement [feature]`

 **REFACTOR (if needed):**
 1. Clean up implementation if obvious improvements exist
 2. Run tests - MUST still pass
-3. Only commit if changes made: `refactor: clean up [feature]`
+3. Only commit if changes made: `refactor({phase}-{plan}): clean up [feature]`

-**Atomic commits:** Each TDD task produces 2-3 commits following this pattern.
+**Result:** Each TDD plan produces 2-3 atomic commits.
 </execution_flow>

 <test_quality>
@@ -77,7 +136,7 @@ TDD is about design quality, not coverage metrics. The red-green-refactor cycle
 <framework_setup>
 ## Test Framework Setup (If None Exists)

-When a TDD task exists but no test framework is configured:
+When executing a TDD plan but no test framework is configured, set it up as part of the RED phase:

 **1. Detect project type:**
 ```bash
@@ -122,6 +181,8 @@ Follow project conventions for test location:
 - `*.test.ts` / `*.spec.ts` next to source
 - `__tests__/` directory
 - `tests/` directory at root
+
+Framework setup is a one-time cost included in the first TDD plan's RED phase.
 </framework_setup>

 <error_handling>
@@ -134,7 +195,7 @@ Follow project conventions for test location:

 **Test doesn't pass in GREEN phase:**
 - Debug implementation
- Don't skip to next task
+- Don't skip to refactor
 - Keep iterating until green

 **Tests fail in REFACTOR phase:**
@@ -149,39 +210,54 @@ Follow project conventions for test location:
 </error_handling>

 <commit_pattern>
-## Commit Pattern for TDD Tasks
+## Commit Pattern for TDD Plans

-TDD tasks produce 2-3 atomic commits (one per TDD phase):
+TDD plans produce 2-3 atomic commits (one per phase):

 ```
-test({phase}-{plan}): add failing test for email validation
+test(08-02): add failing test for email validation

 - Tests valid email formats accepted
 - Tests invalid formats rejected
 - Tests empty input handling

-feat({phase}-{plan}): implement email validation
+feat(08-02): implement email validation

 - Regex pattern matches RFC 5322
 - Returns boolean for validity
 - Handles edge cases (empty, null)

-refactor({phase}-{plan}): extract regex to constant (optional)
+refactor(08-02): extract regex to constant (optional)

 - Moved pattern to EMAIL_REGEX constant
 - No behavior changes
 - Tests still pass
 ```

-**This aligns with the standard task commit pattern:**
- Non-TDD tasks: 1 commit per task (feat/fix)
- TDD tasks: 2-3 commits per task (test/feat/refactor)
+**Comparison with standard plans:**
+- Standard plans: 1 commit per task, 2-4 commits per plan
+- TDD plans: 2-3 commits for single feature

 Both follow same format: `{type}({phase}-{plan}): {description}`

 **Benefits:**
 - Each commit independently revertable
- Git bisect works at commit level (not just task level)
+- Git bisect works at commit level
 - Clear history showing TDD discipline
 - Consistent with overall commit strategy
 </commit_pattern>
+
+<context_budget>
+## Context Budget
+
+TDD plans target **~40% context usage** (lower than standard plans' ~50%).
+
+Why lower:
+- RED phase: write test, run test, potentially debug why it didn't fail
+- GREEN phase: implement, run test, potentially iterate on failures
+- REFACTOR phase: modify code, run tests, verify no regressions
+
+Each phase involves reading files, running commands, analyzing output. The back-and-forth is inherently heavier than linear task execution.
+
+Single feature focus ensures full quality throughout the cycle.
+</context_budget>