@xiaowen-jiang/bug-triage

---

name: Bug Triage description: Analyze bug reports, assess severity, identify root cause, and recommend fixes version: "1.0" tags: [engineering, quality, debugging] complexity: intermediate requires_tools: [mcp:filesystem:*]

Process

1. Understand the bug report — What was expected? What happened instead?
2. Read related code — Find the code path where the bug occurs
3. Reproduce mentally — Trace the execution flow to understand why the bug happens
4. Classify severity:
   • P0 (Critical): Data loss, security vulnerability, complete feature broken
   • P1 (High): Major feature degraded, no workaround
   • P2 (Medium): Feature partially broken, workaround exists
   • P3 (Low): Cosmetic issue, minor inconvenience
5. Identify root cause — The actual code/logic error, not just symptoms
6. Assess blast radius — What else could be affected?
7. Propose fix — Specific code changes with effort estimate

Output Format

## Bug Triage Report

**Severity**: P0/P1/P2/P3
**Component**: [module/file affected]
**Root Cause**: [1-2 sentence explanation]
**Blast Radius**: [what else is affected]

### Reproduction Steps
1. ...

### Proposed Fix
- File: path/to/file.py
- Change: [description of fix]
- Effort: Small (< 1hr) / Medium (1-4hr) / Large (4hr+)

### Regression Risk
[What could break if we fix this incorrectly]

Guidelines

• Always read the actual code before diagnosing — don't guess
• Distinguish symptoms from root cause
• Consider if the bug is a regression (did this work before?)
• Check for similar patterns elsewhere in the codebase
• Prioritize data integrity and security bugs above all else
• Include a test case that would catch this bug