Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
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 is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after.
When exploring the codebase, read `GLOSSARY.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
## What a good test is
Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification: "user can checkout with valid cart" tells you exactly what capability exists, and it survives refactors because it doesn't care about internal structure.
See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
## Seams: where tests go
A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
…
The line at the top of this page pins the label git:20261025.3b43540, 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.
A 17 of 17 checks passed. Fixed automatic checks with no AI involved, so the same checks give the same answer every run.
pass: Frontmatter block present
pass: Frontmatter declares a name
pass: Frontmatter declares a description
pass: Size between 200 bytes and 200 KB (3550 bytes)
pass: No zero-width or bidi control characters
pass: No instruction hidden inside an HTML comment
pass: No link to an exfiltration or paste host
pass: No credential-shaped string
pass: No instruction to send local credentials anywhere
pass: No text hidden with inline styles
pass: No prompt-injection phrasing
pass: No curl or wget piped into a shell
pass: No recursive delete of root, home or parent
pass: No instruction to read or print local credentials
pass: No base64 blob over 200 characters
pass: No link to a raw IP address
pass: No script tag
Source
GitHub
miklschmidt/archboard · 4 stars · license a license file GitHub does not identify · pushed 2026-11-09 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_bnr4vnmu4wjwesjo
GET https://markdownregistry.com/api/v1/resolve?ref=miklschmidt/archboard/tdd
GET https://markdownregistry.com/api/v1/blob/93ea419b76e9caaf26153b828e984f7c3fb136f4caa67b14af95f32ea965a1cc
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.
miklschmidt/archboard · .agents/skills/claude-handoff/SKILL.md · Hand the current conversation off to a fresh background agent that picks up the work immediately.
miklschmidt/archboard · .agents/skills/code-review/SKILL.md · Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code…
miklschmidt/archboard · .agents/skills/codebase-design/SKILL.md · Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find…
miklschmidt/archboard · .agents/skills/diagnosing-bugs/SKILL.md · Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports…
miklschmidt/archboard · .agents/skills/domain-modeling/SKILL.md · Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md…
miklschmidt/archboard · .agents/skills/grill-with-docs/SKILL.md · A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
miklschmidt/archboard · .agents/skills/grilling/SKILL.md · Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or…
miklschmidt/archboard · .agents/skills/impeccable/SKILL.md · Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt…
cursor/plugins · pstack/skills/tdd/SKILL.md · Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious…
cursor/plugins · harness/pstack/claude-code/skills/tdd/SKILL.md · Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious…
nightly-labs/openbot · marketplace/production-catalog/bundles/pstack/skills/tdd/SKILL.md · Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious…
michael-denyer/pstack-claude · plugins/pstack/skills/tdd/SKILL.md · Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious…
backnotprop/pstack · skills/tdd/SKILL.md · Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious…
