coverage-gap-analysislisted

# Coverage gap analysis `superpowers:test-driven-development` governs writing new code test-first. This skill is for the opposite direction: code already exists, has weak or no tests, and you need to find what's actually untested before touching it. Order matters — inventory (§1) before characterize (§4) before any new assertions, and never let "coverage went up" substitute for "the risk went down" (§3). ## 1. Branch/path inventory — before writing a single test Read the target code and enumerate, in a list, every point where behavior forks: - **Conditionals**: every `if`/`else`/`switch`/ternary branch, including the implicit "else does nothing" branch nobody wrote. - **Loops**: zero iterations, one iteration, many, early-exit (`break`/ `return` inside the loop). - **Error paths**: every `throw`/`catch`/`Result::Err`/error return, every place a caught exception is swallowed, logged-and-continued, or fell back silently. - **Boundary values**: empty string/collection, null/undefined/None, zero, negative, max-length, off-by-one at any range check (`<` vs `<=`). - **External-input validation**: what happens on malformed input at each parse/deserialize/validate call. Turn this into a checklist of `<location> -> <branch>` pairs before writing any test. A gap you didn't enumerate is a gap you won't test. ## 2. Mutation-testing mindset on EXISTING tests For every test that already exists and claims to cover a piece of code, ask: "what one-line bug could I introduce