bug-analyzerlisted

# bug-analyzer ## When to use **Reactive mode:** User reports a bug, shares a Sentry issue, or asks to investigate an error. **Proactive mode:** User asks to audit code for hidden bugs, edge cases, or risky patterns. Do NOT use when: * Feature development — route to [`feature-planning`](../feature-planning/SKILL.md) * Code style or refactoring — route to [`code-refactoring`](../code-refactoring/SKILL.md) * Performance issues — route to [`performance-analysis`](../performance-analysis/SKILL.md) * Security vulnerabilities — route to [`security-audit`](../security-audit/SKILL.md) * You need to trace how one data element flows through the code — route to [`data-flow-mapper`](../data-flow-mapper/SKILL.md) * You need to enumerate every call site / consumer affected by a planned fix — route to [`blast-radius-analyzer`](../blast-radius-analyzer/SKILL.md) ## Input sources Bugs can come from multiple sources — gather as many as available: | Source | What it provides | |---|---| | **Branch name** | Auto-detected ticket ID (e.g., `fix/DEV-1234/...`) | | **Jira ticket** | Description, acceptance criteria, comments, priority | | **Sentry issue URL** | Stacktrace, affected users/environments, frequency, tags | | **Sentry event ID** | Specific occurrence with full context | | **Error message** | String to search in codebase | | **User description** | Reproduction steps, expected vs. actual behavior | ### Branch ticket detection Always check the current branch for ticket IDs: ``