project-review

name	project:review
description	Local code review with multi-round review & fix cycle. Use for reviewing code, checking changes, getting feedback on a branch, or before creating a PR.
argument-hint	(optional special instructions)
version	1.8.2
last-modified	"2026-06-23T00:00:00.000Z"
allowed-tools	["Read","Edit","Write","Grep","Glob","Bash(git:*)","Task","AskUserQuestion"]

Review Skill

You are executing the review skill, which provides local code review with a multi-round review & fix cycle on a feature branch vs main.

RESULTS DISPLAY GUARANTEE

The skill MUST ALWAYS surface its review results. It never finishes silently. This holds in every mode — embedded (called from plan-and-do) or stand-alone, dry-run or normal.

Every run MUST produce the full review content. One of these two carries it:

1. Markdown file — normal mode. The review is written to [docs_folder]/reviews/REVIEW-<branch>.md (PHASE 6).
2. On screen — dry-run mode. The full review content is displayed in the conversation instead of writing a file (PHASE 6).

On top of that, the PHASE 7 summary is always printed to screen. In every mode. Including embedded. So the caller and the user both see the outcome.

Embedded mode skips only PHASE 0 (plan-mode check and header) and PHASE 1.3 (task-understanding confirmation). It still runs PHASE 6 and PHASE 7. So it still writes the review file and prints the summary.

If a run reaches the end without producing either the Markdown file or the on-screen content, that is a bug. Produce the on-screen content before stopping.

Writing Style

Short and brief. Short sentences. Simple words non-native speakers understand. No passive voice. Use sentence fragments.

FILE PATH DISPLAY RULE

When displaying any file path to the user, ALWAYS use the full absolute path. Get the project root with pwd and prepend it to relative paths. Example: /Users/dev/project/docs/reviews/REVIEW-add-feature.md instead of docs/reviews/REVIEW-add-feature.md. This lets users Command-click paths in the terminal to open them.

HOW TO ASK THE USER FOR DECISIONS

Use the AskUserQuestion tool for all user prompts. This is the built-in tool that pauses execution and waits for the user to type a response.

Numbered choices: Pass the full question text (including numbered options) as the question parameter.

Freeform input: Pass the question as the question parameter.

Wait rule: After calling AskUserQuestion, you MUST wait for the user's response before taking any further action. Never assume a choice, skip the question, or proceed without the user's answer. The user's response drives what happens next.

User Autonomy

Complete all review work autonomously without mid-execution prompts. Interrupting to ask "Should I continue?" or "Should I review the next file?" breaks flow and wastes time. Only prompt when a genuine decision is needed to proceed — not for status checks or confirmations.

ARGUMENTS HANDLING

Skill receives: $ARGUMENTS

Parse arguments to determine mode:

• Empty or whitespace -> Local review mode (default)
• "help" -> Help mode (show usage and exit)
• "doctor" -> Doctor mode (run health checks and exit)
• "dryrun" or "dry-run" or "dry_run" -> Dry-run mode
• "embedded" -> Embedded mode (called from plan-and-do, skip header/plan-check/confirmation)
• base:<ref> -> Optional. Compare against <ref> (a branch name or commit SHA) instead of main/master. Combines with other modes, e.g. embedded base:abc1234. This token is extracted in PHASE 1 parsing and is NOT treated as special instructions.
• Other text -> Treat as special instructions for the review

PHASE 0: PLAN MODE CHECK & HEADER

If embedded mode: Skip plan mode check, header, and task understanding confirmation. Jump directly to PHASE 1.5: TOOL VALIDATION.

If NOT embedded mode:

Check if Claude Code is in plan mode.

If in plan mode, output:

Plan mode detected. This skill cannot run in plan mode.

Exit plan mode first, then run:
  /review

Then STOP immediately.

If NOT in plan mode, display header:

Code Review (v1.8.2, 2026-06-23)
****************************************

Local code review - multi-round review & fix cycle

Then continue to PHASE 1.

PHASE 1: PARAMETER PARSING & MODE DETECTION

Parse $ARGUMENTS to determine execution mode.

Step 1.0: Extract Base Override

Before any other parsing, scan $ARGUMENTS for a base:<ref> token (starts with literal base: followed by a branch name or commit SHA, no spaces inside the token).

• If found: extract the ref value, store as base_override. Remove the base:<ref> token from $ARGUMENTS so it does not appear in special_instructions.
• If not found: set base_override = null.

The remaining $ARGUMENTS (after removing the base: token) is parsed as usual in Step 1.1.

Step 1.1: Check for Special Modes

Check if $ARGUMENTS matches:

• "help" -> Execute Help Mode and STOP
• "doctor" -> Execute Doctor Mode and STOP
• "dryrun" or "dry-run" or "dry_run" (case-insensitive) -> Set dry_run_mode = true, continue
• Other non-empty text -> Store as special_instructions, continue

Step 1.2: Announce Mode

Output:

Local Review Mode - analyzing local changes

If special_instructions set:

Special instructions: [special_instructions]

Proceed to PHASE 1.3: TASK UNDERSTANDING CONFIRMATION.

---

PHASE 1.3: TASK UNDERSTANDING CONFIRMATION

If special_instructions are set (non-empty, non-default mode):

Repeat back your understanding of the review focus to the user:

Output understanding, then call AskUserQuestion:

My understanding: Review local changes with focus on [brief summary of special_instructions].

  1 - Correct, proceed
  2 - Clarify instructions

Wait for the user's response before continuing:

• "1" or "ok"/"yes"/"correct" → Continue to PHASE 1.5.
• "2" or "clarify"/"change" → Call AskUserQuestion: "What should I change?" Wait for response. Update special_instructions. Return to this step.
• Anything else → Call AskUserQuestion again with the same options. Wait for response.

If no special_instructions (default review mode):

• Skip confirmation (nothing custom to confirm).
• Continue to PHASE 1.5.

---

PHASE 1.5: TOOL VALIDATION

Validate required tools before main workflow.

Step 1.5.1: Check git (Critical)

git --version

If fails:

REQUIRED: git unavailable

This skill requires git for diff analysis.

Install: brew install git

Then STOP.

If succeeds:

• Show: "git available"
• Continue to PHASE 1.7: AGENT DISCOVERY

---

PHASE 1.7: AGENT DISCOVERY

Read the project's CLAUDE.md (the one in the project root, not this skill file) and look for an ## Agents section.

If ## Agents section found:

1. Parse markdown tables to extract agent names and purposes
2. Exclude general tooling agents: skip any agent whose name starts with python-, shell-, or skill- — they are not CRM domain agents
3. Extract reviewer agents (names containing -reviewer, after exclusion)
4. Extract coder agents (names containing -coder, after exclusion)
5. Extract designer agents (names containing ui-designer or -designer, after exclusion)
6. Store all_reviewers, all_coders, all_designers
7. Set review_agents_available = true if reviewers found
8. Set fix_agents_available = true if coders OR designers found
9. Display: "Review agents: [list of reviewer agent names]"
10. Display: "Fix agents: [list of coder and designer agent names]"

If no ## Agents section found or CLAUDE.md missing:

• Set review_agents_available = false
• Set fix_agents_available = false
• Display: "No agents found. Using built-in review checklist."

Continue to PHASE 2: VALIDATION & SETUP.

---

Context Recovery

If you lose track of variables (e.g., after context compression), re-read the state file at [docs_folder]/state/STATE-REVIEW-<branch>.json. It contains all runtime configuration, discovered agents, and progress. Trust the file over conversation memory.

Note: The state file is created in Phase 3.4. If context compresses before that, re-derive docs_folder and current_branch from git before reading the state file.

Note: The loop counters current_round and max_rounds are NOT persisted (the state file is written before Phase 5). After recovery, re-derive: max_rounds = 3 if fix_agents_available else 1; current_round = number of rounds already in all_round_results, plus 1 if the last round is mid-flight.

---

PHASE 2: VALIDATION & SETUP

Step 2.1: Validate Git Repository

Verify git repository:

git rev-parse --git-dir

If fails, output:

ERROR: Not in git repository

This skill requires git repository.

Run: git init
Or: cd to existing repository

Then STOP.

Step 2.2: Validate Current Branch

Get current branch:

git branch --show-current

Check not on main/master:

if [ "$branch" = "main" ] || [ "$branch" = "master" ]; then
  # Error
fi

If on main/master, output:

ERROR: On main/master branch

Local review requires feature branch.

Create branch: git checkout -b feature-branch

Then STOP.

Store current branch as current_branch.

---

PHASE 3: IDENTIFY CHANGED FILES

Step 3.1: Determine Base Branch

If base_override is set:

Verify the ref exists:

git rev-parse --verify "<base_override>^{commit}" >/dev/null 2>&1

• If it succeeds: set main_branch = base_override. Skip main/master detection entirely. Display: "Base override: <base_override>".
• If it fails: display "Warning: base override <base_override> not found, falling back to main/master." Then continue with main/master detection below.

If base_override is null (or the override lookup above failed):

Check which main branch exists:

git rev-parse --verify main >/dev/null 2>&1 && echo "main"
git rev-parse --verify master >/dev/null 2>&1 && echo "master"

Use first that exists. Store as main_branch.

If neither exists, output:

ERROR: No main/master branch

Cannot determine base branch for comparison.

Create main branch: git checkout -b main

Then STOP.

(main_branch holds the resolved comparison base — either the override ref or the detected main/master.)

Step 3.2: Fetch Latest Changes

A commit SHA needs no fetch — it is already in the local object store. Only fetch when the base is a branch name.

If base_override looks like a full SHA (40 hex chars) or a short SHA (7+ hex chars with no /), skip the fetch. Otherwise:

git fetch origin <main_branch> 2>/dev/null || true

Ignore errors if no remote configured. The || true already tolerates any failure.

Step 3.3: Get Changed Files

Get list of changed files vs the resolved base (main_branch — override SHA or detected main/master):

git diff --name-only <main_branch>...HEAD

Include uncommitted changes:

git diff --name-only HEAD

Include staged-but-uncommitted changes:

git diff --name-only --cached

Combine all three lists, deduplicate.

If no changes found, output:

No changes detected

No files changed vs <main_branch>.
No uncommitted changes found.

Nothing to review.

Then STOP.

Store changed files list.

Step 3.4: Persist State

Detect docs folder:

test -d doc && echo "doc" || (test -d docs && echo "docs" || echo "none")

Create state directory:

mkdir -p [docs_folder]/state

Write state file to [docs_folder]/state/STATE-REVIEW-<current_branch>.json using the Write tool:

{
  "version": 1,
  "branch": "<current_branch>",
  "main_branch": "<main_branch>",
  "docs_folder": "<docs_folder>",
  "special_instructions": "<special_instructions or null>",
  "review_agents_available": <true/false>,
  "fix_agents_available": <true/false>,
  "all_reviewers": [<list>],
  "all_coders": [<list>],
  "all_designers": [<list>],
  "changed_files": [<list>],
  "dry_run_mode": <true/false>,
  "started": "<ISO timestamp>"
}

This file is not committed — it exists only for context recovery if conversation context compresses mid-review.

---

PHASE 4: PROJECT CONTEXT ANALYSIS

Analyze project documentation to understand goals, requirements, and conventions.

Step 4.1: Read PRD (if exists)

Search for PRD files using Glob tool with pattern **/PRD*.md or **/prd*.md.

If found: Read with Read tool (use offset/limit for files >220KB). Extract purpose, goals, requirements, success criteria.

If not found: Infer project context from repository name and structure.

Step 4.2: Read CLAUDE.md (if exists)

Search using Glob tool with patterns **/CLAUDE.md and **/claude.md.

If found: Read with Read tool (use offset/limit for files >220KB). Extract required/prohibited practices, code conventions, technology stack, testing requirements.

If not found: Infer conventions from existing code files.

Step 4.3: Combine Context

Create context summary from PRD (purpose, goals, requirements) and CLAUDE.md (conventions, prohibited practices). Store for review phase.

---

PHASE 5: MULTI-ROUND REVIEW & FIX CYCLE

Up to max_rounds rounds (3 with fix agents, 1 without — see Step 5.0). Each round: reviewers find issues, fixers plan fixes, the user approves the fixes (Step 5.2.5), reviewers validate the plan, fixes applied. The loop ends early on a clean round.

Run each round autonomously except for the single findings-approval checkpoint (Step 5.2.5). Never interrupt with status-check questions.

Step 5.0: Initialize Round Tracking

Create tracking structure:

• all_round_results = [] — each round stores a list of issues, each with:
  • severity (CRITICAL / WARNING / SUGGESTION)
  • file (file path)
  • line (line number or null)
  • description (what's wrong)
  • found_by (agent name or "built-in review")
  • proposed_fix (brief description of the planned change — null until planned in Step 5.2)
  • proposed_fix_by (agent that will apply it — null until planned)
  • fix_description (what changed — null until fixed)
  • fixed_by (agent name or "direct fix" — null until fixed)
• current_round = 1
• max_rounds: set to 3 when fix_agents_available = true, otherwise 1. The review→fix→re-review loop only helps when fixes happen between rounds, so without fix agents one round is all that adds value. The loop still ends early on a clean round (Step 5.1.3).

Step 5.1: REVIEW PHASE

Display: --- Review Round <current_round>/<max_rounds> ---

Step 5.1.1: Agent-Powered Review

If review_agents_available = true:

1. Determine applicable_reviewers by matching changed files to reviewer agents using agent NAME patterns:

   • be-* reviewer → applies when any changed file is under backend/ (excluding backend/src/db/ and backend/src/config/migrate.ts)
   • db-* reviewer → applies when any changed file is under backend/src/db/, backend/src/config/migrate.ts, or backend/src/config/db.ts
   • fe-* reviewer → applies when any changed file is under frontend/
   • ui-* reviewer → applies when any changed file is an .scss file or an Angular template (.html under frontend/)
   • ba-* reviewer → applies when any changed file is under docs/ (PRDs, plans, specs)
   • skill-* reviewer → applies when any changed file is under .claude/
   • If no pattern matches any changed file, include all reviewers as fallback

2. If applicable_reviewers is non-empty:

   • Launch each applicable reviewer agent via Task tool (in parallel - multiple Task calls in one message)
   • Each agent reviews changed files in its domain
   • Collect findings from all agents
   • Tag each finding with found_by = the reviewer agent name that produced it
   • Merge and deduplicate findings by file:line (keep the first agent's attribution)
   • Skip built-in review (Step 5.1.2)

3. If applicable_reviewers is empty:

   • Fall through to built-in review (Step 5.1.2)

For rounds 2+ (current_round > 1): append to every reviewer prompt — "Focus on fix correctness, regressions introduced by the previous round's fixes, and any remaining issues."

If review_agents_available = false:

• Use built-in review checklist below

Step 5.1.2: Built-in Review (fallback when no review agents)

Initialize findings lists:

• Critical issues: []
• Warnings: []
• Suggestions: []

For each changed file:

Read File Content:

Use Read tool to get local file content.

If file too large (>2000 lines), use Grep tool to search for specific patterns.

Apply Code Review Checklist:

Check each item:

Project Alignment:

• Changes align with project goals and requirements from PRD (if exists)
• Changes follow conventions and patterns from CLAUDE.md (if exists)
• Changes match established patterns in this repository

Code Quality:

• Code is simple and readable
• Functions and variables are well-named
• Methods and classes are not too long
• No duplicated code
• Proper error handling
• No exposed secrets or API keys
• Input validation implemented where needed
• Good test coverage
• Uses idiomatic patterns for the project's language
• Tests are concise
• Performance considerations addressed
• Changes match design, best practices, and patterns in this repository
• Code does not violate security best practices

Apply Security Review Checklist:

Apply only items relevant to the file type and project stack. Skip checks that don't apply (e.g., CORS for backend-only code, container security when no Dockerfiles changed).

Check security items relevant to file type and project stack:

• Input validation implements allowlist patterns for all user input, validating both syntax (format, length, type) and semantics (business logic correctness)
• Secrets never hardcoded in source code, Docker ENV/ARG commands, or committed to version control
• Authorization checks implemented at appropriate layers for the project's architecture
• SQL/NoSQL queries use parameterized statements or ORM abstractions, never string concatenation with user input
• Authentication tokens validated with proper signature verification and expiration checks
• CORS configuration uses explicit origin allowlists rather than wildcard (*) permissions
• Error responses return generic messages without exposing stack traces, internal paths, or technology versions
• Logging captures security events but never logs passwords, tokens, session IDs, encryption keys, or PII
• HTTP security headers included where applicable: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options
• Rate limiting configured where applicable with appropriate response codes
• File uploads (if applicable) validate extensions, enforce size limits, and use server-controlled filenames
• Dependencies kept up-to-date with no known CVEs
• Sensitive data never appears in URLs, GET query parameters, or logs
• Container images (if applicable) run as non-root users with minimal privileges
• Service-to-service authentication uses proper token exchange, not passing external tokens directly

Skip items that don't apply to the file under review. A Python utility script doesn't need CORS checks. A frontend component doesn't need container security review.

Step 5.1.3: Record Round Findings

Only record comments that identify actual issues. Encouraging comments ("Nice implementation!") dilute the review. Reviewers identify problems, fixers propose solutions — keeping these roles separate produces sharper reviews and better fixes.

For each issue found, determine severity (internal tracking only):

• CRITICAL: Security vulnerability, data loss risk, breaks core functionality
• WARNING: Poor practice, potential bug, performance issue
• SUGGESTION: Style issue, minor improvement, optimization requiring investigation

Record per issue:

• severity (CRITICAL / WARNING / SUGGESTION)
• file (file path)
• line (line number or null)
• description (use backticks for code identifiers)
• found_by (agent name or "built-in review")
• proposed_fix = null (populated in Step 5.2)
• proposed_fix_by = null (populated in Step 5.2)
• fix_description = null (populated later in Step 5.4)
• fixed_by = null (populated later in Step 5.4)

Store findings for current round in all_round_results[current_round].

Display each issue as found:

  [CRITICAL] path/to/file.kt:28 — `getCurrentUser()` throws NoSuchElementException (found by: be-reviewer)
  [WARNING] path/to/config.kt:15 — CORS allows wildcard origins (found by: be-reviewer)

Then display round summary: Round <current_round>: <count> issues found

If no issues found:

• Display: Round <current_round>: Clean. No issues found.
• Proceed to Step 5.5. A clean round means there is nothing to fix, so the loop ends early — re-reviewing unchanged code adds no value. (This is why a fresh, already-clean branch finishes in one round even when max_rounds = 3.)

If issues found: proceed to Step 5.2.

Step 5.2: FIX PLANNING PHASE

Display: --- Fix Planning (Round <current_round>) ---

If fix_agents_available = true:

1. Determine applicable fixer agents using the same agent NAME patterns as Step 5.1.1:

   • be-* coder → files under backend/ (excluding db/migrate paths)
   • db-* coder → files under backend/src/db/, backend/src/config/migrate.ts, or backend/src/config/db.ts
   • fe-* coder → files under frontend/
   • ui-* designer → .scss files or Angular templates under frontend/
   • skill-* coder → files under .claude/
   • If no pattern matches, use the nearest domain match or all coders as fallback

2. Launch applicable fixer agents via Task tool (in parallel - multiple Task calls in one message)

3. Each agent receives:

   • Findings from current review round relevant to its domain
   • The changed files in its domain
   • Project context (PRD, CLAUDE.md conventions)

4. Each agent produces a fix plan listing per issue:

   • Issue # (reference to the issue index from Step 5.1.3)
   • File and line
   • proposed_fix (brief description of the proposed change)
   • Rationale

5. Collect and merge all fix plans. For each issue, set proposed_fix and proposed_fix_by = the agent that produced the plan.

Display: Fix plans created: <count> fixes proposed

If fix_agents_available = false:

• List issues found as actionable items in review output
• Skip Steps 5.2.5, 5.3, and 5.4
• Proceed to Step 5.5 (single round only when no fixers available)

Step 5.2.5: FINDINGS APPROVAL CHECKPOINT

Skip this checkpoint when no fix agents exist, when this round found zero issues (Step 5.1.3 already exits the loop in that case, so this condition is redundant but kept as a safety guard), or in embedded mode (called from plan-and-do — the caller drives fix approval at its own checkpoint; approve all planned fixes automatically and continue to Step 5.3).

Otherwise (fix agents exist AND findings are present — any severity): Display the full findings table including proposed fixes:

Round <current_round> — Findings & Proposed Fixes

| # | Severity | File | Issue | Found by | Proposed Fix | Fix by |
|---|----------|------|-------|----------|--------------|--------|
| 1 | CRITICAL | path/to/file.ts:28 | description | be-reviewer | proposed fix description | be-coder |
| 2 | WARNING  | path/to/route.ts:15 | description | built-in review | proposed fix description | be-coder |

Then call the AskUserQuestion tool with:

1. Approve all fixes, proceed
2. Approve some, skip others (specify which to skip)
3. Skip all fixes this round (record issues only)

Wait for the user's response.

• Approve all → mark every finding for execution. Continue to Step 5.3.
• Approve some → call the AskUserQuestion tool to ask which issue numbers to skip. For each skipped issue, set proposed_fix = "—", proposed_fix_by = "—". Continue to Step 5.3 with the approved subset only.
• Skip all → clear proposed_fix / proposed_fix_by for all findings (back to null). Skip Steps 5.3 and 5.4. Proceed directly to Step 5.5 (terminate the loop — the user declined fixes this round, so re-reviewing would only re-find the same issues).

This is the one genuine decision point in the review loop — it does not violate User Autonomy, which only forbids status-check interruptions.

Step 5.3: PLAN REVIEW PHASE

Display: --- Plan Review (Round <current_round>) ---

Pass only approved fix plans (findings whose proposed_fix is set and not "—", per Step 5.2.5) to reviewers. Launch reviewer agents with those fix plans via Task tool (in parallel - multiple Task calls in one message).

Each reviewer validates fixes in its domain:

• Fix addresses the identified issue
• Fix does not introduce new problems
• Fix follows project conventions from CLAUDE.md
• Fix aligns with PRD requirements

Collect reviewer feedback.

If reviewers request changes to a fix plan:

• Feed feedback back to the relevant coder/designer agent (one revision iteration max)
• Collect revised plan

Display: Fix plan approved by reviewers

Step 5.4: EXECUTE FIXES PHASE

Display: --- Applying Fixes (Round <current_round>) ---

Only act on approved findings — those whose proposed_fix is set and not "—" (per Step 5.2.5). Leave skipped findings recorded but unfixed (fix_description / fixed_by stay null).

If dry_run_mode = true:

• Display each fix: [DRY-RUN] Would fix: <file>:<line> — <brief description> (by: <agent-name>)
• Display: [DRY-RUN] Round <current_round> fixes simulated: <count> files
• Skip actual file modifications
• Still update each issue's fix_description and fixed_by in all_round_results for the review file

If dry_run_mode = false:

1. Launch coder/designer agents to implement approved fixes via Task tool (in parallel - multiple Task calls in one message)
2. Each agent applies fixes to files in its domain using Edit/Write tools
3. Display each fix applied: Fixed: <file>:<line> — <brief description> (by: <agent-name>)
4. Display: Round <current_round> fixes applied: <count> files modified

After fixes applied (or simulated):

• For each fix, update the corresponding issue in all_round_results[current_round]:
  • Set fix_description = brief description of what changed
  • Set fixed_by = agent name that applied the fix (or "direct fix" if no agents)
• Increment current_round
• If current_round <= max_rounds: go back to Step 5.1 (next review round)
• If current_round > max_rounds: proceed to Step 5.5

Step 5.5: Cycle Summary

Count totals across all rounds:

• Per-round: issues found, fixes planned, fixes applied
• Total issues found across all rounds
• Total fixes applied across all rounds
• Remaining issues (if any)

Store for use in output phases.

---

PHASE 6: WRITE REVIEW FILE

Step 6.1: Determine Output Path

Detect docs folder: check doc then docs, create docs if neither exists.

mkdir -p [docs_folder]/reviews

Filename: REVIEW-<BRANCH-NAME>.md (fallback: REVIEW-YYYY-MM-DD-hh-mm.md if branch name too long).

Get full path (pwd + relative) for clickable terminal output.

Step 6.2: Generate Review Content

Format review as markdown:

# Code Review - <Branch Name>

**Date**: <ISO Date>
**Branch**: <Current Branch>
**Base**: <main_branch — the resolved comparison base: override SHA or main/master>
**Files Reviewed**: <Count>
**Review Rounds**: <rounds actually run> (max <max_rounds>)

## Summary

<Brief overview of changes and review findings across all rounds>

## Review Rounds

<For each round, use one of these two formats:>

<FORMAT A — Round with issues:>

### Round N

**Issues found**: X | **Fixes applied**: Y

| # | Severity | File | Issue | Found by | Proposed Fix | Fix by | Applied | Applied by |
|---|----------|------|-------|----------|--------------|--------|---------|------------|
| 1 | CRITICAL | `path/to/file.ts:28` | `getCurrentUser()` throws on anonymous requests | be-reviewer | Add null-safe fallback for anonymous user | be-coder | Added null-safe `?? null` with anonymous fallback | be-coder |
| 2 | WARNING | `path/to/route.ts:15` | CORS allows wildcard origins | be-reviewer | Restrict to explicit origin allowlist | be-coder | skipped | — |
| 3 | SUGGESTION | `path/to/util.ts:50` | Could extract duplicated validation logic | be-reviewer | — | — | — | — |

<Proposed Fix / Fix by come from Step 5.2 planning; Applied / Applied by from Step 5.4 execution.>
<Use "—" for unfixed or unplanned issues (e.g., suggestions skipped). Use "skipped" in Applied when the user declined the fix at the Step 5.2.5 checkpoint.>
<Use "built-in review" as Found by when no reviewer agents. Use "direct fix" as Applied by when no coder agents.>

<FORMAT B — Clean round (0 issues):>

### Round N

Clean pass. No issues found.

## Remaining Issues

<List of any unresolved issues with file:line references - use backticks for code identifiers>

<If none: "No remaining issues.">

## Project Context Validation

<Results from PRD and CLAUDE.md analysis>

## Next Steps

- Review remaining issues (if any)
- Ensure all tests pass
- Update documentation if needed
- Create PR when ready

---
Generated with Claude Code - review v1.8.2

Step 6.3: Write Review File

Per the RESULTS DISPLAY GUARANTEE, exactly one of the two branches below always runs — normal mode writes the Markdown file, dry-run displays the content on screen. This step never gets skipped, in embedded or stand-alone mode.

If dry_run_mode = true:

• Display: [DRY-RUN] Would write review to: [full_path]
• Display review content
• Skip actual write
• Continue to PHASE 7

If dry_run_mode = false:

• Write content to [docs_folder]/reviews/<FILENAME>
• Verify file written successfully

---

PHASE 7: SUMMARY

Per the RESULTS DISPLAY GUARANTEE, this summary is always printed to screen — in every mode, including embedded. Never skip it.

Output final summary:

Local Review Complete

Branch: <CURRENT> (vs <main_branch — the resolved comparison base: override SHA or main/master>)
Files reviewed: <COUNT>
Review rounds: <rounds actually run> (max <max_rounds>)
Reviewer agents: <list of reviewer agents used, or "None (built-in checklist)">
Fix agents: <list of coder/designer agents used, or "None">

Findings written to: <FULL_PATH>
<In dry-run mode, no file is written — replace the line above with:>
[DRY-RUN] Review displayed above (no file written)

Round summary:
<For each round 1 through max_rounds:>
- Round N: <issues found> issues -> <fixes applied> fixes applied
- Remaining issues: <COUNT>

Next steps:
1. Read review file: <FULL_PATH>
2. Address remaining issues (if any)
3. Run tests
4. Create PR when ready

Use full path (e.g., /Users/dev/project/docs/reviews/REVIEW-add-feature.md) so users can click it in terminal.

STOP - Local review complete.

---

SPECIAL MODES

If help, doctor, or dryrun mode detected: Read review-modes.md (in this skill's directory) and execute the matching section. Then STOP.

---