bug-finder

Bug finder — find one real defect, prove it, file it

Most bugs reach production because nobody was looking in the places bugs live. This pass goes looking deliberately, and it holds itself to a standard that makes the output worth a human's attention: one concrete defect, backed by evidence, filed as a ticket somebody can act on.

The failure mode this skill is built to prevent is the plausible-sounding audit — twenty speculative observations, no reproduction, no evidence. That output is worse than silence: every item costs a maintainer time to dismiss, and after one such report the next one gets ignored entirely. One proven bug beats twenty maybes, so the bar is deliberately set where speculation cannot clear it.

How to apply this

Apply to $ARGUMENTS — the text typed after the invocation, an optional area to hunt in (a directory, module, or subsystem). If that token appears literally or is empty, choose the hunting ground yourself using section 1's priorities.

Load Skill(sonu:ticket-lifecycle) for the tracker and the create operation, then run sections 1 through 4 in order. Sections 2 and 3 are the gate: nothing gets filed that has not cleared them.

---

1. Hunt where bugs actually live

Read repository instructions first, then look at recent history and open work so you do not re-find something already in flight.

Prioritize, in roughly this order — these are the places defects concentrate, not a checklist to complete:

• Recently changed code. Fresh code has had the least exposure; a defect there is both more likely and cheaper to fix now.
• Error handling and fallback paths. The catch block, the default value, the retry — rarely exercised in tests, and a silent fallback converts breakage into wrong data that nobody notices.
• Untrusted input boundaries. Request parsing, deserialization, file and header handling, anything from a third party.
• Process and persistence boundaries. Serialization round trips, transaction scope, partial writes, what happens when the second call fails after the first succeeded.
• Concurrency and cleanup. Read-then-write races, shared mutable state, unreleased locks or handles, work that assumes it runs alone.
• Weak coverage. Compare what tests assert against what the code does; the gap is where nobody has looked.