Tdd

Invocation points:

• Task plan calls out behavior with a clear external contract (pure function, API endpoint, module boundary)
• Bug fix — write the failing repro test first, then fix
• Refactor into a new module — write the tests against the new interface first

Do not use this skill for:

• Exploratory spikes (use /gsd start spike — no production code ships)
• Pure UI polish where visual verification beats unit tests
• Scripts that run once and are deleted

<core_principle> TESTS VERIFY BEHAVIOR THROUGH PUBLIC INTERFACES, NOT IMPLEMENTATION DETAILS. A good test reads like a specification and survives refactors. A test that mocks internals or asserts private state fails every time you clean up the code — that is a bad test pretending to be a good one.

VERTICAL SLICES, NOT HORIZONTAL LAYERS. Writing all tests upfront ("horizontal slicing") produces tests for behavior you imagined, not behavior the code actually exhibits. One tracer bullet at a time: write one test, make it pass, learn, write the next.

NEVER REFACTOR WHILE RED. Refactoring without a passing test means you are guessing whether you broke something. Get to green first. Then clean up. Then go red again for the next slice. </core_principle>

Step 1: Confirm the interface

Before writing anything:

1. What is the public interface? (function signature, HTTP route, module exports)
2. Which behaviors matter most? List them in order of how badly you'd want to know if they broke.
3. What does a "caller" look like? Write one example call in prose.

If the user has not supplied these, ask — one round, 1–3 questions.

Step 2: Tracer bullet