Test driven development
Skill stevenfackley/opencode-amplifier/.opencode/skills/test-driven-development
Contract-governed OpenCode config that amplifies constrained LLMs (Sonnet 4.5, GPT-5.1, cheap corp models) into near-frontier coding agents: multi-agent pipeline with per-agent models, independent test-gen + locked tests, golden-pattern corpus, cross-model review, and an eval harness.
npx -y skills add stevenfackley/opencode-amplifier --skill test-driven-developmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when implementing any feature or bugfix. Write a failing test first (RED), the minimal code to pass it (GREEN), then refactor. With constrained models the test is an executable spec the model cannot drift from — and it structurally prevents verification gaming.
SKILL.md
1.8 KB, as published. Nobody here has run it
Test-Driven Development
A weak model that writes code first and tests later will write tests that rubber-stamp its own bugs. TDD flips that: the test becomes a contract written before the implementation exists, so it can't be reverse-engineered to pass broken code.
The loop
- RED — write one small test that expresses the next required behavior. Run it. Watch it FAIL for the right reason. A test that passes immediately is testing nothing.
- GREEN — write the minimal code to make that test pass. No extra features. Run the suite.
- REFACTOR — clean up with the test as a safety net. Re-run; stay green.
- Repeat for the next behavior.
Hard rules (these are what make it work with weak models)
- Test files are locked during GREEN. Once a test is written and committed, the
implementation step may NOT edit it. If a test needs to change, that's a separate, explicit
decision — never a silent edit to make red go green. (Enforced by the
tdd-lockplugin.) - For non-trivial features, the tester agent (a different model that never sees your
implementation) writes the spec tests from the plan — use
/spec-tests. - Show the actual RED output and the actual GREEN output. "It passes" without the run is a
violation of
verification-before-completion.
When to relax
- Throwaway spikes/exploration — but the moment you keep the code, back-fill the tests.
- True UI pixel-tweaks where a test costs more than it protects — use judgment, state it.
Gives 4 of the 12 instructions most tdd skills give
Counted across 439 of the 443 authors here whose files we hold, read 2026-08-06
- write minimal code to pass the testhere, and in 302 of 439, across 218 files
- write a failing test firsthere, and in 176 of 439, across 112 files
- refactor code only after tests passin 171 of 439, across 101 files
- watch the test fail before writing codein 142 of 439, across 93 files
- test one behavior per testin 106 of 439, across 44 files
- refactor code while keeping tests greenhere, and in 99 of 439, across 86 files
- delete code written before testsin 98 of 439, across 54 files
- run tests after each refactor stepin 85 of 439, across 54 files
- Use real code instead of mocks unless unavoidablein 64 of 439, across 21 files
- confirm the test fails for the right reasonhere, and in 64 of 439, across 60 files
- reproduce bugs with a test before fixingin 53 of 439, across 36 files
- write tests before implementationin 48 of 439, across 39 files
Said here and by no other author read
- show actual RED and GREEN output
- back-fill tests when keeping throwaway code
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.