tdd
Test-driven development workflow with philosophy guide - plan → write tests → implement → validate
By parcadei · 466 installs
npx skills add parcadei/continuous-claude-v3 --skill tdd
Source repository · Upstream listing
/tdd Test Driven Development Workflow
Strict TDD workflow: tests first, then implementation.
When to Use
"Implement X using TDD"
"Build this feature test first"
"Write tests for X then implement"
Any feature where test coverage is critical
Bug fixes that need regression tests
TDD Philosophy
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
The Iron Law
Write code before the test? Delete it. Start over.
No exceptions:
Don't keep it as "reference"
Don't "adapt" it while writing tests
Don't look at it
Delete means delete
Implement fresh from tests. Period.
Red Green Refactor
RED Write Failing Test
Write one minimal test showing what should happen.
Good:
Clear name, tests real behavior, one thing.
Bad:
Vague name, tests mock not code.
Requirements:
One behavior
Clear name
Real code (no mocks unless unavoidable)
Verify RED Watch It Fail
MANDATORY. Never skip.
Confirm:
Test fails (not errors)
Failure message is expected
Fails because feature missing (not typos)
Test passes? You're testing existing behavior. Fix test.
Test errors? Fix error, re run until it fails correctly.
GREEN Minimal Code
Write simplest code to pass the test.
Good:
Just enough to pass.
Bad:
Don't add features, refactor other code, or "improve" beyond the test.
Verify GREEN Watch It Pass
MANDATORY.
Confirm:
Test passes
Other tests still pass
Output pristine (no errors, warnings)
Test fails? Fix code, not test.
Other tests fail? Fix now.
REFACTOR Clean Up
After green only:
Remove duplication
Improve names
Extract helpers
Keep tests green. Don't add behavior.
Common Rationalizations
Excuse Reality
"Too simple to test" Simple code breaks. Test takes 30 seconds.
"I'll test after" Tests passing immediately prove nothing.
"Tests after achieve same goals" Tests after = "what does this do?" Tests first = "what should this do?"
"Already manually tested" Ad hoc ≠ systematic. No record, can't re run.
"Deleting X hours is wasteful" Sunk cost fallacy. Keeping unverified code is technical debt.
"Keep as reference, write tests first" You'll adapt it. That's testing after. Delete means delete.
"Need to explore first" Fine. Throw away exploration, start with TDD.
"Test hard = design unclear" Listen to test. Hard to test = hard to use.
"TDD will slow me down" TDD faster than debugging. Pragmatic = test first.
"Manual test faster" Manual doesn't prove edge cases. You'll re test every change.
Red Flags STOP and Start Over
Code before test
Test after implementation
Test passes immediately
Can't explain why test failed
Tests added "later"
Rationalizing "just this once"
"I already manually tested it"
"Tests after achieve the same purpose"
"Keep as reference" or "adapt existing code"
All of these mean: Delete code. Start over with TDD.
Verification Checklist
Before marking work complete:
[ ] Every new function/method has a test
[ ] Watched each test fail before implementing
[ ] Each test failed for expected reason (feature missing, not typo)
[ ] Wrote minimal code to pass each test
[ ] All tests pass
[ ] Output pristine (no errors, warnings)
[ ] Tests use real code (mocks only if unavoidable)
[ ] Edge cases and errors covered
Can't check all boxes? You skipped TDD. Start over.
When Stuck
Problem Solution
Don't know how to test Write wished for API. Write assertion first. Ask your human partner.
Test too complicated Design too complicated. Simplify interface.
Must mock everything Code too coupled. Use dependency injection.
Test setup huge Extract helpers. Still complex? Simplify design.
Workflow Execution
Workflow Overview
Agent Sequence
Agent Role Output
1 plan agent Design test cases and implementation approach Test plan
2 arbiter Write failing tests (RED phase) Test files
3 kraken Implement minimal code to pass (GREEN phase) Implementation
4 arbiter Run all tests, verify nothing broken Test report
Core Principle
Each agent follows the TDD contract:
arbiter writes tests that MUST fail initially
kraken writes MINIMAL code to make tests pass
arbiter confirms the full suite passes
Execution
Phase 1: Plan Test Cases
Phase 2: Write Failing Tests (RED)
Phase 3: Implement (GREEN)
Phase 4: Validate
TDD Rules Enforced
1. arbiter cannot write implementation code
2. kraken cannot add untested features
3. Tests must fail before implementation
4. Tests must pass after implementation
Example
Refactor Phase (Optional)
After GREEN, you can add a refactor phase: