Test-driven development workflow with philosophy guide - plan → write tests → implement → validate

MITAuto-check passedTesting & QA

Install TDD

skills CLI
$ npx skills add parcadei/Continuous-Claude-v3 --skill tdd -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install parcadei/Continuous-Claude-v3 tdd --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/parcadei/Continuous-Claude-v3.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/tdd .claude/skills/tdd && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
tdd
GitHub stars
3.9k
Used in
1 other repo
Token cost
~2.3k tokens
SKILL.md length
700 words
Files
1
Skills in repo
141
Repo updated
First seen
Licence
MIT

At a glance

Test-driven development workflow with philosophy guide - plan → write tests → implement → validate

  • Works in 4 steps: Plan Test Cases → Write Failing Tests (RED) → Implement (GREEN) → …
  • Tasks that involve Test-driven development
  • SKILL.md covers When to Use, Overview, The Iron Law and Red-Green-Refactor, plus 11 more sections
  • Calls npm and pytest

What it does

TDD is an agent skill from parcadei/Continuous-Claude-v3. Test-driven development workflow with philosophy guide - plan → write tests → implement → validate

Its SKILL.md is about 2.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Test-driven development and Test generation. The repository describes itself as: Context management for Claude Code. Hooks maintain state via ledgers and handoffs. MCP execution without context pollution. Agent orchestration with isolated context windows. The licence is MIT.

When your agent uses it

  • Tasks that involve Test-driven development
  • Tasks that involve Test generation

Example prompts

  • “/tdd”

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Plan Test Cases
  2. Write Failing Tests (RED)
  3. Implement (GREEN)
  4. Validate

What it can do on your machine

Read from SKILL.md and the folder at commit d07ff4b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npm
    • pytest

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

TDD loads about 2.3k tokens when it runs. Until then it costs about 26 tokens; SKILL.md has 700 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~26
When it runs · the whole SKILL.md, loaded when a task matches
~2.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from parcadei/Continuous-Claude-v3 at commit d07ff4b, republished under its MIT licence (© parcadei). 700 words, ~2,287 tokens.

Download SKILL.mdSave it as .claude/skills/tdd/SKILL.md (or your agent's skills folder).
name
tdd
description
Test-driven development workflow with philosophy guide - plan → write tests → implement → validate
keywords
tdd, test-driven, test-first, red-green-refactor

/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

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

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:

typescript
test('retries failed operations 3 times', async () => {
  let attempts = 0;
  const operation = () => {
    attempts++;
    if (attempts < 3) throw new Error('fail');
    return 'success';
  };

  const result = await retryOperation(operation);

  expect(result).toBe('success');
  expect(attempts).toBe(3);
});

Clear name, tests real behavior, one thing.

Bad:

typescript
test('retry works', async () => {
  const mock = jest.fn()
    .mockRejectedValueOnce(new Error())
    .mockResolvedValueOnce('success');
  await retryOperation(mock);
  expect(mock).toHaveBeenCalledTimes(3);
});

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.

bash
npm test path/to/test.test.ts
# or
pytest path/to/test_file.py

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:

typescript
async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
  for (let i = 0; i < 3; i++) {
    try {
      return await fn();
    } catch (e) {
      if (i === 2) throw e;
    }
  }
  throw new Error('unreachable');
}

Just enough to pass.

Bad:

typescript
async function retryOperation<T>(
  fn: () => Promise<T>,
  options?: {
    maxRetries?: number;
    backoff?: 'linear' | 'exponential';
    onRetry?: (attempt: number) => void;
  }
): Promise<T> {
  // YAGNI - over-engineered
}

Don't add features, refactor other code, or "improve" beyond the test.

Verify GREEN - Watch It Pass

MANDATORY.

bash
npm test path/to/test.test.ts

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

ExcuseReality
"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.
Show full SKILL.md (300 more words)Show less

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

ProblemSolution
Don't know how to testWrite wished-for API. Write assertion first. Ask your human partner.
Test too complicatedDesign too complicated. Simplify interface.
Must mock everythingCode too coupled. Use dependency injection.
Test setup hugeExtract helpers. Still complex? Simplify design.

Workflow Execution

Workflow Overview

┌────────────┐    ┌──────────┐    ┌──────────┐    ┌───────────┐
│   plan-    │───▶│ arbiter  │───▶│  kraken  │───▶│ arbiter  │
│   agent    │    │          │    │          │    │           │
└────────────┘    └──────────┘    └──────────┘    └───────────┘
   Design          Write           Implement        Verify
   approach        failing         minimal          all tests
                   tests           code             pass

Agent Sequence

#AgentRoleOutput
1plan-agentDesign test cases and implementation approachTest plan
2arbiterWrite failing tests (RED phase)Test files
3krakenImplement minimal code to pass (GREEN phase)Implementation
4arbiterRun all tests, verify nothing brokenTest report

Core Principle

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

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
Task(
  subagent_type="plan-agent",
  prompt="""
  Design TDD approach for: [FEATURE_NAME]

  Define:
  1. What behaviors need to be tested
  2. Edge cases to cover
  3. Expected test structure

  DO NOT write any implementation code.
  Output: Test plan document
  """
)
Phase 2: Write Failing Tests (RED)
Task(
  subagent_type="arbiter",
  prompt="""
  Write failing tests for: [FEATURE_NAME]

  Test plan: [from phase 1]

  Requirements:
  - Write tests FIRST
  - Run tests to confirm they FAIL
  - Tests must fail because feature is missing (not syntax errors)
  - Create clear test names describing expected behavior

  DO NOT write any implementation code.
  """
)
Phase 3: Implement (GREEN)
Task(
  subagent_type="kraken",
  prompt="""
  Implement MINIMAL code to pass tests: [FEATURE_NAME]

  Tests location: [test file path]

  Requirements:
  - Write ONLY enough code to make tests pass
  - No additional features beyond what tests require
  - No "improvements" or "enhancements"
  - Run tests after each change

  Follow Red-Green-Refactor strictly.
  """
)
Phase 4: Validate
Task(
  subagent_type="arbiter",
  prompt="""
  Validate TDD implementation: [FEATURE_NAME]

  - Run full test suite
  - Verify all new tests pass
  - Verify no existing tests broke
  - Check test coverage if available
  """
)

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

User: /tdd Add email validation to the signup form

Claude: Starting /tdd workflow for email validation...

Phase 1: Planning test cases...
[Spawns plan-agent]
Test plan:
- Valid email formats
- Invalid email formats
- Empty email rejection
- Edge cases (unicode, long emails)

Phase 2: Writing failing tests (RED)...
[Spawns arbiter]
✅ 8 tests written, all failing as expected

Phase 3: Implementing minimal code (GREEN)...
[Spawns kraken]
✅ All 8 tests now passing

Phase 4: Validating...
[Spawns arbiter]
✅ 247 tests passing (8 new), 0 failing

TDD workflow complete!

Refactor Phase (Optional)

After GREEN, you can add a refactor phase:

Task(
  subagent_type="kraken",
  prompt="""
  Refactor: [FEATURE_NAME]

  - Clean up code while keeping tests green
  - Remove duplication
  - Improve naming
  - Extract helpers if needed

  DO NOT add new behavior. Keep all tests passing.
  """
)

© parcadei, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/tdd of parcadei/Continuous-Claude-v3.

Open the folder on GitHubat commit d07ff4b

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in parcadei/Continuous-Claude-v3, which our catalogue first saw on October 7, 2026.

Compare with similar skills

TDD next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

TDD compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
TDD this skillparcadei/Continuous-Claude-v33.9k1 repos~2.3kAutomated safety check: PassMIT
Designing TestsCloudAI-X/opencode-workflow275—~2.9kAutomated safety check: PassMIT
TDD Guidealirezarezvani/claude-code-skill-factory8801 repos~2.7kAutomated safety check: PassMIT
Automated Test Planningtestdouble/han279—~6.7kAutomated safety check: PassMIT
Workflow Test GenerationdavidYichengWei/agentic-engineering-framework158—~580Automated safety check: PassMIT
Manual Test Planningtestdouble/han279—~2.9kAutomated safety check: PassMIT

Similar skills

  • Designing Tests

    CloudAI-X/opencode-workflow

    Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices.

    275 GitHub stars~2.9k tokensUpdated 9 mo ago
    Testing & QAAuto-check passed
  • TDD Guide

    alirezarezvani/claude-code-skill-factory

    Comprehensive Test Driven Development guide for engineering subagents with multi-framework support, coverage analysis, and intelligent test generation

    880 GitHub starsUsed in 1 repo~2.7k tokens
    Testing & QAAuto-check passed
  • Produce a standalone test plan by analyzing code for test coverage gaps and edge cases.

    279 GitHub stars~6.7k tokensUpdated 7 days ago
    Testing & QAAuto-check passed
  • Workflow Test Generation

    davidYichengWei/agentic-engineering-framework

    测试生成。基于 spec.md 或被测代码,生成单元测试、集成测试、性能测试。当用户请求生成测试、TDD 模式、或 workflow-code-generation 完成后触发。

    158 GitHub stars~580 tokensUpdated 6 mo ago
    Testing & QAAuto-check passed
  • Manual Test Planning

    testdouble/han

    Produce a plain-language manual test plan from the context supplied to it — an executive summary, a high-level list of named tests, and a detail section per test with the steps a person follows by…

    279 GitHub stars~2.9k tokensUpdated 7 days ago
    Testing & QAAuto-check passed
  • Shift Left Testing

    proffesor-for-testing/agentic-qe

    Move testing activities earlier in the development lifecycle to catch defects when they're cheapest to fix.

    494 GitHub stars~1.2k tokensUpdated 4 days ago
    Testing & QAAuto-check passed

More from parcadei/Continuous-Claude-v3

All 141 skills in this repo
  • Tldr Deep

    parcadei/Continuous-Claude-v3

    Full 5-layer analysis of a specific function. An agent skill from parcadei/Continuous-Claude-v3.

    3.9k GitHub starsUsed in 2 repos~677 tokens
    Auto-check passed
  • Compound Learnings

    parcadei/Continuous-Claude-v3

    Transform session learnings into permanent capabilities (skills, rules, agents).

    3.9k GitHub starsUsed in 1 repo~1.6k tokens
    Auto-check: notes
  • Gradient Methods

    parcadei/Continuous-Claude-v3

    Problem-solving strategies for gradient methods in optimization

    3.9k GitHub starsUsed in 3 repos~1k tokens
    Auto-check: notes
  • Debug Hooks

    parcadei/Continuous-Claude-v3

    Systematic hook debugging workflow. An agent skill from parcadei/Continuous-Claude-v3.

    3.9k GitHub starsUsed in 1 repo~863 tokens
    Auto-check: notes
  • Math

    parcadei/Continuous-Claude-v3

    Unified math capabilities - computation, solving, and explanation.

    3.9k GitHub starsUsed in 3 repos~1.6k tokens
    Auto-check: notes
  • Math Model Selector

    parcadei/Continuous-Claude-v3

    Routes problems to appropriate mathematical frameworks using expert heuristics

    3.9k GitHub starsUsed in 3 repos~841 tokens
    Auto-check passed

Categories

Questions about TDD

What does TDD do?

Test-driven development workflow with philosophy guide - plan → write tests → implement → validate. TDD is an agent skill from parcadei/Continuous-Claude-v3.

When should I use TDD?

TDD fits situations like: tasks that involve Test-driven development; tasks that involve Test generation.

How do I install TDD in Claude Code?

Run `npx skills add parcadei/Continuous-Claude-v3 --skill tdd -a claude-code`. Or copy the skill folder (.claude/skills/tdd in parcadei/Continuous-Claude-v3) into .claude/skills/tdd in your project. Claude Code loads it when a task matches its description.

How do I install TDD in Codex?

Run `npx skills add parcadei/Continuous-Claude-v3 --skill tdd -a codex`. Or copy the skill folder (.claude/skills/tdd in parcadei/Continuous-Claude-v3) into .agents/skills/tdd in your project. Codex loads it when a task matches its description.

Can I use TDD in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add parcadei/Continuous-Claude-v3 --skill tdd -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/tdd, .gemini/skills/tdd, .github/skills/tdd and .opencode/skills/tdd in your project.

What does TDD need to run?

Going by SKILL.md and its folder, TDD needs the command-line tools its instructions call (npm and pytest).

Does TDD access the network?

SKILL.md contains no URLs. Its commands use npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is TDD safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does TDD use?

TDD is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does TDD use?

About 2.3k tokens (SKILL.md is roughly 9.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to TDD?

Skills that share tags, products or a category with TDD: Designing Tests (CloudAI-X/opencode-workflow, 275 stars), TDD Guide (alirezarezvani/claude-code-skill-factory, 880 stars), Automated Test Planning (testdouble/han, 279 stars) and Workflow Test Generation (davidYichengWei/agentic-engineering-framework, 158 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains TDD?

parcadei (a GitHub user) maintains it in parcadei/Continuous-Claude-v3, which has 3,940 GitHub stars. The repository holds 141 skills in this directory. The repository was last updated on January 26, 2026.

Source: parcadei/Continuous-Claude-v3 on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.