wow20/.claude/skills/bmad-code-review/steps/step-03-triage.md

---

---

Step 3: Triage

RULES

• YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config {communication_language}

INSTRUCTIONS

1. Normalize findings from all layers into a unified list where each finding has:

   • id -- sequential integer
   • source -- the id of the layer that produced the finding (e.g., blind-hunter), or merged sources joined with + (e.g., blind-hunter+edge-case-hunter)
   • title -- one-line summary
   • detail -- full description
   • location -- file and line reference (if available)

2. Deduplicate. Deduplicate only findings with the same claim and same required action. If two or more findings meet both conditions, merge them into one:

   • Use the most specific finding as the base (prefer findings with a precise location over prose-only findings).
   • Append any unique detail, reasoning, or location references from the other finding(s) into the surviving detail field.
   • Set source to the merged sources (e.g., blind-hunter+edge-case-hunter).

3. Then evaluate each remaining finding independently. Do not reject a finding because a related finding was rejected.

4. Read the code before rating. Before assigning severity, open the source at each finding's location and read enough surrounding code to judge reachability -- call sites, guards, and validation that live outside the diff hunk. Do not rate from the diff hunk alone. Severity reflects the real consequence at a real call site, not the worst theoretical reading.

5. Assign severity to each finding by consequence for the artifact's main consumer (software user, document reader, etc). Disregard any severity assigned by a reviewing subagent. Review subagents operate under by-design information asymmetry and do not have enough context to set final severity for this workflow.

   • low -- none or cosmetic
   • medium -- tolerable
   • high -- intolerable

6. Route each finding into exactly one triage bucket:

   • decision_needed -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if {review_mode} = "full".
   • patch -- Code issue that is fixable without human input. The correct fix is unambiguous.
   • defer -- Pre-existing issue not caused by the current change. Real but not actionable now.
   • dismiss -- Noise, false positive, or handled elsewhere.

   If {review_mode} = "no-spec" and a finding would otherwise be decision_needed, reclassify it as patch (if the fix is unambiguous) or defer (if not).

7. Drop all dismiss findings. Record the dismiss count for the summary.

8. If {failed_layers} is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND {failed_layers} is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.

9. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via {failed_layers}.)

NEXT

Read fully and follow ./step-04-present.md