How do I install the Tdd Cycle skill?

Run npx skillmds@latest add anton-abyzov/tdd-cycle 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.

What does the Tdd Cycle skill do?

Execute full TDD red-green-refactor cycle with validation gates. Use when saying "TDD cycle", "test-driven development", or "full TDD workflow". It is listed under Productivity on SkillMD.

Is Tdd Cycle safe to use?

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

Which AI agents work with Tdd Cycle?

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 Cycle free to use?

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

Who published Tdd Cycle?

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

Tdd Cycle by anton-abyzov — Agent Skill

Name: Tdd Cycle
Author: anton-abyzov

TDD Cycle - Comprehensive Test-Driven Development

Phases

Run the full RED → GREEN → REFACTOR cycle, or one phase at a time with --phase red|green|refactor (--phase all is the default).

Examples

# Full cycle (default)
tdd-cycle "user authentication"

# Single phases
tdd-cycle --phase red "user authentication"
tdd-cycle --phase green "user authentication"
tdd-cycle --phase refactor "user authentication"

# Same as default — explicit
tdd-cycle --phase all "user authentication"

Execute a comprehensive Test-Driven Development (TDD) workflow with strict red-green-refactor discipline:

[Extended thinking: This workflow enforces test-first development through coordinated agent orchestration. Each phase of the TDD cycle is strictly enforced with fail-first verification, incremental implementation, and continuous refactoring. The workflow supports both single test and test suite approaches with configurable coverage thresholds.]

Configuration

Coverage Thresholds

Minimum line coverage: 80%
Minimum branch coverage: 75%
Critical path coverage: 100%

Refactoring Triggers

Cyclomatic complexity > 10
Method length > 20 lines
Class length > 200 lines
Duplicate code blocks > 3 lines

Phase 1: Test Specification and Design

1. Requirements Analysis

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Analyze requirements for: $ARGUMENTS. Define acceptance criteria, identify edge cases, and create test scenarios. Output a comprehensive test specification."
Output: Test specification, acceptance criteria, edge case matrix
Validation: Ensure all requirements have corresponding test scenarios

2. Test Architecture Design

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Design test architecture for: $ARGUMENTS based on test specification. Define test structure, fixtures, mocks, and test data strategy. Ensure testability and maintainability."
Output: Test architecture, fixture design, mock strategy
Validation: Architecture supports isolated, fast, reliable tests

Phase 2: RED - Write Failing Tests

3. Write Unit Tests (Failing)

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Write FAILING unit tests for: $ARGUMENTS. Tests must fail initially. Include edge cases, error scenarios, and happy paths. DO NOT implement production code."
Output: Failing unit tests, test documentation
CRITICAL: Verify all tests fail with expected error messages

4. Verify Test Failure

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Verify that all tests for: $ARGUMENTS are failing correctly. Ensure failures are for the right reasons (missing implementation, not test errors). Confirm no false positives."
Output: Test failure verification report
GATE: Do not proceed until all tests fail appropriately

Phase 3: GREEN - Make Tests Pass

5. Minimal Implementation

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Implement MINIMAL code to make tests pass for: $ARGUMENTS. Focus only on making tests green. Do not add extra features or optimizations. Keep it simple."
Output: Minimal working implementation
Constraint: No code beyond what's needed to pass tests

6. Verify Test Success

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Run all tests for: $ARGUMENTS and verify they pass. Check test coverage metrics. Ensure no tests were accidentally broken."
Output: Test execution report, coverage metrics
GATE: All tests must pass before proceeding

Phase 4: REFACTOR - Improve Code Quality

7. Code Refactoring

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Refactor implementation for: $ARGUMENTS while keeping tests green. Apply SOLID principles, remove duplication, improve naming, and optimize performance. Run tests after each refactoring."
Output: Refactored code, refactoring report
Constraint: Tests must remain green throughout

8. Test Refactoring

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Refactor tests for: $ARGUMENTS. Remove test duplication, improve test names, extract common fixtures, and enhance test readability. Ensure tests still provide same coverage."
Output: Refactored tests, improved test structure
Validation: Coverage metrics unchanged or improved

Phase 5: Integration and System Tests

9. Write Integration Tests (Failing First)

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Write FAILING integration tests for: $ARGUMENTS. Test component interactions, API contracts, and data flow. Tests must fail initially."
Output: Failing integration tests
Validation: Tests fail due to missing integration logic

10. Implement Integration

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Implement integration code for: $ARGUMENTS to make integration tests pass. Focus on component interaction and data flow."
Output: Integration implementation
Validation: All integration tests pass

Phase 6: Continuous Improvement Cycle

11. Performance and Edge Case Tests

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Add performance tests and additional edge case tests for: $ARGUMENTS. Include stress tests, boundary tests, and error recovery tests."
Output: Extended test suite
Metric: Increased test coverage and scenario coverage

12. Final Code Review

Run this step in a fresh context (a subagent, or a new session) so earlier reasoning cannot leak into it.
Prompt: "Perform comprehensive review of: $ARGUMENTS. Verify TDD process was followed, check code quality, test quality, and coverage. Suggest improvements."
Output: Review report, improvement suggestions
Action: Implement critical suggestions while maintaining green tests

Incremental Development Mode

For test-by-test development:

Write ONE failing test
Make ONLY that test pass
Refactor if needed
Repeat for next test

Use this approach by adding --incremental flag to focus on one test at a time.

Test Suite Mode

For comprehensive test suite development:

Write ALL tests for a feature/module (failing)
Implement code to pass ALL tests
Refactor entire module
Add integration tests

Use this approach by adding --suite flag for batch test development.

Validation Checkpoints

RED Phase Validation

All tests written before implementation
All tests fail with meaningful error messages
Test failures are due to missing implementation
No test passes accidentally

GREEN Phase Validation

All tests pass
No extra code beyond test requirements
Coverage meets minimum thresholds
No test was modified to make it pass

REFACTOR Phase Validation

All tests still pass after refactoring
Code complexity reduced
Duplication eliminated
Performance improved or maintained
Test readability improved

Coverage Reports

Generate coverage reports after each phase:

Line coverage
Branch coverage
Function coverage
Statement coverage

Failure Recovery

If TDD discipline is broken:

STOP immediately
Identify which phase was violated
Rollback to last valid state
Resume from correct phase
Document lesson learned

TDD Metrics Tracking

Track and report:

Time in each phase (Red/Green/Refactor)
Number of test-implementation cycles
Coverage progression
Refactoring frequency
Defect escape rate

Anti-Patterns to Avoid

Writing implementation before tests
Writing tests that already pass
Skipping the refactor phase
Writing multiple features without tests
Modifying tests to make them pass
Ignoring failing tests
Writing tests after implementation

Anti-Rationalization Table

These excuses signal you're about to break TDD discipline. Recognize them and return to the correct phase.

Excuse	Rebuttal	Why It Matters
"I'll test after"	Tests written after implementation pass immediately, proving nothing. You can't verify a test catches bugs if you never saw it fail.	Tests-after are biased by implementation — you test what you built, not what's required
"This is too simple to test"	Simple code has the most unexamined assumptions. Simple code breaks at integration boundaries where you least expect it.	The simpler it seems, the more likely you'll miss an edge case
"TDD slows me down"	TDD prevents 2-3 hour debugging sessions. Writing a test takes minutes; debugging an untested bug takes hours.	The time you "save" skipping tests is borrowed against future debugging
"Just this once"	Every "just this once" becomes the new standard. Discipline has no exceptions — the exception IS the precedent.	One skip normalizes skipping. There is no "just this once"
"I already manually tested it"	Manual testing leaves no record, isn't repeatable, and doesn't catch regressions. It proves nothing to anyone but you, right now.	Manual tests evaporate. Automated tests compound
"Deleting my code is wasteful"	Sunk cost fallacy — keeping bad code costs more than writing it correctly. Code written without tests is unverified code.	Bad code costs more to maintain than to rewrite correctly
"The spirit matters, not the ritual"	The ritual IS the spirit — the specific order (test → fail → implement → pass → refactor) is what produces the quality guarantee.	Skipping steps while claiming to follow TDD is not following TDD
"I'll keep deleted code as reference"	Reference code biases you toward the wrong implementation. Start fresh — the test tells you what to write.	Prior code anchors you to assumptions that may be wrong

Success Criteria

100% of code written test-first
All tests pass continuously
Coverage exceeds thresholds
Code complexity within limits
Zero defects in covered code
Clear test documentation
Fast test execution (< 5 seconds for unit tests)

Notes

Enforce strict RED-GREEN-REFACTOR discipline
Each phase must be completed before moving to next
Tests are the specification
If a test is hard to write, the design needs improvement
Refactoring is NOT optional
Keep test execution fast
Tests should be independent and isolated

TDD implementation for: $ARGUMENTS

Resources

Official Documentation

Tdd Cycle

File contents