How do I install the Tdd Workflow skill?

Run npx skillmds@latest add dmitryprg-ai/tdd-workflow in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Tdd Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tdd Workflow?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tdd Workflow free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tdd Workflow?

dmitryprg-ai (@dmitryprg-ai) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tdd Workflow by dmitryprg-ai — Agent Skill

Name: Tdd Workflow
Rating: 4.2 (5 reviews)
Author: dmitryprg-ai

Tdd Workflow

Test-Driven Development with strict Red-Green-Refactor cycle. Use when developing with TDD, writing tests before code, adding test coverage, or when user mentions test-first, red-green-refactor, or wants reliable test suites.

dmitryprg-ai Updated Sep 10, 2026

File contents

TDD Workflow

Principle: Red -> Green -> Refactor (strict order)

Writing tests first catches design issues early — if the API is awkward to test, it's awkward to use. Tests also serve as living documentation that stays current because it breaks when behavior changes.

Phase 0: Test Planning (before any code)

Fill the test cases table first because it forces you to think about behavior before implementation. Without this step, tests end up only covering the happy path.

| # | Scenario | Input | Expected Output | Type |
|---|----------|-------|-----------------|------|
| 1 | Happy path | ... | ... | Unit |
| 2 | Edge: empty | [] | ... | Unit |
| 3 | Edge: null | null | Error | Unit |
| 4 | Integration | ... | ... | Integration |

Coverage categories:

Happy path (main scenario)
Edge cases (empty, null, boundaries)
Error cases (invalid input, exceptions)
Integration points (if dependencies exist)

Do NOT proceed until the table is filled — skipping this step leads to incomplete test coverage that gives false confidence.

Phase 1: RED — Write Failing Tests

Create test file (feature.test.ts)
Write tests for ALL cases from Phase 0
Run tests — they must fail

npm test -- --grep "feature"
# Expected: FAIL

Tests must fail first because a test that passes without implementation might be testing the wrong thing.

Phase 2: GREEN — Minimal Code

Write the minimum code to make tests pass
Resist the urge to optimize or add "for later" — that's Phase 3
Run tests — they must pass

npm test -- --grep "feature"
# Expected: PASS

Phase 3: REFACTOR

All tests green? Now refactor
After each change: run tests (must stay green)

Refactoring with a green test suite is safe. Refactoring without tests is gambling.

Phase 4: Verify

| Category | Written | Passing | Skipped |
|----------|---------|---------|---------|
| Happy path | X | X | 0 |
| Edge cases | X | X | 0 |
| Error cases | X | X | 0 |
| Integration | X | X | 0 |

What to avoid

Code before test table — leads to incomplete coverage
Code before failing tests — the test might be wrong
Refactoring while tests are red — you don't know if refactoring broke something or if it was already broken
"I'll write tests later" — later never comes, and by then you've forgotten the edge cases

---name: tdd-workflowdescription: Test-Driven Development with strict Red-Green-Refactor cycle. Use when developing with TDD, writing tests before code, adding test coverage, or when user mentions test-first, red-green-refactor, or wants reliable test suites.---# TDD WorkflowPrinciple: **Red -> Green -> Refactor** (strict order)Writing tests first catches design issues early — if the API is awkward to test, it's awkward to use. Tests also serve as living documentation that stays current because it breaks when behavior changes.## Phase 0: Test Planning (before any code)Fill the test cases table first because it forces you to think about behavior before implementation. Without this step, tests end up only covering the happy path.```markdown| # | Scenario | Input | Expected Output | Type ||---|----------|-------|-----------------|------|| 1 | Happy path | ... | ... | Unit || 2 | Edge: empty | [] | ... | Unit || 3 | Edge: null | null | Error | Unit || 4 | Integration | ... | ... | Integration |```Coverage categories:- Happy path (main scenario)- Edge cases (empty, null, boundaries)- Error cases (invalid input, exceptions)- Integration points (if dependencies exist)Do NOT proceed until the table is filled — skipping this step leads to incomplete test coverage that gives false confidence.## Phase 1: RED — Write Failing Tests1. Create test file (`feature.test.ts`)2. Write tests for ALL cases from Phase 03. Run tests — they must fail```bashnpm test -- --grep "feature"# Expected: FAIL```Tests must fail first because a test that passes without implementation might be testing the wrong thing.## Phase 2: GREEN — Minimal Code1. Write the minimum code to make tests pass2. Resist the urge to optimize or add "for later" — that's Phase 33. Run tests — they must pass```bashnpm test -- --grep "feature"# Expected: PASS```## Phase 3: REFACTOR1. All tests green? Now refactor2. After each change: run tests (must stay green)Refactoring with a green test suite is safe. Refactoring without tests is gambling.## Phase 4: Verify```markdown| Category | Written | Passing | Skipped ||----------|---------|---------|---------|| Happy path | X | X | 0 || Edge cases | X | X | 0 || Error cases | X | X | 0 || Integration | X | X | 0 |```## What to avoid- Code before test table — leads to incomplete coverage- Code before failing tests — the test might be wrong- Refactoring while tests are red — you don't know if refactoring broke something or if it was already broken- "I'll write tests later" — later never comes, and by then you've forgotten the edge cases

Frequently asked questions