get-shit-done-cc 1.3.19 → 1.3.21

package/README.md

@@ -171,9 +171,24 @@ GSD prevents this. Each plan is maximum 3 tasks. Each plan runs in a fresh subag
 
 No degradation. Walk away, come back to completed work.
 
-### Clean Git History
+### Atomic Git Commits
 
-Every task: atomic commit, clear message, summary documenting outcomes. Maintainable history you can trace.
+Each task gets its own commit immediately after completion. Plans produce 2-4 commits total:
+
+```bash
+abc123f docs(08-02): complete user registration plan
+def456g feat(08-02): add email confirmation flow
+hij789k feat(08-02): implement password hashing
+lmn012o feat(08-02): create registration endpoint
+```
+
+**Benefits:**
+- Git bisect finds exact failing task
+- Each task independently revertable
+- Clear history for Claude in future sessions
+- Better observability in AI-automated workflow
+
+Every commit is surgical, traceable, and meaningful.
 
 ### Modular by Design
 

package/commands/gsd/execute-plan.md

@@ -14,10 +14,13 @@ allowed-tools:
 ---
 
 <objective>
-Execute a PLAN.md file, create SUMMARY.md, update project state, commit.
+Execute a PLAN.md file with per-task atomic commits, create SUMMARY.md, update project state.
 
-Uses intelligent segmentation:
+Commit strategy:
+- Each task → 1 commit immediately after completion (feat/fix/test/refactor)
+- Plan completion → 1 metadata commit (docs: SUMMARY + STATE + ROADMAP)
 
+Uses intelligent segmentation:
 - Plans without checkpoints → spawn subagent for full autonomous execution
 - Plans with verify checkpoints → segment execution, pause at checkpoints
 - Plans with decision checkpoints → execute in main context
@@ -88,23 +91,38 @@ Only rule 4 requires user intervention.
 </deviation_rules>
 
 <commit_rules>
-**Critical: Stage only files this plan actually modified.**
+**Per-Task Commits:**
+
+After each task completes:
+1. Stage only files modified by that task
+2. Commit with format: `{type}({phase}-{plan}): {task-name}`
+3. Types: feat, fix, test, refactor, perf, chore
+4. Record commit hash for SUMMARY.md
 
-NEVER use:
+**Plan Metadata Commit:**
 
+After all tasks complete:
+1. Stage planning artifacts only: PLAN.md, SUMMARY.md, STATE.md, ROADMAP.md
+2. Commit with format: `docs({phase}-{plan}): complete [plan-name] plan`
+3. NO code files (already committed per-task)
+
+**NEVER use:**
 - `git add .`
 - `git add -A`
 - `git add src/` or any broad directory
 
-Stage each file individually from the modified-files list.
+**Always stage files individually.**
+
+See ~/.claude/get-shit-done/references/git-integration.md for full commit strategy.
 </commit_rules>
 
 <success_criteria>
 
 - [ ] All tasks executed
-- [ ] SUMMARY.md created with substantive content
+- [ ] Each task committed individually (feat/fix/test/refactor)
+- [ ] SUMMARY.md created with substantive content and commit hashes
 - [ ] STATE.md updated (position, decisions, issues, session)
 - [ ] ROADMAP updated (plan count, phase status)
-- [ ] Changes committed with feat({phase}-{plan}): [summary]
+- [ ] Metadata committed with docs({phase}-{plan}): complete [plan-name] plan
 - [ ] User informed of next steps
       </success_criteria>

package/get-shit-done/references/git-integration.md

@@ -11,14 +11,15 @@ The git log should read like a changelog of what shipped, not a diary of plannin
 
 <commit_points>
 
-| Event                   | Commit? | Why                                   |
-| ----------------------- | ------- | ------------------------------------- |
-| BRIEF + ROADMAP created | YES     | Project initialization                |
-| PLAN.md created         | NO      | Intermediate - commit with completion |
-| RESEARCH.md created     | NO      | Intermediate                          |
-| DISCOVERY.md created    | NO      | Intermediate                          |
-| **Phase completed**     | YES     | Actual code shipped                   |
-| Handoff created         | YES     | WIP state preserved                   |
+| Event                   | Commit? | Why                                              |
+| ----------------------- | ------- | ------------------------------------------------ |
+| BRIEF + ROADMAP created | YES     | Project initialization                           |
+| PLAN.md created         | NO      | Intermediate - commit with plan completion       |
+| RESEARCH.md created     | NO      | Intermediate                                     |
+| DISCOVERY.md created    | NO      | Intermediate                                     |
+| **Task completed**      | YES     | Atomic unit of work (1 commit per task)         |
+| **Plan completed**      | YES     | Metadata commit (SUMMARY + STATE + ROADMAP)     |
+| Handoff created         | YES     | WIP state preserved                              |
 
 </commit_points>
 
@@ -56,30 +57,88 @@ git commit
 
 </format>
 
-<format name="phase-completion">
-## Phase Completion
+<format name="task-completion">
+## Task Completion (During Plan Execution)
 
+Each task gets its own commit immediately after completion.
+
+```
+{type}({phase}-{plan}): {task-name}
+
+- [Key change 1]
+- [Key change 2]
+- [Key change 3]
+```
+
+**Commit types:**
+- `feat` - New feature/functionality
+- `fix` - Bug fix
+- `test` - Test-only (TDD RED phase)
+- `refactor` - Code cleanup (TDD REFACTOR phase)
+- `perf` - Performance improvement
+- `chore` - Dependencies, config, tooling
+
+**Examples:**
+
+```bash
+# Standard task
+git add src/api/auth.ts src/types/user.ts
+git commit -m "feat(08-02): create user registration endpoint
+
+- POST /auth/register validates email and password
+- Checks for duplicate users
+- Returns JWT token on success
+"
+
+# TDD task - RED phase
+git add src/__tests__/jwt.test.ts
+git commit -m "test(07-02): add failing test for JWT generation
+
+- Tests token contains user ID claim
+- Tests token expires in 1 hour
+- Tests signature verification
+"
+
+# TDD task - GREEN phase
+git add src/utils/jwt.ts
+git commit -m "feat(07-02): implement JWT generation
+
+- Uses jose library for signing
+- Includes user ID and expiry claims
+- Signs with HS256 algorithm
+"
 ```
-feat([domain]): [one-liner from SUMMARY.md]
 
-- [Key accomplishment 1]
-- [Key accomplishment 2]
-- [Key accomplishment 3]
+</format>
+
+<format name="plan-completion">
+## Plan Completion (After All Tasks Done)
+
+After all tasks committed, one final metadata commit captures plan completion.
 
-[If issues encountered:]
-Note: [issue and resolution]
 ```
+docs({phase}-{plan}): complete [plan-name] plan
 
-Use `fix([domain])` for bug fix phases.
+Tasks completed: [N]/[N]
+- [Task 1 name]
+- [Task 2 name]
+- [Task 3 name]
+
+SUMMARY: .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
+```
 
 What to commit:
 
 ```bash
-git add .planning/phases/XX-name/  # PLAN.md + SUMMARY.md
-git add src/                        # Actual code created
+git add .planning/phases/XX-name/{phase}-{plan}-PLAN.md
+git add .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
+git add .planning/STATE.md
+git add .planning/ROADMAP.md
 git commit
 ```
 
+**Note:** Code files NOT included - already committed per-task.
+
 </format>
 
 <format name="handoff">
@@ -104,23 +163,92 @@ git commit
 
 <example_log>
 
+**Old approach (per-plan commits):**
 ```
-a]7f2d1 feat(checkout): Stripe payments with webhook verification
-b]3e9c4 feat(products): catalog with search, filters, and pagination
-c]8a1b2 feat(auth): JWT with refresh rotation using jose
-d]5c3d7 feat(foundation): Next.js 15 + Prisma + Tailwind scaffold
-e]2f4a8 docs: initialize ecommerce-app (5 phases)
+a7f2d1 feat(checkout): Stripe payments with webhook verification
+3e9c4b feat(products): catalog with search, filters, and pagination
+8a1b2c feat(auth): JWT with refresh rotation using jose
+5c3d7e feat(foundation): Next.js 15 + Prisma + Tailwind scaffold
+2f4a8d docs: initialize ecommerce-app (5 phases)
 ```
 
+**New approach (per-task commits):**
+```
+# Phase 04 - Checkout
+1a2b3c docs(04-01): complete checkout flow plan
+4d5e6f feat(04-01): add webhook signature verification
+7g8h9i feat(04-01): implement payment session creation
+0j1k2l feat(04-01): create checkout page component
+
+# Phase 03 - Products
+3m4n5o docs(03-02): complete product listing plan
+6p7q8r feat(03-02): add pagination controls
+9s0t1u feat(03-02): implement search and filters
+2v3w4x feat(03-01): create product catalog schema
+
+# Phase 02 - Auth
+5y6z7a docs(02-02): complete token refresh plan
+8b9c0d feat(02-02): implement refresh token rotation
+1e2f3g test(02-02): add failing test for token refresh
+4h5i6j docs(02-01): complete JWT setup plan
+7k8l9m feat(02-01): add JWT generation and validation
+0n1o2p chore(02-01): install jose library
+
+# Phase 01 - Foundation
+3q4r5s docs(01-01): complete scaffold plan
+6t7u8v feat(01-01): configure Tailwind and globals
+9w0x1y feat(01-01): set up Prisma with database
+2z3a4b feat(01-01): create Next.js 15 project
+
+# Initialization
+5c6d7e docs: initialize ecommerce-app (5 phases)
+```
+
+Each plan produces 2-4 commits (tasks + metadata). Clear, granular, bisectable.
+
 </example_log>
 
 <anti_patterns>
 
-- PLAN.md creation (wait for phase completion)
+**Still don't commit (intermediate artifacts):**
+- PLAN.md creation (commit with plan completion)
 - RESEARCH.md (intermediate)
 - DISCOVERY.md (intermediate)
 - Minor planning tweaks
 - "Fixed typo in roadmap"
 
-These create noise. Commit outcomes, not process.
+**Do commit (outcomes):**
+- Each task completion (feat/fix/test/refactor)
+- Plan completion metadata (docs)
+- Project initialization (docs)
+
+**Key principle:** Commit working code and shipped outcomes, not planning process.
+
 </anti_patterns>
+
+<commit_strategy_rationale>
+
+## Why Per-Task Commits?
+
+**Context engineering for AI:**
+- Git history becomes primary context source for future Claude sessions
+- `git log --grep="{phase}-{plan}"` shows all work for a plan
+- `git diff <hash>^..<hash>` shows exact changes per task
+- Less reliance on parsing SUMMARY.md = more context for actual work
+
+**Failure recovery:**
+- Task 1 committed ✅, Task 2 failed ❌
+- Claude in next session: sees task 1 complete, can retry task 2
+- Can `git reset --hard` to last successful task
+
+**Debugging:**
+- `git bisect` finds exact failing task, not just failing plan
+- `git blame` traces line to specific task context
+- Each commit is independently revertable
+
+**Observability:**
+- Solo developer + Claude workflow benefits from granular attribution
+- Atomic commits are git best practice
+- "Commit noise" irrelevant when consumer is Claude, not humans
+
+</commit_strategy_rationale>

package/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:
-
-```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>
-```
+<note_on_tdd>
+**TDD candidates get dedicated plans.**
 
-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.

package/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>
@@ -115,6 +119,29 @@ Plan → Execute → Ship → Learn → Repeat
 Milestones mark shipped versions (v1.0 → v1.1 → v2.0).
 </ship_fast>
 
+<atomic_commits>
+
+**Git commits = context engineering for Claude.**
+
+Each task gets its own commit immediately after completion:
+- Format: `{type}({phase}-{plan}): {task-description}`
+- Types: feat, fix, test, refactor, perf, chore, docs
+- One final metadata commit per plan: `docs({phase}-{plan}): complete [plan-name]`
+
+**Why per-task commits:**
+- Git history becomes primary context source for future Claude sessions
+- `git bisect` finds exact failing task, not just failing plan
+- Each task independently revertable
+- Better failure recovery (task 1 committed ✅, retry task 2)
+- Observability optimized for AI workflow, not human browsing
+
+**Plans produce 3-4 commits total:**
+- 2-3 task commits (working code)
+- 1 metadata commit (SUMMARY + STATE + ROADMAP)
+
+See `~/.claude/get-shit-done/references/git-integration.md` for complete strategy.
+</atomic_commits>
+
 <anti_enterprise>
 
 NEVER include:

package/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>
@@ -80,7 +101,7 @@ Plan 1: "Auth Database Models" (2 tasks)
 Plan 2: "Auth API Core" (3 tasks)
 Plan 3: "Auth API Protection" (2 tasks)
 Plan 4: "Auth UI Components" (2 tasks)
-Each: 30-40% context, peak quality, focused commits
+Each: 30-40% context, peak quality, atomic commits (2-3 task commits + 1 metadata commit)
 ```
 </anti_patterns>
 
@@ -137,7 +158,7 @@ Each plan: fresh context, peak quality. More plans = more thoroughness, same qua
 <summary>
 **2-3 tasks, 50% context target:**
 - All tasks: Peak quality
-- Git: Atomic, surgical commits
+- Git: Atomic per-task commits (each task = 1 commit, plan = 1 metadata commit)
 - Autonomous plans: Subagent execution (fresh context)
 
 **The principle:** Aggressive atomicity. More plans, smaller scope, consistent quality.
@@ -145,5 +166,7 @@ Each plan: fresh context, peak quality. More plans = more thoroughness, same qua
 **The rule:** If in doubt, split. Quality over consolidation. Always.
 
 **Depth rule:** Depth increases plan COUNT, never plan SIZE.
+
+**Commit rule:** Each plan produces 3-4 commits total (2-3 task commits + 1 docs commit). More granular history = better observability for Claude.
 </summary>
 </scope_estimation>

package/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,20 +210,54 @@ Follow project conventions for test location:
 </error_handling>
 
 <commit_pattern>
-## Commit Pattern for TDD Tasks
+## Commit Pattern for TDD Plans
 
-Each TDD task produces atomic commits:
+TDD plans produce 2-3 atomic commits (one per phase):
 
 ```
-test: 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(08-02): implement email validation
+
+- Regex pattern matches RFC 5322
+- Returns boolean for validity
+- Handles edge cases (empty, null)
 
-feat: implement email validation
+refactor(08-02): extract regex to constant (optional)
 
-refactor: extract regex to constant (optional)
+- Moved pattern to EMAIL_REGEX constant
+- No behavior changes
+- Tests still pass
 ```
 
-This pattern:
-- Creates clean git history
-- Each commit is independently revertable
-- Shows TDD discipline in commit log
+**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
+- 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>

package/get-shit-done/templates/phase-prompt.md

@@ -169,7 +169,20 @@ From create-meta-prompts patterns:
 - Different subsystems (auth vs API vs UI)
 - Clear dependency boundaries (setup → implement → test)
 - 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>
 

package/get-shit-done/templates/summary.md

@@ -62,6 +62,18 @@ completed: YYYY-MM-DD
 - [Second key accomplishment]
 - [Third if applicable]
 
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: [task name]** - `abc123f` (feat/fix/test/refactor)
+2. **Task 2: [task name]** - `def456g` (feat/fix/test/refactor)
+3. **Task 3: [task name]** - `hij789k` (feat/fix/test/refactor)
+
+**Plan metadata:** `lmn012o` (docs: complete plan)
+
+_Note: TDD tasks may have multiple commits (test → feat → refactor)_
+
 ## Files Created/Modified
 - `path/to/file.ts` - What it does
 - `path/to/another.ts` - What it does
@@ -83,7 +95,7 @@ completed: YYYY-MM-DD
 - **Fix:** [What was done]
 - **Files modified:** [file paths]
 - **Verification:** [How it was verified]
-- **Commit:** [hash]
+- **Committed in:** [hash] (part of task commit)
 
 [... repeat for each auto-fix ...]
 
@@ -189,7 +201,7 @@ The one-liner should tell someone what actually shipped.
 - **Fix:** Added bcrypt hashing on registration, comparison on login with salt rounds 10
 - **Files modified:** src/app/api/auth/login/route.ts, src/lib/auth.ts
 - **Verification:** Password hash test passes, plaintext never stored
-- **Commit:** abc123f
+- **Committed in:** abc123f (Task 2 commit)
 
 **2. [Rule 3 - Blocking] Installed missing jose dependency**
 - **Found during:** Task 4 (JWT token generation)
@@ -197,7 +209,7 @@ The one-liner should tell someone what actually shipped.
 - **Fix:** Ran `npm install jose`
 - **Files modified:** package.json, package-lock.json
 - **Verification:** Import succeeds, build passes
-- **Commit:** def456g
+- **Committed in:** def456g (Task 4 commit)
 
 ### Deferred Enhancements
 

package/get-shit-done/workflows/execute-phase.md

@@ -440,8 +440,8 @@ Execute each task in the prompt. **Deviations are normal** - handle them automat
    **If `type="auto"`:**
 
    **Before executing:** Check if task has `tdd="true"` attribute:
-   - If yes: Follow TDD execution flow (see `<tdd_execution>`) - RED → GREEN → REFACTOR cycle with multiple atomic commits
-   - If no: Standard implementation with single commit
+   - If yes: Follow TDD execution flow (see `<tdd_execution>`) - RED → GREEN → REFACTOR cycle with atomic commits per stage
+   - If no: Standard implementation
 
    - Work toward task completion
    - **If CLI/API returns authentication error:** Handle as authentication gate (see below)
@@ -449,7 +449,8 @@ Execute each task in the prompt. **Deviations are normal** - handle them automat
    - Continue implementing, applying rules as needed
    - Run the verification
    - Confirm done criteria met
-   - Track any deviations for Summary documentation
+   - **Commit the task** (see `<task_commit>` below)
+   - Track task completion and commit hash for Summary documentation
    - Continue to next task
 
    **If `type="checkpoint:*"`:**
@@ -814,53 +815,155 @@ 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
-</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
+
+After each task completes (verification passed, done criteria met), commit immediately:
+
+**1. Identify modified files:**
+
+Track files changed during this specific task (not the entire plan):
+
+```bash
+git status --short
+```
+
+**2. Stage only task-related files:**
+
+Stage each file individually (NEVER use `git add .` or `git add -A`):
+
+```bash
+# Example - adjust to actual files modified by this task
+git add src/api/auth.ts
+git add src/types/user.ts
+```
+
+**3. Determine commit type:**
+
+| Type | When to Use | Example |
+|------|-------------|---------|
+| `feat` | New feature, endpoint, component, functionality | feat(08-02): create user registration endpoint |
+| `fix` | Bug fix, error correction | fix(08-02): correct email validation regex |
+| `test` | Test-only changes (TDD RED phase) | test(08-02): add failing test for password hashing |
+| `refactor` | Code cleanup, no behavior change (TDD REFACTOR phase) | refactor(08-02): extract validation to helper |
+| `perf` | Performance improvement | perf(08-02): add database index for user lookups |
+| `docs` | Documentation changes | docs(08-02): add API endpoint documentation |
+| `style` | Formatting, linting fixes | style(08-02): format auth module |
+| `chore` | Config, tooling, dependencies | chore(08-02): add bcrypt dependency |
+
+**4. Craft commit message:**
+
+Format: `{type}({phase}-{plan}): {task-name-or-description}`
+
+```bash
+git commit -m "{type}({phase}-{plan}): {concise task description}
+
+- {key change 1}
+- {key change 2}
+- {key change 3}
+"
+```
+
+**Examples:**
+
+```bash
+# Standard plan task
+git commit -m "feat(08-02): create user registration endpoint
+
+- POST /auth/register validates email and password
+- Checks for duplicate users
+- Returns JWT token on success
+"
+
+# Another standard task
+git commit -m "fix(08-02): correct email validation regex
+
+- 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:
+
+```bash
+TASK_COMMIT=$(git rev-parse --short HEAD)
+echo "Task ${TASK_NUM} committed: ${TASK_COMMIT}"
+```
+
+Store in array or list for SUMMARY generation:
+```bash
+TASK_COMMITS+=("Task ${TASK_NUM}: ${TASK_COMMIT}")
+```
+
+**Atomic commit benefits:**
+- Each task independently revertable
+- Git bisect finds exact failing task
+- Git blame traces line to specific task context
+- Clear history for Claude in future sessions
+- Better observability for AI-automated workflow
+
+</task_commit>
 
 <step name="checkpoint_protocol">
 When encountering `type="checkpoint:*"`:
@@ -1181,16 +1284,11 @@ ROADMAP_FILE=".planning/ROADMAP.md"
 - Add completion date
   </step>
 
-<step name="git_commit_plan">
-Commit plan completion (SUMMARY + PROJECT-STATE + ROADMAP + modified code files):
-
-**Critical: Stage only files this plan actually modified.**
-
-NEVER use:
+<step name="git_commit_metadata">
+Commit plan metadata (SUMMARY + STATE + ROADMAP):
 
-- `git add .`
-- `git add -A`
-- `git add src/` or any broad directory add
+**Note:** All task code has already been committed during execution (one commit per task).
+This final commit captures plan completion metadata only.
 
 **1. Stage planning artifacts:**
 
@@ -1203,45 +1301,73 @@ git add .planning/STATE.md
 **2. Stage roadmap file:**
 
 ```bash
-if [ -f .planning/ROADMAP.md ]; then
-  git add .planning/ROADMAP.md
-else
-  git add .planning/ROADMAP.md
-fi
+git add .planning/ROADMAP.md
 ```
 
-**3. Stage only code files from the modified-files list**
-
-**4. Verify staging before commit:**
+**3. Verify staging:**
 
 ```bash
 git status
-# Confirm only expected files are staged
+# Should show only planning artifacts, no code files
 ```
 
-**5. Commit:**
+**4. Commit metadata:**
 
 ```bash
 git commit -m "$(cat <<'EOF'
-feat({phase}-{plan}): [one-liner from SUMMARY.md]
+docs({phase}-{plan}): complete [plan-name] plan
+
+Tasks completed: [N]/[N]
+- [Task 1 name]
+- [Task 2 name]
+- [Task 3 name]
 
-- [Key accomplishment 1]
-- [Key accomplishment 2]
-- [Key accomplishment 3]
+SUMMARY: .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md
 EOF
 )"
 ```
 
-For commit message conventions and git workflow patterns, see ~/.claude/get-shit-done/references/git-integration.md
+**Example:**
+
+```bash
+git commit -m "$(cat <<'EOF'
+docs(08-02): complete user registration plan
+
+Tasks completed: 3/3
+- User registration endpoint
+- Password hashing with bcrypt
+- Email confirmation flow
+
+SUMMARY: .planning/phases/08-user-auth/08-02-registration-SUMMARY.md
+EOF
+)"
+```
+
+**Git log after plan execution:**
+
+```
+abc123f docs(08-02): complete user registration plan
+def456g feat(08-02): add email confirmation flow
+hij789k feat(08-02): implement password hashing with bcrypt
+lmn012o feat(08-02): create user registration endpoint
+```
+
+Each task has its own commit, followed by one metadata commit documenting plan completion.
+
+For commit message conventions, see ~/.claude/get-shit-done/references/git-integration.md
 </step>
 
 <step name="update_codebase_map">
 **If .planning/codebase/ exists:**
 
-Check what changed in this plan:
+Check what changed across all task commits in this plan:
 
 ```bash
-git diff --name-only HEAD~1 2>/dev/null
+# Find first task commit (right after previous plan's docs commit)
+FIRST_TASK=$(git log --oneline --grep="feat({phase}-{plan}):" --grep="fix({phase}-{plan}):" --grep="test({phase}-{plan}):" --reverse | head -1 | cut -d' ' -f1)
+
+# Get all changes from first task through now
+git diff --name-only ${FIRST_TASK}^..HEAD 2>/dev/null
 ```
 
 **Update only if structural changes occurred:**
@@ -1265,7 +1391,7 @@ Make single targeted edits - add a bullet point, update a path, or remove a stal
 
 ```bash
 git add .planning/codebase/*.md
-git commit --amend --no-edit  # Include in plan commit
+git commit --amend --no-edit  # Include in metadata commit
 ```
 
 **If .planning/codebase/ doesn't exist:**

package/get-shit-done/workflows/plan-phase.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
+
+**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.
 
-**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
+**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 complete TDD guidance.
+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>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "get-shit-done-cc",
-  "version": "1.3.19",
+  "version": "1.3.21",
   "description": "A meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.",
   "bin": {
     "get-shit-done-cc": "bin/install.js"