# second review prompt
# this prompt is used for the final review pass in phase 4
# focuses on critical/major issues only, uses 2 agents
#
# available variables:
#   {{PLAN_FILE}} - path to the plan file being executed
#   {{PROGRESS_FILE}} - path to the progress log (task execution + previous reviews)
#   {{GOAL}} - human-readable goal description
#   {{DEFAULT_BRANCH}} - default branch name (main, master, trunk, etc.)
#   {{agent:<name>}} - expands to Task tool instructions for the named agent
#
# agents are defined in ~/.config/ralphex/agents/ (user) or pkg/config/defaults/agents/ (builtin)

Second code review pass of: {{GOAL}}

Progress log: {{PROGRESS_FILE}} (contains task execution and previous review iterations)

## Step 1: Get Branch Context

Run both commands to understand what was done:
- `git log {{DEFAULT_BRANCH}}..HEAD --oneline` - see commit history (what was implemented)
- `git diff {{DEFAULT_BRANCH}}...HEAD` - see actual code changes

## Step 2: Launch Review Agents IN PARALLEL

All Task tool calls MUST be in the same message for parallel foreground execution.
Do NOT use run_in_background. Foreground agents run in parallel and block until all complete — no TaskOutput polling needed.

CRITICAL: Do NOT proceed to Step 3 until BOTH agents have returned results.

Agents to launch:
{{agent:quality}}
{{agent:implementation}}

Each agent prompt should be short — do NOT paste the diff into it. Instead, instruct each agent to:
1. Run `git diff {{DEFAULT_BRANCH}}...HEAD` and `git diff --stat {{DEFAULT_BRANCH}}...HEAD` to get the changes
2. Read the actual source files to review code in full context
3. Report problems only - no positive observations

Focus only on critical and major issues. Ignore style/minor issues.

## Step 3: Verify and Evaluate Findings

### 3.1 Verify Each Finding
For each issue reported:
1. Read actual code at file:line
2. Verify issue is real (not false positive)
3. Check if it's truly critical/major severity

### 3.2 Act on Verified Findings

IMPORTANT: Pre-existing issues (linter errors, failed tests) should also be fixed.
Do NOT reject issues just because they existed before this branch - fix them anyway.

SIGNAL LOGIC - READ CAREFULLY:

IMPORTANT: Do not decide on a signal path until you have completed Steps 1-3 in full — all agents finished, all results collected, all findings verified and acted on.

REVIEW_DONE means "this iteration found ZERO issues" - NOT "I finished fixing issues".

Path A - NO issues found in this iteration:
- You reviewed the code and found nothing critical/major to fix
- Output: <<<RALPHEX:REVIEW_DONE>>>

Path B - Issues found AND fixed:
1. Fix verified critical/major issues only
2. Run tests and linter - ALL tests must pass, ALL linter issues resolved
3. Commit fixes: `git commit -m "fix: address code review findings"`
4. STOP HERE. Do NOT output any signal. Do NOT output REVIEW_DONE.
   The external loop will run another review iteration to verify your fixes.
   Your fixes might have introduced new issues - another iteration must check.

Path C - Issues found but cannot fix:
- Output: <<<RALPHEX:TASK_FAILED>>>

OUTPUT FORMAT: No markdown formatting (no **bold**, `code`, # headers). Plain text and - lists are fine.
