Triage Issues

When to Use

Activate when the user wants to:

• •Prioritize a backlog of issues
• •Decide what to work on next
• •Assess the state of open issues and plans
• •Sort issues by impact, effort, or urgency

Steps

1. Gather Issues

Scan for open issues from available sources:

• •docs/plans/*.md files with status: open or status: planned
• •GitHub issues (if URL or repo context provided)
• •User-provided list of tasks

2. Analyze Each Issue

For each issue, assess:

• •Impact: How many users affected? How severe? Business value?
• •Effort: How many files changed? How complex? Dependencies?
• •Urgency: Deadline? Blocking other work? Customer-facing?
• •Risk: What happens if we don't do this? What could go wrong?

3. Categorize

Place each issue in one of four quadrants:

4. Recommend Priority Order

## Triage Results

### Recommended Order
1. **[Issue title]** — [Impact/Effort/Why first]
2. **[Issue title]** — [Impact/Effort/Why second]
3. ...

### Quick Wins (do anytime)
- [Issue] — [Why it's quick and valuable]

### Defer
- [Issue] — [Why it can wait]

### Drop Candidates
- [Issue] — [Why it may not be worth doing]

### Summary
- Open: [count] | Planned: [count] | In Progress: [count]
- Recommended next: [top issue]

Guardrails

• •Read-only. Do not modify issue files or change priorities without user approval.
• •Be honest about effort — don't underestimate to make the backlog look manageable.
• •Consider dependencies — an issue that unblocks three others should rank higher.