Use when implementing any feature or bugfix, before writing implementation code - write the failing test first and watch it fail for the right reason.
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)
_Adapted from the MIT-licensed superpowers plugin by Jesse Vincent. See NOTICE.md._
## 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.
## The Cycle
One action per step. Do not merge steps or skip ahead.
1. **RED** — write one failing test for one behavior.
2. **Verify RED** — run it. Confirm it fails, and check *why* it fails.
3. **GREEN** — write the minimal code to pass that test.
4. **Verify GREEN** — run the full suite. Confirm it passes and nothing else broke.
5. **REFACTOR** — clean up duplication and naming while staying green.
6. **COMMIT** — commit the change, then start the next RED.
## Verify RED means checking the failure message, not just the exit code
A red exit code alone proves nothing. Read the failure message before moving on:
- **Correct reason:** the assertion fails because the behavior doesn't exist yet — e.g.
`AssertionError: expected undefined to equal 'success'`.
- **Wrong reason:** a typo in the import path, a missing file, a syntax error, a test that
…
The line at the top of this page pins the label git:20260805.6da0f10, 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_tzqo43qy7amowsf5
GET https://markdownregistry.com/api/v1/resolve?ref=andreymudri/fleetmates/test-driven-development
GET https://markdownregistry.com/api/v1/blob/1395f5b795354173e0efd7d786fb0eda0d7164db36ac6b6484452d6b8f388156
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.
andreymudri/fleetmates · skills/brainstorming/SKILL.md · Use when starting any creative work - creating features, building components, adding functionality, or modifying…
andreymudri/fleetmates · skills/executing-plans/SKILL.md · Use when you have a written implementation plan to execute inline in this session, with checkpoints - the non-fleet…
andreymudri/fleetmates · skills/finishing-a-development-branch/SKILL.md · Use when implementation is complete and needs integrating - re-runs the gate to verify each phase, then decides how the…
andreymudri/fleetmates · skills/fleet-lifecycle/SKILL.md · Use when spawning, listing, messaging, scaling, stopping, or resuming background teammates on a run.
andreymudri/fleetmates · skills/fleet-supervision/SKILL.md · Use when checking what a running fleet is doing - renders the digest, surfaces blocked or failed teammates, and…
andreymudri/fleetmates · skills/grilling/SKILL.md · Use when a plan, spec or design still has unresolved decisions, when the user says "grill me" or asks to be…
andreymudri/fleetmates · skills/parallel-execution/SKILL.md · Use when executing a written plan across background teammates - splits it into phases, dispatches worktree-isolated…
andreymudri/fleetmates · skills/phase-gate/SKILL.md · Use when a phase finished and needs an automated verdict before integration - runs command, agent, and MCP checks and…
andreymudri/fleetmates · skills/receiving-code-review/SKILL.md · Use when receiving code review feedback, before implementing suggestions - requires technical verification rather than…
andreymudri/fleetmates · skills/systematic-debugging/SKILL.md · Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - reproduce and isolate…
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…
