Agent skill
tdd-cycle
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.
Install this agent skill to your Project
npx add-skill https://github.com/anortham/sherpa/tree/main/skills/tdd-cycle
SKILL.md
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
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
bug-hunt
Systematically debug issues using Sherpa's Bug Hunt workflow. Activates when fixing bugs, investigating errors, debugging broken functionality, or handling regressions. Prevents symptom-fixing by enforcing reproduction-first approach.
systematic-development
Use Sherpa's systematic development workflow for general coding tasks. Activates when starting development work, adding features, or implementing functionality. Ensures guide check before coding and guide done after completion for progress tracking and celebrations.
logic-flow
Explain a function's logic step-by-step by analyzing its implementation and call graph. Use when the user asks "how does this work", "walk me through this", or wants to understand control flow and decision points.
metrics
Show Julie operational metrics -- session stats, tool usage, context efficiency, and historical trends. Use when the user asks about Julie's performance, how it's doing, how much context was saved, or wants a metrics/stats report.
architecture
Generate an architecture overview β key entry points, module map, dependency flow, and suggested reading order. Use when the user is new to a codebase, asks "how does this work?", wants an architecture overview, or needs onboarding documentation.
dependency-graph
Show module dependencies by analyzing imports, exports, and cross-references. Use when the user asks what a file imports, what depends on a module, or wants to see dependency structure.
Didn't find tool you were looking for?