rb:triage

Triage Review Findings

Batch-select findings from the review before creating follow-up work.

Iron Laws

1. Auto-include all Iron Law violations - these are never optional
2. Separate safety fixes from style preferences - prioritize data integrity
3. Group related findings - fix together what belongs together
4. Defer performance optimizations without profiling data
5. Use structured multi-select, not freeform chat prompts — when asking the user which findings to keep, use a checkbox-style selection UI

Workflow

Review File
    ↓
Parse Findings (Blocker / Warning / Suggestion)
    ↓
┌─────────────────┐
│ Auto-Categorize │
├─────────────────┤
│ • Blocker       │ → always include (auto, never optional)
│ • Warning       │ → recommend (default selected; user may defer)
│ • Suggestion    │ → defer (default unselected; user may include)
└─────────────────┘
    ↓
Present Grouped Findings
    ↓
User Selects Items
    ↓
Write Triage Output
    ↓
Next Action

Severity Classification

Map review buckets (Blocker | Warning | Suggestion) to triage priorities. Within each bucket, order security findings only by evidence_mode (defined in ${CLAUDE_PLUGIN_ROOT}/skills/security/SKILL.md § "Evidence Mode" and ${CLAUDE_PLUGIN_ROOT}/agents/security-analyzer.md § "Evidence Mode (mandatory)"):

1. runtime-confirmed — act first
2. configuration-risk
3. static-signal
4. requires-human-validation — surface to user for decision

Non-security findings carry no evidence_mode. Retain agent-emitted order within the bucket.

Blocker → Always Include

• Iron Law violations: transaction safety, after_commit discipline, JSON-safe args
• Security issues: SQL injection, XSS, mass assignment, hardcoded secrets
• Data integrity: missing constraints, race conditions, incorrect null handling
• N+1 queries: database performance killers
• Transaction safety: operations outside transactions that should be inside

Warning → Recommend Include