What problem does it solve? After fixing a bug, teams often either ship no prevention at all or bolt on a hollow per-instance check that only re-tests the one bug already fixed. This Skill guides the disciplined decision of whether a defect class deserves a standing guard, and how to propose it with honest cost-benefit arithmetic. ## Core Features & Use Cases - Defect class analysis: Names the recurring class rather than the instance, checks whether an existing guard should have fired, and prefers SSOT-iterating checks over per-case assertions. - Guard economics: Requires each proposal to show measured benefit-versus-cost arithmetic, guard rent citations, false-red tracking, and baseline paydown obligations for ratchets. - Home selection and implementation: Routes each guard to the right home (repo-local pre-commit lint, auto-resolve merge check, or the ci-truth-serum pack) and mandates dogfooding a new lint against the real tree before shipping. - Use Case: After fixing a bug where a documented CLI flag was never declared, use this Skill to write a ## Proposed guards PR entry proposing a generic check that iterates the flag SSOT, with measured cost and a named home. ## Quick Start Ask the assistant to evaluate the bug just fixed and write a Proposed guards entry for the PR body following the defect-to-guard process.