Claude Code Plugins

Community-maintained marketplace

Feedback
0
0

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 Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

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 check BEFORE every coding step
  • Write tests BEFORE implementation (no exceptions!)
  • Mark completion with guide done after 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 check called before each phase
  • βœ… guide done called after each completion
  • βœ… No untested code shipped
  • βœ… Refactoring done with confidence (tests stay green)

Why TDD Works

80% of bugs are prevented by:

  1. Tests written first - Forces you to think about behavior before code
  2. Systematic phases - Prevents skipping critical steps
  3. Enforcement - Sherpa tracks progress, catches shortcuts
  4. Rapid feedback - Tests tell you immediately when something breaks
  5. 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