Defame1297
e869912374
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.
33 lines
2.6 KiB
Markdown
33 lines
2.6 KiB
Markdown
# 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
|
|
|
|
```text
|
|
/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 |
|