---
name: "step-05-code-review"
description: "Perform adversarial code review using Reviewer role, delegating to code-review workflow logic"
nextStepFile: "./step-06-test-story.md"
nextStepFile_issues: "./step-07-fix-and-retest.md"
kind: "quality-gate"
---

# Step 5 of 9: Code Review

**Goal:** Perform an adversarial code review to validate implementation quality, catching issues before QA testing.

**Role:** Adversarial Code Reviewer

---

## EXECUTION SEQUENCE

### 1. Switch to Reviewer Role

Adopt the Adversarial Code Reviewer persona:
- YOU ARE AN ADVERSARIAL CODE REVIEWER — Find what's wrong or missing!
- Validate story file claims against actual implementation
- Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented?
- Find 3-10 specific issues minimum — no lazy "looks good" reviews

### 2. Execute Code Review

Invoke the `xiaoma-code-review` skill to perform the code review.

Key parameters to pass:
- `{story_path}` = `{current_story_path}`
- The code-review workflow uses 4 sharded steps:
  1. `step-01-gather-context` — Load story and discover changes via git
  2. `step-02-review` — Execute adversarial review (AC validation, task audit, code quality, test quality)
  3. `step-03-triage` — Classify each finding into one of code-review's native buckets: intent_gap / bad_spec / patch / defer / reject (this pipeline step then assigns its own CRITICAL/HIGH/MEDIUM/LOW severity in section 3 for auto-fix prioritization)
  4. `step-04-present` — Present findings and recommendations (non-interactive; it does NOT auto-fix)

**CRITICAL PIPELINE MODE INSTRUCTIONS:**
- `xiaoma-code-review` step-04 (present) is **non-interactive** — it surfaces findings and recommendations but does NOT modify code and does NOT offer a fix/skip menu to select. In pipeline mode, do NOT wait for a code-review choice: carry the surfaced findings into section 3 below, where this step (in its Reviewer role) assigns each a CRITICAL/HIGH/MEDIUM/LOW severity and auto-fixes them. Treat code-review `patch` / `bad_spec` / `intent_gap` findings as actionable; `defer` / `reject` findings need no fix
- Do NOT exclude `_xiaoma/` or IDE configuration folders from review scope — the workflow handles these exclusions internally

### 3. Auto-Fix Review Findings

**CRITICAL:** In pipeline mode, automatically fix issues instead of asking the user:

1. **CRITICAL severity issues** — These represent fundamental defects (security holes, data corruption risks, broken core ACs). Always attempt an inline fix first; if a CRITICAL issue cannot be resolved inline (e.g., requires architectural change), route immediately to step-07 (fix-and-retest) regardless of HIGH/MEDIUM state, AND set `{fix_source}` = "code-review" with the CRITICAL flag preserved so step-07 prioritizes it as Priority 1. Never silently down-grade CRITICAL to HIGH/MEDIUM. When this routing occurs, append to `{run_warnings}`: `[step-05] CRITICAL finding for {current_story_key} unresolvable inline — routed to step-07 with CRITICAL flag preserved`.
2. Fix ALL HIGH severity issues immediately
3. Fix ALL MEDIUM severity issues
4. Document LOW severity issues as action items but do not block the pipeline
5. Update the story file with:
   - Fixed issues noted in Dev Agent Record (include severity in each entry)
   - Updated File List with any newly modified files
   - Change Log entry for review fixes (note count by severity: e.g., "Review fixes: 1 CRITICAL, 3 HIGH, 2 MEDIUM")

### 4. Evaluate Review Outcome

**IF all CRITICAL, HIGH and MEDIUM issues are fixed AND all ACs are implemented:**
- Set story status to "review" (ready for QA)
- Output: "Code review complete. All critical issues resolved. Proceeding to QA testing."
- **NEXT:** Proceed to step-06 (test story) [frontmatter: nextStepFile]

**IF any CRITICAL issue remains OR there are remaining HIGH or MEDIUM issues that could not be auto-fixed:**
- Output the unresolved issues, ordered CRITICAL → HIGH → MEDIUM
- Set `{fix_source}` = "code-review" (used by step-07 for routing)
- Append to `{run_warnings}`: `[step-05] Unresolved code-review findings for {current_story_key} (CRITICAL/HIGH/MEDIUM counts: {c_count}/{h_count}/{m_count}) — routed to step-07`
- **NEXT:** Proceed to step-07 (fix and retest) to address remaining issues [frontmatter: nextStepFile_issues]

### 5. Pipeline Status Update

- Set `{pipeline_status}` = "code-review-complete"
- Set `{steps_completed}` = `{steps_completed}` + 1

---

## NEXT STEP

**If all issues resolved:**
**NEXT:** Read fully and follow: `./steps/step-06-test-story.md`

**If issues remain:**
**NEXT:** Read fully and follow: `./steps/step-07-fix-and-retest.md`

---

## SUCCESS METRICS

- All CRITICAL, HIGH and MEDIUM issues identified and resolved
- No tasks marked [x] that are not actually implemented
- All ACs verified as implemented
- Code quality meets project standards
- Tests are real assertions, not placeholders

## FAILURE MODES

- Lazy "looks good" review with < 3 findings
- Not cross-referencing git reality vs story claims
- Skipping AC validation
- Not fixing HIGH severity issues before proceeding