How do I install the Test Driven Development skill?

Run npx skillmds@latest add aeondave/test-driven-development 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 Test Driven Development 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 Test Driven Development?

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 Test Driven Development free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Test Driven Development?

AeonDave (@aeondave) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Test Driven Development by aeondave

Name: Test Driven Development
Author: AeonDave

Test Driven Development

Use when implementing persistent code, bug fixes, refactors, scripts, exploit tooling, harnesses, or skill utilities before writing implementation code. Applies when tests, reproducers, assertions, or verification can be written first; treat disposable spikes separately and convert them to tested code before claiming reliability.

AeonDave 63d50b5 2 files · 3.8 KB Updated Sep 17, 2026

File contents

Test-Driven Development

Write the proof first. If the proof never failed, it may not prove anything.

Activation

Use this for code that is meant to remain: features, bug fixes, refactors, test harnesses, scripts, offensive tooling, parsers, and skill utilities.

Disposable exploration is allowed only as a spike. Do not ship, commit, or claim reliability from spike code until behavior is captured by a test, reproducer, or explicit verification gate.

RED-GREEN-REFACTOR

RED: write one minimal test or reproducer for desired behavior or the bug.
Verify RED: run it and confirm it fails for the expected reason.
GREEN: implement the smallest code that makes it pass.
Verify GREEN: run the focused check and relevant broader checks.
REFACTOR: clean structure while checks stay green.
Repeat: one behavior at a time.

Good tests

Test behavior, primitive, or contract rather than mock call trivia.
Use clear names that describe expected behavior.
Keep setup small enough that failure attribution is obvious.
Cover error paths, trust boundaries, and edge inputs when they define the contract.

Bug fixes

Before changing production code, create the smallest reproducer for the failure. For exploit or fuzzing work, preserve the crash input, seed, transcript, or packet sample and prove the fix against it.

Stop signals

Test passes before implementation: the test is wrong or behavior already exists.
Test errors for setup reasons: fix the test until it fails for the intended reason.
Test requires massive setup: the design may be too coupled; simplify the seam.
You wrote code first: restart from a failing test or mark the earlier code as disposable spike material.

Resources

Load on demand:

references/tdd-rationalizations.md — common shortcuts, legitimate exceptions, and offensive-development adaptations.

---name: test-driven-developmentdescription: Use when implementing persistent code, bug fixes, refactors, scripts, exploit tooling, harnesses, or skill utilities before writing implementation code. Applies when tests, reproducers, assertions, or verification can be written first; treat disposable spikes separately and convert them to tested code before claiming reliability.license: MIT---# Test-Driven DevelopmentWrite the proof first. If the proof never failed, it may not prove anything.## ActivationUse this for code that is meant to remain: features, bug fixes, refactors, test harnesses, scripts, offensive tooling, parsers, and skill utilities.Disposable exploration is allowed only as a spike. Do not ship, commit, or claim reliability from spike code until behavior is captured by a test, reproducer, or explicit verification gate.## RED-GREEN-REFACTOR1. **RED**: write one minimal test or reproducer for desired behavior or the bug.2. **Verify RED**: run it and confirm it fails for the expected reason.3. **GREEN**: implement the smallest code that makes it pass.4. **Verify GREEN**: run the focused check and relevant broader checks.5. **REFACTOR**: clean structure while checks stay green.6. **Repeat**: one behavior at a time.## Good tests- Test behavior, primitive, or contract rather than mock call trivia.- Use clear names that describe expected behavior.- Keep setup small enough that failure attribution is obvious.- Cover error paths, trust boundaries, and edge inputs when they define the contract.## Bug fixesBefore changing production code, create the smallest reproducer for the failure. For exploit or fuzzing work, preserve the crash input, seed, transcript, or packet sample and prove the fix against it.## Stop signals- Test passes before implementation: the test is wrong or behavior already exists.- Test errors for setup reasons: fix the test until it fails for the intended reason.- Test requires massive setup: the design may be too coupled; simplify the seam.- You wrote code first: restart from a failing test or mark the earlier code as disposable spike material.## ResourcesLoad on demand:- `references/tdd-rationalizations.md` — common shortcuts, legitimate exceptions, and offensive-development adaptations.

Frequently asked questions