golem15/msd-core
4
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity

feat: TDD features use dedicated plans for full context quality

Browse Source 
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
2026-01-05 21:55:36 -06:00
parent 7bc80699f3
commit 85f0ea5c58
7 changed files with 205 additions and 137 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
get-shit-done/references/plan-format.md
View File

@@ -243,42 +243,30 @@ Use for: Technology selection, architecture decisions, design choices, feature p
See `./checkpoints.md` for comprehensive checkpoint guidance. See `./checkpoints.md` for comprehensive checkpoint guidance.
</task_types> </task_types>
<tdd_annotation> <tdd_plans>
Tasks can include `tdd="true"` attribute when TDD improves quality: **TDD work uses dedicated plans.**
**Structure:** 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.
```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>
```
**When to add tdd="true":** **When to create a TDD plan:**
- Business logic with defined inputs/outputs - Business logic with defined inputs/outputs
- API endpoints with request/response contracts - API endpoints with request/response contracts
- Data transformations and parsing - Data transformations and parsing
- Validation rules - Validation rules
- Algorithms with testable behavior - Algorithms with testable behavior
**When NOT to add tdd="true":** **When to use standard plans (skip TDD):**
- UI layout and styling - UI layout and styling
- Configuration changes - Configuration changes
- Glue code connecting existing components - Glue code connecting existing components
- One-off scripts - One-off scripts
**Execution flow (when tdd="true"):** **Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
1. Claude writes failing test from `<test-first>` → Yes: Create a TDD plan (one feature per plan)
2. Claude implements from `<action>` until test passes → No: Use standard plan, add tests after if needed
3. Claude refactors if needed (tests still pass)
4. Claude commits atomic change
See `./tdd.md` for comprehensive TDD guidance. See `./tdd.md` for TDD plan structure and execution guidance.
</tdd_annotation> </tdd_plans>
<context_references> <context_references>
Use @file references to load context for the prompt: 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. Claude can implement this immediately.
</just_right> </just_right>
<tdd_example> <note_on_tdd>
TDD task example: **TDD candidates get dedicated plans.**
```xml If email validation warrants TDD, create a TDD plan for it. See `./tdd.md` for TDD plan structure.
<task type="auto" tdd="true"> </note_on_tdd>
<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>
<too_detailed> <too_detailed>
Writing the actual code in the plan. Trust Claude to implement from clear instructions. Writing the actual code in the plan. Trust Claude to implement from clear instructions.

22
get-shit-done/references/principles.md
View File

@@ -77,7 +77,7 @@ Plans are guides, not straitjackets. During execution:
Use TDD when the work WOULD benefit from it. Not dogma—pragmatism. 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 - Business logic with defined inputs/outputs
- API endpoints and handlers - API endpoints and handlers
- Data transformations and parsing - Data transformations and parsing
@@ -85,7 +85,7 @@ Use TDD when the work WOULD benefit from it. Not dogma—pragmatism.
- State machines and workflows - State machines and workflows
- Anything where you can describe expected behavior before implementing - Anything where you can describe expected behavior before implementing
**Skip TDD for:** **Skip TDD (use standard plan):**
- UI layout and styling - UI layout and styling
- Exploratory prototyping - Exploratory prototyping
- One-off scripts and migrations - One-off scripts and migrations
@@ -94,16 +94,20 @@ Use TDD when the work WOULD benefit from it. Not dogma—pragmatism.
**Decision heuristic:** **Decision heuristic:**
Can you write `expect(fn(input)).toBe(output)` before writing `fn`? Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
→ Yes: TDD will help → Yes: Create a TDD plan (one feature per plan)
→ No: Write implementation first, add tests after if needed → No: Standard plan, add tests after if needed
**TDD task structure:** **Why TDD gets its own plan:**
When TDD applies, structure tasks as test-first: 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.
1. Write failing test (red)
2. Implement to pass (green) **TDD plan structure:**
3. Refactor if needed 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. 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> </test_driven_when_beneficial>
<ship_fast> <ship_fast>

21
get-shit-done/references/scope-estimation.md
View File

@@ -38,6 +38,27 @@ Why 50% not 80%?
**When in doubt: Default to 2 tasks.** Better to have an extra plan than degraded quality. **When in doubt: Default to 2 tasks.** Better to have an extra plan than degraded quality.
</task_rule> </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> <split_signals>
<always_split> <always_split>

120
get-shit-done/references/tdd.md
View File

@@ -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. 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. **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> </overview>
<detection> <when_to_use_tdd>
## When TDD Improves Quality ## When TDD Improves Quality
**TDD candidates (add `tdd="true"`, include `<test-first>`):** **TDD candidates (create a TDD plan):**
- Business logic with defined inputs/outputs - Business logic with defined inputs/outputs
- API endpoints with request/response contracts - API endpoints with request/response contracts
- Data transformations, parsing, formatting - 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 - State machines and workflows
- Utility functions with clear specifications - Utility functions with clear specifications
**Skip TDD (standard `type="auto"`):** **Skip TDD (use standard plan with `type="auto"` tasks):**
- UI layout, styling, visual components - UI layout, styling, visual components
- Configuration changes - Configuration changes
- Glue code connecting existing components - Glue code connecting existing components
@@ -25,32 +27,89 @@ TDD is about design quality, not coverage metrics. The red-green-refactor cycle
- Exploratory prototyping - Exploratory prototyping
**Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`? **Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
→ Yes: TDD will help → Yes: Create a TDD plan
→ No: Implement first, add tests after if needed → No: Use standard plan, add tests after if needed
</detection> </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> <execution_flow>
## Red-Green-Refactor Cycle ## Red-Green-Refactor Cycle
**RED - Write failing test:** **RED - Write failing test:**
1. Create test file following project conventions 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 3. Run test - it MUST fail
4. If test passes: feature exists or test is wrong. Investigate. 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:** **GREEN - Implement to pass:**
1. Write minimal code to make test pass 1. Write minimal code to make test pass
2. No cleverness, no optimization - just make it work 2. No cleverness, no optimization - just make it work
3. Run test - it MUST pass 3. Run test - it MUST pass
4. Commit: `feat: implement [feature]` 4. Commit: `feat({phase}-{plan}): implement [feature]`
**REFACTOR (if needed):** **REFACTOR (if needed):**
1. Clean up implementation if obvious improvements exist 1. Clean up implementation if obvious improvements exist
2. Run tests - MUST still pass 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> </execution_flow>
<test_quality> <test_quality>
@@ -77,7 +136,7 @@ TDD is about design quality, not coverage metrics. The red-green-refactor cycle
<framework_setup> <framework_setup>
## Test Framework Setup (If None Exists) ## 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:** **1. Detect project type:**
```bash ```bash
@@ -122,6 +181,8 @@ Follow project conventions for test location:
- `*.test.ts` / `*.spec.ts` next to source - `*.test.ts` / `*.spec.ts` next to source
- `__tests__/` directory - `__tests__/` directory
- `tests/` directory at root - `tests/` directory at root
Framework setup is a one-time cost included in the first TDD plan's RED phase.
</framework_setup> </framework_setup>
<error_handling> <error_handling>
@@ -134,7 +195,7 @@ Follow project conventions for test location:
**Test doesn't pass in GREEN phase:** **Test doesn't pass in GREEN phase:**
- Debug implementation - Debug implementation
- Don't skip to next task - Don't skip to refactor
- Keep iterating until green - Keep iterating until green
**Tests fail in REFACTOR phase:** **Tests fail in REFACTOR phase:**
@@ -149,39 +210,54 @@ Follow project conventions for test location:
</error_handling> </error_handling>
<commit_pattern> <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 valid email formats accepted
- Tests invalid formats rejected - Tests invalid formats rejected
- Tests empty input handling - Tests empty input handling
feat({phase}-{plan}): implement email validation feat(08-02): implement email validation
- Regex pattern matches RFC 5322 - Regex pattern matches RFC 5322
- Returns boolean for validity - Returns boolean for validity
- Handles edge cases (empty, null) - 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 - Moved pattern to EMAIL_REGEX constant
- No behavior changes - No behavior changes
- Tests still pass - Tests still pass
``` ```
**This aligns with the standard task commit pattern:** **Comparison with standard plans:**
- Non-TDD tasks: 1 commit per task (feat/fix) - Standard plans: 1 commit per task, 2-4 commits per plan
- TDD tasks: 2-3 commits per task (test/feat/refactor) - TDD plans: 2-3 commits for single feature
Both follow same format: `{type}({phase}-{plan}): {description}` Both follow same format: `{type}({phase}-{plan}): {description}`
**Benefits:** **Benefits:**
- Each commit independently revertable - 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 - Clear history showing TDD discipline
- Consistent with overall commit strategy - Consistent with overall commit strategy
</commit_pattern> </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>

15
get-shit-done/templates/phase-prompt.md
View File

@@ -169,7 +169,20 @@ From create-meta-prompts patterns:
- Different subsystems (auth vs API vs UI) - Different subsystems (auth vs API vs UI)
- Clear dependency boundaries (setup → implement → test) - Clear dependency boundaries (setup → implement → test)
- Risk of context overflow (>50% estimated usage) - Risk of context overflow (>50% estimated usage)
</scope_guidance> - **TDD candidates** - Features that warrant TDD become their own TDD plans
</scope_guidance>
<tdd_plan_note>
**TDD features get dedicated plans.**
TDD requires 2-3 execution cycles (RED → GREEN → REFACTOR) that consume 40-50% context for a single feature. Features warranting TDD (business logic, validation, algorithms, API contracts) each get their own TDD plan.
**Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
→ Yes: Create a TDD plan (one feature per plan)
→ No: Standard task in standard plan
See `~/.claude/get-shit-done/references/tdd.md` for TDD plan structure.
</tdd_plan_note>
<good_examples> <good_examples>

72
get-shit-done/workflows/execute-phase.md
View File

@@ -815,55 +815,62 @@ Logged to .planning/ISSUES.md for future consideration:
</deviation_documentation> </deviation_documentation>
<tdd_execution> <tdd_plan_execution>
## TDD Task 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: If no test framework configured:
- Detect project type from package.json/requirements.txt/etc. - Detect project type from package.json/requirements.txt/etc.
- Install minimal test framework (Jest, pytest, Go testing, etc.) - Install minimal test framework (Jest, pytest, Go testing, etc.)
- Create test config file - Create test config file
- Verify: run empty test suite - Verify: run empty test suite
- This is part of the RED phase, not a separate task
**2. RED - Write failing test:** **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) - Create test file if doesn't exist (follow project conventions)
- Write test(s) that describe expected behavior - Write test(s) that describe expected behavior
- Run tests - MUST fail (if passes, test is wrong or feature exists) - 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:** **3. GREEN - Implement to pass:**
- Read `<action>` element for implementation guidance - Read `<implementation>` element for guidance
- Write minimal code to make test pass - Write minimal code to make test pass
- Run tests - MUST pass - Run tests - MUST pass
- Commit: "feat: implement [feature]" - Commit: `feat({phase}-{plan}): implement [feature]`
**4. REFACTOR (if needed):** **4. REFACTOR (if needed):**
- Clean up code if obvious improvements - Clean up code if obvious improvements
- Run tests - MUST still pass - 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:** **Commit pattern for TDD plans:**
Each TDD task produces 2-3 atomic commits: Each TDD plan produces 2-3 atomic commits:
1. `test: add failing test for X` 1. `test({phase}-{plan}): add failing test for X`
2. `feat: implement X` 2. `feat({phase}-{plan}): implement X`
3. `refactor: clean up X` (optional) 3. `refactor({phase}-{plan}): clean up X` (optional)
**Error handling:** **Error handling:**
- If test doesn't fail in RED phase: Test is wrong or feature already exists. Investigate before proceeding. - 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. - If tests fail in REFACTOR phase: Undo refactor, commit was premature.
**Verification:** **Verification:**
After TDD task completion, ensure: After TDD plan completion, ensure:
- All tests pass - All tests pass
- Test coverage for the new behavior exists - Test coverage for the new behavior exists
- No unrelated tests broken - No unrelated tests broken
**Note:** TDD tasks produce 2-3 commits (test/feat/refactor). Non-TDD tasks produce 1 commit after task completion. **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.
</tdd_execution>
**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>
## Task Commit Protocol ## Task Commit Protocol
@@ -917,7 +924,7 @@ git commit -m "{type}({phase}-{plan}): {concise task description}
**Examples:** **Examples:**
```bash ```bash
# Non-TDD task # Standard plan task
git commit -m "feat(08-02): create user registration endpoint git commit -m "feat(08-02): create user registration endpoint
- POST /auth/register validates email and password - 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 - Returns JWT token on success
" "
# TDD task - RED phase # Another standard task
git commit -m "test(07-02): add failing test for JWT generation git commit -m "fix(08-02): correct email validation regex
- Tests token contains user ID claim - Fixed regex to accept plus-addressing
- Tests token expires in 1 hour - Added tests for edge cases
- 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
" "
``` ```
**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:** **5. Record commit hash:**
After committing, capture hash for SUMMARY.md: After committing, capture hash for SUMMARY.md:

38
get-shit-done/workflows/plan-phase.md
View File

@@ -225,7 +225,9 @@ cat .planning/phases/XX-name/${PHASE}-CONTEXT.md 2>/dev/null
</step> </step>
<step name="break_into_tasks"> <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) - **Type**: auto, checkpoint:human-verify, checkpoint:decision (human-action rarely needed)
- **Task name**: Clear, action-oriented - **Task name**: Clear, action-oriented
- **Files**: Which files created/modified (for auto tasks) - **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 - **Verify**: How to prove it worked
- **Done**: Acceptance criteria - **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 - Business logic with defined inputs/outputs
- API endpoints with request/response contracts - API endpoints with request/response contracts
- Data transformations, parsing, formatting - Data transformations, parsing, formatting
@@ -243,7 +245,7 @@ TDD candidates (add `tdd="true"` to task, include `<test-first>` element):
- Algorithms with testable behavior - Algorithms with testable behavior
- State machines and workflows - State machines and workflows
Skip TDD (standard `type="auto"` task): Standard tasks (remain in standard plans):
- UI layout, styling, visual components - UI layout, styling, visual components
- Configuration changes - Configuration changes
- Glue code connecting existing components - Glue code connecting existing components
@@ -251,15 +253,14 @@ Skip TDD (standard `type="auto"` task):
- Simple CRUD with no business logic - Simple CRUD with no business logic
**Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`? **Heuristic:** Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
→ Yes: Add `tdd="true"`, include `<test-first>` describing the failing test → Yes: Create a dedicated TDD plan for this feature (one feature per TDD plan)
→ No: Standard task, no TDD annotation → No: Standard task in standard plan
**Test framework:** If project has no test setup and TDD tasks exist, add a setup task first: **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.
- Detect project type (package.json → Jest, requirements.txt → pytest, etc.)
- Add minimal test configuration
- Create example test file to verify setup
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). **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. If you can't specify Files + Action + Verify + Done, the task is too vague.
**Good TDD 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.
```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>
```
</task_quality> </task_quality>
<anti_patterns> <anti_patterns>