Files
holocron/plugins/bin/skills/tdd
Defame1297 e869912374 docs(bin): give every bin skill a README
The bin skills were the only plugin without per-skill READMEs, so a reader
had to open SKILL.md — an agent-facing contract, not an explainer — to learn
what a skill does and when it fires. Each README states purpose, triggers and
boundaries for a human audience, leaving SKILL.md free to stay terse.
2026-08-31 08:02:09 +00:00
..

tdd

Test-driven development as a strict red-green-refactor loop, one behaviour at a time.

What it does

Two convictions drive this skill. The first is about what a test is for: tests verify behaviour through public interfaces, not implementation details. A good test reads like a specification ("user can checkout with valid cart") and survives refactors because it does not care about internal structure. The warning sign for a bad one is precise — the test breaks when you refactor but behaviour has not changed.

The second is an explicit anti-pattern: do not write all the tests first, then all the implementation. Horizontal slicing treats RED as "write every test" and GREEN as "write every implementation", and it produces tests of imagined behaviour — tests of the shape of things, insensitive to real change, committed to before the implementation was understood. The correct shape is vertical: one test → one implementation → repeat, each cycle informed by what the last one taught you.

The workflow is four stages: plan (confirm the interface and which behaviours matter, with the user — you cannot test everything), fire a tracer bullet (one test proving the path works end to end), loop incrementally one behaviour at a time, then refactor once everything is green. Refactoring while RED is forbidden.

Codebase exploration uses the project's domain glossary, so test names and interface vocabulary match the project's language, and ADRs in the area are respected.

Usage

/tdd

Describe the feature or bug. Expect the skill to ask what the public interface should look like and which behaviours matter most before any code is written. For diagnosing an existing bug rather than building test-first, use diagnose; for throwaway exploratory code, use prototype.

Files

File Purpose
SKILL.md Philosophy, the horizontal-slicing anti-pattern, the four-stage workflow, and the per-cycle checklist
tests.md Skill-root document, cited from Philosophy: worked good and bad test examples
mocking.md Skill-root document, cited from Philosophy: mock at system boundaries only, and what not to mock
deep-modules.md Skill-root document, cited from stage 1: what a deep module is (small interface, large implementation) and why it is the design to aim for
interface-design.md Skill-root document, cited from stage 1: designing interfaces for testability, starting with accepting dependencies rather than creating them
refactoring.md Skill-root document, cited from stage 4: the refactor-candidate checklist — duplication, long methods, shallow modules, feature envy, primitive obsession