Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# Test-Driven Development (TDD)
## 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.**
## When to Use
**Always:**
- New features
- Bug fixes
- Refactoring
- Behavior changes
**Exceptions (ask your human partner):**
- Throwaway prototypes
- Generated code
- Configuration files
Thinking "skip TDD just this once"? Stop. That's rationalization.
## 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
```dot
digraph tdd_cycle {
rankdir=LR;
red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
verify_red [label="Verify fails\ncorrectly", shape=diamond];
green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
…
The line at the top of this page pins the label git:20260204.611bfd1, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
GET https://markdownregistry.com/api/v1/artifacts/art_jipf6qrdktufs4fa
GET https://markdownregistry.com/api/v1/resolve?ref=ed3dai/ed3d-plugins/test-driven-development
GET https://markdownregistry.com/api/v1/blob/1ecc7e837989f9bab91f26918d74bc51162ab8ffc5edeb28d4eebcd1aec08c79
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
ed3dai/ed3d-plugins · plugins/ed3d-basic-agents/skills/doing-a-simple-two-stage-fanout/SKILL.md · Use when analyzing a large corpus of text, code, or data that exceeds a single agent's effective context - orchestrates…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/creating-a-plugin/SKILL.md · Use when creating a new Claude Code plugin or setting up plugin structure - provides complete file organization…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/creating-an-agent/SKILL.md · Use when creating specialized subagents for Claude Code plugins or the Task tool - covers description writing for…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/maintaining-a-marketplace/SKILL.md · Use when creating, releasing, or maintaining a Claude Code Plugin Marketplace - covers marketplace.json schema, version…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/maintaining-project-context/SKILL.md · Use when completing development phases or branches to identify and update CLAUDE.md or AGENTS.md files that may have…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/prompt-security-hardening/SKILL.md · Use when writing skills, CLAUDE.md files, agent prompts, or any directives that involve shell commands, environment…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/testing-skills-with-subagents/SKILL.md · Use when creating or editing skills, before deployment, to verify they work under pressure and resist rationalization -…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/writing-claude-directives/SKILL.md · Use when writing instructions that guide Claude behavior - skills, CLAUDE.md files, agent prompts, system prompts…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/writing-claude-md-files/SKILL.md · Use when creating or updating CLAUDE.md files for projects or subdirectories - covers top-level vs domain-level…
ed3dai/ed3d-plugins · plugins/ed3d-extending-claude/skills/writing-skills/SKILL.md · Use when creating new skills, editing existing skills, or verifying skills work before deployment - applies TDD to…
addyosmani/agent-skills · skills/test-driven-development/SKILL.md · Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or…
mvschwarz/openrig · skills/_canonical/process/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code
mvschwarz/openrig · packages/daemon/specs/agents/shared/skills/process/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code
cbrock84/headcount · plugins/technology/skills/test-driven-development/SKILL.md · Drives implementation by writing a failing test first, then the smallest code that passes it. Use this before writing…
a5c-ai/babysitter · library/methodologies/superpowers/skills/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.
a5c-ai/babysitter · library/methodologies/rpikit/skills/test-driven-development/SKILL.md · Test-first development practice where test specifications are written before production code, integrated into plan…