get-shit-done-cc 1.0.2 → 1.0.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -73,6 +73,39 @@ Plans are guides, not straitjackets. During execution:
|
|
|
73
73
|
5. **Log enhancements** - Nice-to-haves, log to Issues, continue
|
|
74
74
|
</deviation_rules>
|
|
75
75
|
|
|
76
|
+
<test_driven_when_beneficial>
|
|
77
|
+
|
|
78
|
+
Use TDD when the work WOULD benefit from it. Not dogma—pragmatism.
|
|
79
|
+
|
|
80
|
+
**TDD candidates (write test first):**
|
|
81
|
+
- Business logic with defined inputs/outputs
|
|
82
|
+
- API endpoints and handlers
|
|
83
|
+
- Data transformations and parsing
|
|
84
|
+
- Validation rules
|
|
85
|
+
- State machines and workflows
|
|
86
|
+
- Anything where you can describe expected behavior before implementing
|
|
87
|
+
|
|
88
|
+
**Skip TDD for:**
|
|
89
|
+
- UI layout and styling
|
|
90
|
+
- Exploratory prototyping
|
|
91
|
+
- One-off scripts and migrations
|
|
92
|
+
- Configuration changes
|
|
93
|
+
- Glue code with no logic
|
|
94
|
+
|
|
95
|
+
**Decision heuristic:**
|
|
96
|
+
Can you write `expect(fn(input)).toBe(output)` before writing `fn`?
|
|
97
|
+
→ Yes: TDD will help
|
|
98
|
+
→ No: Write implementation first, add tests after if needed
|
|
99
|
+
|
|
100
|
+
**TDD task structure:**
|
|
101
|
+
When TDD applies, structure tasks as test-first:
|
|
102
|
+
1. Write failing test (red)
|
|
103
|
+
2. Implement to pass (green)
|
|
104
|
+
3. Refactor if needed
|
|
105
|
+
|
|
106
|
+
This is about design quality, not test coverage metrics.
|
|
107
|
+
</test_driven_when_beneficial>
|
|
108
|
+
|
|
76
109
|
<ship_fast>
|
|
77
110
|
|
|
78
111
|
No enterprise process. No approval gates.
|
|
@@ -422,6 +422,18 @@ Each task must have:
|
|
|
422
422
|
- **Verify**: How to prove it worked
|
|
423
423
|
- **Done**: Acceptance criteria
|
|
424
424
|
|
|
425
|
+
**Assess TDD fit for each task:**
|
|
426
|
+
|
|
427
|
+
TDD produces better design and catches bugs early. Use it when you can define expected behavior upfront.
|
|
428
|
+
|
|
429
|
+
For each task, ask: Can I write `expect(fn(input)).toBe(output)` before writing `fn`?
|
|
430
|
+
|
|
431
|
+
→ **Yes** (business logic, APIs, transformations, validation, state machines):
|
|
432
|
+
Structure test-first. Task action: "Implement X with TDD—write failing test, then implement to pass."
|
|
433
|
+
|
|
434
|
+
→ **No** (UI layout, config, glue code, exploration):
|
|
435
|
+
Standard implementation. Add tests after if coverage needed.
|
|
436
|
+
|
|
425
437
|
**Identify checkpoints:**
|
|
426
438
|
|
|
427
439
|
- Claude automated work needing visual/functional verification? → checkpoint:human-verify
|
package/package.json
CHANGED