bug-huntlisted

# Bug Hunt ## Overview A **proactive, source-driven** search for bugs that have not surfaced yet. You are not fixing a reported failure and you are not checking a feature against a spec — you are reading the implementation as written, building a mental model of how data moves through it, and asking at every step "what input, ordering, or state makes this go wrong?" The output is a list of concrete, evidence-backed findings, each rated on the project's standard severity model and each pointing at an exact location with a way to reproduce it. This is the discovery counterpart to the kit's other quality skills. Use it when you want to find *unknown* problems in code that currently "works." ## When to Use - Before shipping a feature, to surface defects the happy-path tests never exercise. - After a feature is built but before (or alongside) the formal review gates. - When inheriting unfamiliar code and you need to know where it is fragile. - When a class of bug keeps recurring and you want to sweep a module for siblings. **When NOT to use:** - A test is failing or an error is in front of you → `debugging-and-error-recovery` (reactive, single root cause). - You are reviewing a specific change/diff → `code-review-and-quality` (change-scoped). - You need to verify behavior against acceptance criteria on a running app → the `tester` / `senior-tester` lane. ## How It Differs | Skill / agent | Trigger | Scope | |---|---|---| | **bug-hunt** (this) | proactive, nothing is br