| name | tdd-cycle |
| description | Follow strict TDD methodology using Sherpa's workflow enforcement. Activates when implementing new features, adding functionality, or building code that requires tests. Ensures RED-GREEN-REFACTOR discipline with guide check/done tracking. |
| allowed-tools | mcp__sherpa__guide, mcp__sherpa__approach, Write, Edit, Bash, Read |
TDD Cycle Skill
Purpose
Follow strict TDD discipline using Sherpa's workflow enforcement to prevent untested code and ensure systematic development.
When to Activate
- Implementing new features
- Adding new functionality
- User says "write tests first" or "use TDD"
- Building something from scratch
- Working on extractors, parsers, transformers, or any core logic
The Mandatory Pattern
β
CRITICAL: ALWAYS call guide check BEFORE coding
BEFORE ANY CODE:
guide check β Get current phase + specific guidance
Read guidance completely
Follow the suggested steps
AFTER EACH STEP:
guide done "what you completed"
β Get celebration + next step
β Phase auto-advances when complete
You are EXCELLENT at following this pattern. It's automatic, like breathing.
The TDD Workflow
Phase 1: π Define Contract (RED Phase Preparation)
Goal: Define what success looks like BEFORE any code exists
guide check β Phase: Define Contract
Steps:
1. Create interface/type file
2. Define function signatures with types
3. Document expected inputs/outputs
4. List error conditions explicitly
5. Document boundary conditions
guide done "defined contract for X with types and error cases"
Key Principle: Contracts prevent building the wrong thing.
Conditionals:
- If interface unclear β Search codebase for similar patterns FIRST (don't guess!)
- If external API/library β Read official docs to verify signatures
- If complex transformations β Write example inputβoutput pairs first
Anti-patterns:
- β Writing implementation code in this phase (STOP - wrong phase!)
- β Making assumptions about types (verify, don't assume)
- β Skipping edge case documentation (edge cases ARE the spec)
Phase 2: π§ͺ Implement Tests (RED Phase)
Goal: Write failing tests that specify behavior
guide check β Phase: Implement Tests
Steps:
1. Create test file following project conventions
2. Write test for happy path
3. Write test for EACH edge case
4. Write test for EACH error condition
5. Run tests β ALL must fail (RED)
6. Verify failure message is correct
guide done "wrote failing tests for X (happy path + 4 edge cases)"
Key Principle: Tests are your specification - make them thorough.
Minimum Coverage:
- 1 happy path test
- 3+ edge case tests (empty, null, boundary values)
- 2+ error case tests (invalid input, missing data)
Conditionals:
- If test passes before implementation β Test is broken, fix it!
- If can't think of edge cases β Use checklist: empty, null, undefined, wrong type, zero, negative, max value, boundary, concurrent
- If test fails for wrong reason β Fix test setup first
- If writing integration test β Mock dependencies, test ONE unit
Anti-patterns:
- β Writing only 1-2 tests (insufficient coverage)
- β Testing multiple behaviors in one test (split them)
- β Tests that depend on each other (must be independent)
- β Skipping error tests "for later" (write them NOW)
Phase 3: π» Minimal Implementation (GREEN Phase)
Goal: Write ONLY enough code to pass tests - nothing more
guide check β Phase: Minimal Implementation
Steps:
1. Start with simplest test
2. Write minimal code to pass it
3. Run test β Verify it passes
4. Repeat for each test
5. ALL tests must be GREEN
guide done "implemented X - all tests passing"
Key Principle: Make it WORK first, make it PRETTY later (refactor phase).
Conditionals:
- If test fails unexpectedly β Understand WHY (valuable feedback!)
- If want to add feature not in tests β STOP, go to Phase 2, add test first
- If implementation getting complex β That's OK - make tests pass, refactor later
- If copy-pasting code β Fine for now - extract in refactor phase
Anti-patterns:
- β Over-engineering (abstractions, design patterns, "future-proofing")
- β Implementing features not covered by tests (untested code = broken code)
- β Skipping test runs between changes (rapid feedback loop critical)
- β "Fixing" tests to match implementation (tests are spec, not implementation!)
Phase 4: π§ Refactor (Still GREEN)
Goal: Improve code quality while keeping tests green
guide check β Phase: Refactor
Steps:
1. Run all tests β Verify ALL green
2. Identify code smells (duplication, complexity, poor names)
3. Make ONE improvement
4. Run tests β Must stay green
5. Repeat until satisfied
guide done "refactored X for readability - tests still green"
Key Principle: Tests give you confidence to refactor safely.
Common Refactorings:
- Extract duplicated code into functions
- Rename variables/functions for clarity
- Simplify complex conditionals
- Extract abstractions from concrete code
- Improve error messages
Conditionals:
- If tests fail during refactor β Revert, smaller step
- If want to change behavior β That's NEW feature - go to Phase 1
- If unclear how to improve β Skip for now, move to next feature
Anti-patterns:
- β Changing behavior (new behavior = new feature = new tests first)
- β Skipping test runs during refactor (each change must keep tests green)
- β Massive refactor all at once (small steps, verify often)
The Complete TDD Cycle
βββββββββββββββββββββββββββββββββββββββββββββββ
β 1. guide check β Define Contract β
β - Write interface/types β
β - Document behavior β
β guide done "defined contract" β
ββββββββββββββ¬βββββββββββββββββββββββββββββββββ
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββ
β 2. guide check β Implement Tests (RED) β
β - Write failing tests β
β - Happy path + edges + errors β
β - Verify all FAIL β
β guide done "wrote failing tests" β
ββββββββββββββ¬βββββββββββββββββββββββββββββββββ
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββ
β 3. guide check β Minimal Impl (GREEN) β
β - Write code to pass tests β
β - Simplest solution β
β - ALL tests must pass β
β guide done "implemented feature" β
ββββββββββββββ¬βββββββββββββββββββββββββββββββββ
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββ
β 4. guide check β Refactor β
β - Improve code quality β
β - Keep tests green β
β - Small steps β
β guide done "refactored for clarity" β
ββββββββββββββ¬βββββββββββββββββββββββββββββββββ
β
βΌ
Next feature!
Example TDD Session
User: "Implement a parser for TypeScript function signatures"
Agent: guide check
Sherpa: Phase 1 - Define Contract
"Create interface/type files with function signatures..."
Agent: Creates parser.types.ts with types:
- FunctionSignature interface
- ParseResult type
- ParseError type
guide done "defined parser contract with types"
Sherpa: Phase 2 - Implement Tests
"Write failing tests for happy path + edge cases..."
Agent: Creates parser.test.ts:
- test('parses simple function signature')
- test('parses function with parameters')
- test('handles generic types')
- test('throws on invalid syntax')
- test('handles empty string')
Runs tests β ALL FAIL β
guide done "wrote 5 failing tests for parser"
Sherpa: Phase 3 - Minimal Implementation
"Write code to pass tests..."
Agent: Implements parser.ts
Runs tests after each function β ALL PASS β
guide done "implemented parser - all tests green"
Sherpa: Phase 4 - Refactor
"Improve code quality while keeping tests green..."
Agent: Extracts helper functions, improves names
Runs tests after each refactor β Still GREEN β
guide done "refactored parser for readability"
Sherpa: β
TDD cycle complete! Next feature?
Integration with Sherpa Commands
Switching to TDD Workflow
guide tdd
β Instantly switches to TDD workflow
β guide check to get first phase
During Development
guide check β Get current phase + specific guidance
guide done "X" β Mark completion, get celebration + next step
guide advance β Manual phase progression (rarely needed)
Workflow Selection
approach list β See all workflows
approach set tdd β Switch to TDD (same as guide tdd)
Key Behaviors
β DO
- Call
guide checkBEFORE every coding step - Write tests BEFORE implementation (no exceptions!)
- Mark completion with
guide doneafter each step - Run tests frequently (after each small change)
- Follow phase guidance systematically
- Trust the process - it prevents bugs
β DON'T
- Start coding without
guide check(this is the #1 mistake) - Skip test writing "because it's simple" (simple changes break too)
- Write implementation before tests exist (defeats TDD purpose)
- Rush through phases to "go faster" (you go slower fixing bugs)
- Ignore anti-patterns in phase guidance (they're bugs waiting to happen)
Success Criteria
This skill succeeds when:
- β Tests written before implementation (always)
- β All tests pass before moving forward
- β
guide checkcalled before each phase - β
guide donecalled after each completion - β No untested code shipped
- β Refactoring done with confidence (tests stay green)
Why TDD Works
80% of bugs are prevented by:
- Tests written first - Forces you to think about behavior before code
- Systematic phases - Prevents skipping critical steps
- Enforcement - Sherpa tracks progress, catches shortcuts
- Rapid feedback - Tests tell you immediately when something breaks
- Safe refactoring - Confidence to improve code without fear
Remember: TDD isn't slower - it's faster because you spend less time debugging and more time building correctly.
Sherpa + TDD = Systematic Excellence