Agent skill

tdd

Test-driven development — write a failing test before writing production code. Use when implementing new functionality, adding behavior, or fixing bugs during active development.

View SKILL.md on GitHub Repository
Stars 1,097
Forks 167

Install this agent skill to your Project

npx add-skill https://github.com/codeaholicguy/ai-devkit/tree/main/skills/tdd

SKILL.md

TDD

Red. Green. Refactor. In that order, every time.

Hard Rules

  • No production code without a failing test first.
  • If production code was written before its test, delete it and start over with a failing test.
  • Never skip the red step. A test that has never failed proves nothing.

Cycle

For each unit of behavior:

  1. Red — Write a test for the next behavior. Run it. It must fail. Read the failure message — it should describe the missing behavior.
  2. Green — Write the minimum production code to make the test pass. Nothing more. Run the test. Apply the verify skill.
  3. Refactor — Clean up both test and production code. Run the test again. Still green? Done. Apply the verify skill.

Then pick the next behavior and repeat.

Rules for Each Step

Red:

  • Test one behavior, not one function. Name the test after what the system should do, not what the function is called.
  • The test must fail for the right reason — a missing method, wrong return value, unmet condition. Not a syntax error or import failure.
  • If the test passes immediately, it's not testing new behavior. Delete it or pick a different behavior.

Green:

  • Write the simplest code that passes. Hardcode if needed — the next test will force generalization.
  • Do not add code "while you're in there." If it's not required by a failing test, it doesn't exist yet.
  • Do not refactor during green. Pass first, clean second.

Refactor:

  • Remove duplication between test and production code.
  • Extract only when you see real duplication, not predicted duplication.
  • Tests must still pass after every refactor move. Run them after each change.

Anti-Patterns

Pattern Problem Fix
Test-after Code shapes the test instead of the other way around Delete the code, write the test first
Testing internals Tests break on refactor, not on behavior change Test public behavior only
Giant red step Multiple behaviors in one test One assertion per behavior
Gold-plating green Adding code no test requires Remove untested code
Skipping refactor Tech debt accumulates immediately Refactor before the next red
Mock-heavy tests Tests pass but real code fails Prefer real dependencies, mock at boundaries only

Red Flags and Rationalizations

Rationalization Why It's Wrong Do Instead
"This is too simple to test first" Simple code still needs a spec Write the test — it'll be fast
"I'll add the test right after" You won't, and the code will shape the test Test first, always
"I need to see the design first" The test IS the design Let the test drive the interface
"Mocking is too hard for this" Difficulty mocking signals tight coupling Fix the design, then test
"The test would be identical to the implementation" Then you're testing internals Test the behavior from the outside

Memory Integration

After completing a TDD session, store reusable test patterns (setup, assertions, fixtures): npx ai-devkit@latest memory store --title "<pattern>" --content "<details>" --tags "tdd,testing"

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

codeaholicguy/ai-devkit

simplify-implementation

Analyze and simplify existing implementations to reduce complexity, improve maintainability, and enhance scalability. Use when users ask to simplify code, reduce complexity, refactor for readability, clean up implementations, improve maintainability, reduce technical debt, or make code easier to understand.

1,097 167
Explore
codeaholicguy/ai-devkit

dev-lifecycle

Structured SDLC workflow with 8 phases — requirements, design review, planning, implementation, testing, and code review. Use when the user wants to build a feature end-to-end, or run any individual phase (new requirement, review requirements, review design, execute plan, update planning, check implementation, write tests, code review).

1,097 167
Explore
codeaholicguy/ai-devkit

debug

Guide structured debugging before code changes by clarifying expected behavior, reproducing issues, identifying likely root causes, and agreeing on a fix plan with validation steps. Use when users ask to debug bugs, investigate regressions, triage incidents, diagnose failing behavior, handle failing tests, analyze production incidents, investigate error spikes, or run root cause analysis (RCA).

1,097 167
Explore
codeaholicguy/ai-devkit

memory

Use AI DevKit memory via CLI commands. Search before non-trivial work, store verified reusable knowledge, update stale entries, and avoid saving transcripts, secrets, or one-off task progress.

1,097 167
Explore
codeaholicguy/ai-devkit

technical-writer

Review and improve documentation for novice users. Use when users ask to review docs, improve documentation, audit README files, evaluate API docs, review guides, or improve technical writing.

1,097 167
Explore
codeaholicguy/ai-devkit

verify

Enforce evidence-based completion claims — require fresh command output before reporting success. Use when completing any task, fixing a bug, finishing a phase, running tests, building, deploying, or making any "it works" claim.

1,097 167
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results