complete-test-codelisted

Use this skill whenever the user wants test code written, added, audited, or judged "good enough" — not merely run. Trigger when they: ask you to write or improve tests for a module (parser, retry/network logic, migration, auth/token, billing, state machine, library/SDK); worry that edge cases or "garbage input" keep slipping through release after release; ask what testing a component needs before shipping, open-sourcing, or tagging a version; want code made robust, reliable, or production-ready; report flaky, missing, or weak tests; or raise data corruption, crash/rollback/atomicity, concurrency, or fault-handling concerns. Also apply proactively right after non-trivial logic is implemented, to cover failure paths and boundaries even if "test" was never said. Brings SQLite-grade methods (fuzzing, property/differential/metamorphic testing, fault injection, mutation testing, coverage) but right-sizes rigor to the component's blast radius. Not for just running an existing suite or general debugging.
shyuan/skills · ★ 5 · Testing & QA · score 74

Install: claude install-skill shyuan/skills

# Complete Test Code Reliability is not achieved by careful coding alone — it is *earned by testing*. This skill packages the testing methodology that makes [SQLite](https://sqlite.org/testing.html) one of the most reliable pieces of software on Earth, and translates it into practices you can apply to **any** project, in any language, at a cost proportional to what's at stake. Two jobs: - **Writing** new tests with the rigor the code actually deserves. - **Auditing / hardening** an existing suite — finding the gaps that let bugs through. The goal is never "more tests." It is *the right tests, where they matter, that would actually notice if the code were wrong.* --- ## Core philosophy — adopt this mental model first These seven ideas are the whole skill in compressed form. Everything else is mechanics. 1. **Test investment scales to blast radius, not to code size.** What determines how much rigor a component deserves is the *cost of being wrong* — how widely it's deployed, how hard a bad release is to recall, and whether it persists state that "remembers" mistakes. A near-zero test ratio on a load-bearing module is the real red flag; an imperfect coverage number on a throwaway script is not. 2. **The unhappy path is where reliability lives.** Correct behavior on good input on a healthy machine is the easy part. The hard, valuable work is sane behavior under bad input and system malfunction (OOM, I/O errors, crashes, timeouts, corruption). Error-ha