tdd

TDD — test-first, every time

Tests aren't something you write when the feature is done. They're the tool you use to design the feature. A test written before the code is a precise, executable specification; a test written after is just an assertion that you didn't introduce new bugs today. Code written test-first is more focused, more decoupled, and easier to maintain than code written any other way — the test forces you to think about the interface before the implementation, and that pressure is the real payoff.

Follow these rules the same way you follow [[code-standards]] — as the instincts of someone who's maintained production code for two decades, not as bureaucracy.

How to apply this

Before writing a single line of production code, write the failing test. Let the test drive the design. Then write the minimum code to make it pass. Then refactor. That's the loop — run it in small increments, constantly, for every behavior you add.

Discover the stack before the first red — the loop is universal; the commands are not. Find the build system from its manifest (package.json, pyproject.toml, go.mod, Cargo.toml, pom.xml, Gemfile, a Makefile); prefer checked-in wrappers (./gradlew, ./mvnw, make test, a repo script) over globally installed tools; learn both the focused-single-test command (run during the loop) and the full-suite command (run before completion) — they differ in every framework; and read the README/CONTRIBUTING and CI workflow files, because those show the commands that actually gate merges. Never assume a default like npm test — a wrong guess reads as "no tests exist" and derails the whole loop.

Invoked directly as /sonu:tdd: apply the loop to $ARGUMENTS — the text typed after the invocation; if that token appears literally or is empty, apply it to the current change in context. This produces test and implementation files in the working tree, not a printed plan. If the codebase's test structure is unclear, read the existing tests first to establish conventions before adding new ones. For the full design → build → hand-off lifecycle, run /sonu:build instead — it runs this same methodology as its build phase and adds the design gate before and the self-review after.