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>
This commit is contained in:
Lex Christopherson
@@ -815,55 +815,62 @@ Logged to .planning/ISSUES.md for future consideration:
|
||||
|
||||
</deviation_documentation>
|
||||
|
||||
<tdd_execution>
|
||||
## TDD Task Execution
|
||||
<tdd_plan_execution>
|
||||
## TDD Plan Execution
|
||||
|
||||
When executing a task with `tdd="true"` attribute:
|
||||
When executing a plan with `type: tdd` in frontmatter, follow the RED-GREEN-REFACTOR cycle for the single feature defined in the plan.
|
||||
|
||||
**1. Check test infrastructure:**
|
||||
**1. Check test infrastructure (if first TDD plan):**
|
||||
If no test framework configured:
|
||||
- Detect project type from package.json/requirements.txt/etc.
|
||||
- Install minimal test framework (Jest, pytest, Go testing, etc.)
|
||||
- Create test config file
|
||||
- Verify: run empty test suite
|
||||
- This is part of the RED phase, not a separate task
|
||||
|
||||
**2. RED - Write failing test:**
|
||||
- Read `<test-first>` element for test specification
|
||||
- Read `<behavior>` element for test specification
|
||||
- Create test file if doesn't exist (follow project conventions)
|
||||
- Write test(s) that describe expected behavior
|
||||
- Run tests - MUST fail (if passes, test is wrong or feature exists)
|
||||
- Commit: "test: add failing test for [feature]"
|
||||
- Commit: `test({phase}-{plan}): add failing test for [feature]`
|
||||
|
||||
**3. GREEN - Implement to pass:**
|
||||
- Read `<action>` element for implementation guidance
|
||||
- Read `<implementation>` element for guidance
|
||||
- Write minimal code to make test pass
|
||||
- Run tests - MUST pass
|
||||
- Commit: "feat: implement [feature]"
|
||||
- Commit: `feat({phase}-{plan}): implement [feature]`
|
||||
|
||||
**4. REFACTOR (if needed):**
|
||||
- Clean up code if obvious improvements
|
||||
- Run tests - MUST still pass
|
||||
- Commit only if changes made: "refactor: clean up [feature]"
|
||||
- Commit only if changes made: `refactor({phase}-{plan}): clean up [feature]`
|
||||
|
||||
**Commit pattern for TDD tasks:**
|
||||
Each TDD task produces 2-3 atomic commits:
|
||||
1. `test: add failing test for X`
|
||||
2. `feat: implement X`
|
||||
3. `refactor: clean up X` (optional)
|
||||
**Commit pattern for TDD plans:**
|
||||
Each TDD plan produces 2-3 atomic commits:
|
||||
1. `test({phase}-{plan}): add failing test for X`
|
||||
2. `feat({phase}-{plan}): implement X`
|
||||
3. `refactor({phase}-{plan}): clean up X` (optional)
|
||||
|
||||
**Error handling:**
|
||||
- If test doesn't fail in RED phase: Test is wrong or feature already exists. Investigate before proceeding.
|
||||
- If test doesn't pass in GREEN phase: Debug implementation, don't skip to next task.
|
||||
- If test doesn't pass in GREEN phase: Debug implementation, keep iterating until green.
|
||||
- If tests fail in REFACTOR phase: Undo refactor, commit was premature.
|
||||
|
||||
**Verification:**
|
||||
After TDD task completion, ensure:
|
||||
After TDD plan completion, ensure:
|
||||
- All tests pass
|
||||
- Test coverage for the new behavior exists
|
||||
- No unrelated tests broken
|
||||
|
||||
**Note:** TDD tasks produce 2-3 commits (test/feat/refactor). Non-TDD tasks produce 1 commit after task completion.
|
||||
</tdd_execution>
|
||||
**Why TDD uses dedicated plans:** 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 plans ensure full quality throughout the cycle.
|
||||
|
||||
**Comparison:**
|
||||
- Standard plans: Multiple tasks, 1 commit per task, 2-4 commits total
|
||||
- TDD plans: Single feature, 2-3 commits for RED/GREEN/REFACTOR cycle
|
||||
|
||||
See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure.
|
||||
</tdd_plan_execution>
|
||||
|
||||
<task_commit>
|
||||
## Task Commit Protocol
|
||||
@@ -917,7 +924,7 @@ git commit -m "{type}({phase}-{plan}): {concise task description}
|
||||
**Examples:**
|
||||
|
||||
```bash
|
||||
# Non-TDD task
|
||||
# Standard plan task
|
||||
git commit -m "feat(08-02): create user registration endpoint
|
||||
|
||||
- POST /auth/register validates email and password
|
||||
@@ -925,31 +932,16 @@ git commit -m "feat(08-02): create user registration endpoint
|
||||
- Returns JWT token on success
|
||||
"
|
||||
|
||||
# TDD task - RED phase
|
||||
git commit -m "test(07-02): add failing test for JWT generation
|
||||
# Another standard task
|
||||
git commit -m "fix(08-02): correct email validation regex
|
||||
|
||||
- Tests token contains user ID claim
|
||||
- Tests token expires in 1 hour
|
||||
- Tests signature verification
|
||||
"
|
||||
|
||||
# TDD task - GREEN phase
|
||||
git commit -m "feat(07-02): implement JWT generation
|
||||
|
||||
- Uses jose library for signing
|
||||
- Includes user ID and expiry claims
|
||||
- Signs with HS256 algorithm
|
||||
"
|
||||
|
||||
# TDD task - REFACTOR phase
|
||||
git commit -m "refactor(07-02): extract JWT config to constants
|
||||
|
||||
- Moved expiry time to constant
|
||||
- Centralized algorithm selection
|
||||
- No behavior changes
|
||||
- Fixed regex to accept plus-addressing
|
||||
- Added tests for edge cases
|
||||
"
|
||||
```
|
||||
|
||||
**Note:** TDD plans have their own commit pattern (test/feat/refactor for RED/GREEN/REFACTOR phases). See `<tdd_plan_execution>` section above.
|
||||
|
||||
**5. Record commit hash:**
|
||||
|
||||
After committing, capture hash for SUMMARY.md:
|
||||
|
||||
@@ -225,7 +225,9 @@ cat .planning/phases/XX-name/${PHASE}-CONTEXT.md 2>/dev/null
|
||||
</step>
|
||||
|
||||
<step name="break_into_tasks">
|
||||
Decompose phase into tasks. Each task needs:
|
||||
Decompose phase into tasks and identify TDD candidates.
|
||||
|
||||
**Standard tasks need:**
|
||||
- **Type**: auto, checkpoint:human-verify, checkpoint:decision (human-action rarely needed)
|
||||
- **Task name**: Clear, action-oriented
|
||||
- **Files**: Which files created/modified (for auto tasks)
|
||||
@@ -233,9 +235,9 @@ Decompose phase into tasks. Each task needs:
|
||||
- **Verify**: How to prove it worked
|
||||
- **Done**: Acceptance criteria
|
||||
|
||||
**TDD detection:** For each task, evaluate TDD fit:
|
||||
**TDD detection:** For each potential task, evaluate TDD fit:
|
||||
|
||||
TDD candidates (add `tdd="true"` to task, include `<test-first>` element):
|
||||
TDD candidates (create dedicated TDD plans):
|
||||
- Business logic with defined inputs/outputs
|
||||
- API endpoints with request/response contracts
|
||||
- Data transformations, parsing, formatting
|
||||
@@ -243,7 +245,7 @@ TDD candidates (add `tdd="true"` to task, include `<test-first>` element):
|
||||
- Algorithms with testable behavior
|
||||
- State machines and workflows
|
||||
|
||||
Skip TDD (standard `type="auto"` task):
|
||||
Standard tasks (remain in standard plans):
|
||||
- UI layout, styling, visual components
|
||||
- Configuration changes
|
||||
- Glue code connecting existing components
|
||||
@@ -251,15 +253,14 @@ Skip TDD (standard `type="auto"` task):
|
||||
- Simple CRUD with no business logic
|
||||
|
||||
**Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
|
||||
→ Yes: Add `tdd="true"`, include `<test-first>` describing the failing test
|
||||
→ No: Standard task, no TDD annotation
|
||||
→ Yes: Create a dedicated TDD plan for this feature (one feature per TDD plan)
|
||||
→ No: Standard task in standard plan
|
||||
|
||||
**Test framework:** If project has no test setup and TDD tasks exist, add a setup task first:
|
||||
- Detect project type (package.json → Jest, requirements.txt → pytest, etc.)
|
||||
- Add minimal test configuration
|
||||
- Create example test file to verify setup
|
||||
**Why TDD gets its own plan:** TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR), each with file reads, test runs, and potential debugging. Embedded in a multi-task plan, TDD work consumes 50-60% of context alone, degrading quality for remaining tasks.
|
||||
|
||||
See `~/.claude/get-shit-done/references/tdd.md` for complete TDD guidance.
|
||||
**Test framework:** If project has no test setup and TDD plans are needed, the first TDD plan's RED phase handles framework setup as part of writing the first test.
|
||||
|
||||
See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure.
|
||||
|
||||
**Checkpoints:** Visual/functional verification → checkpoint:human-verify. Implementation choices → checkpoint:decision. Manual action (email, 2FA) → checkpoint:human-action (rare).
|
||||
|
||||
@@ -427,20 +428,7 @@ Phase plan created: .planning/phases/XX-name/{phase}-01-PLAN.md
|
||||
|
||||
If you can't specify Files + Action + Verify + Done, the task is too vague.
|
||||
|
||||
**Good TDD task:**
|
||||
```xml
|
||||
<task type="auto" tdd="true">
|
||||
<name>Create price calculator with discount rules</name>
|
||||
<files>src/lib/pricing.ts, src/lib/pricing.test.ts</files>
|
||||
<test-first>
|
||||
Test: calculatePrice applies discounts correctly
|
||||
Cases: base 100 + 10% off → 90, base 100 + 20% off + $5 coupon → 75
|
||||
</test-first>
|
||||
<action>Implement calculatePrice(base, discountPercent, couponAmount). Apply percentage first, then flat amount.</action>
|
||||
<verify>npm test -- pricing.test.ts passes</verify>
|
||||
<done>Price calculation handles all discount combinations correctly</done>
|
||||
</task>
|
||||
```
|
||||
**TDD candidates get dedicated plans.** If "Create price calculator with discount rules" warrants TDD, create a TDD plan for it. See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure.
|
||||
</task_quality>
|
||||
|
||||
<anti_patterns>
|
||||
|
||||
Reference in New Issue
Block a user