| 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
- Understand the bug report — What was expected? What happened instead?
- Read related code — Find the code path where the bug occurs
- Reproduce mentally — Trace the execution flow to understand why the bug happens
- 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
- Identify root cause — The actual code/logic error, not just symptoms
- Assess blast radius — What else could be affected?
- 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
