Bug-Class Audit

Quantify how systemic a specific bug class is by classifying every recent fix: PR against explicit inclusion/exclusion criteria, then reporting a headline percentage plus the representative examples and patterns that make the number actionable.

The output of this skill is a number the user can put in front of stakeholders ("19% of our fix PRs in the last 100 merged were the same bug") plus the examples they can point at to make the case for whatever change the audit motivates. Without this rigor, "we keep shipping the same bug" is a vibe — with it, it's an argument.

When to use

• The user names a bug class they think is recurring and wants to size it: "is the stale-state pattern really a problem?", "how often do we forget to invalidate?", "is silent error swallowing a real issue here?"
• The user asks for a brittleness or quality audit of an unfamiliar codebase ("we just took this codebase over — what's most fragile?")
• An architectural change is being considered and needs justification ("should we migrate to X?" — audit the bugs X would prevent)
• A specific incident just happened and you want to know if it was a one-off or the tip of a pattern

When NOT to use

• The user just wants a code review of a specific PR — use a PR-review skill instead
• The user wants to investigate a single bug — use git-blame / debugging skills instead
• The user has no specific hypothesis and wants a generic codebase review — push back and either (a) propose a class from references/bug-classes.md, or (b) suggest a broader audit skill instead