test-driven-development

Write one minimal failing test for a single behavior, run it to confirm it fails for the expected reason, then implement the simplest production code to make it pass. This Skill handles the test side only and hands off production-code implementation to you or another agent.

Re-run the suite multiple times and compare sequential versus parallel execution to surface intermittent failures. Common root causes include fixed sleeps, wall-clock reads, unseeded randomness, shared state, and real network calls, which are fixed by injecting clocks, seeding randomness, and isolating state.

Stubs return canned answers for state-based verification, mocks verify that specific interactions occurred, and fakes are lightweight working implementations like in-memory databases. Use mocks only when the interaction itself is the contract; prefer stubs or fakes at volatile seams like databases and clocks.

No, coverage is only a negative indicator since 100% line coverage can be achieved with zero assertions. Mutation testing is the stronger signal because it injects faults and checks whether your tests actually fail, revealing weak assertions that coverage hides.

No, it never edits production or source code under any circumstance. When it discovers production-code issues, it reports them as handoff notes and recommends the code-review or security-review skills instead.

The workflow is language-agnostic and covers pytest, jest, vitest, JUnit, xUnit, Go test, and Rust cargo test among others. It detects the project's actual tooling from config and CI files, then researches current language-specific idioms online before applying them.