Review

3. Repair NEEDS CHANGES automatically

When blocking findings remain:

1. Require a clean checkout and a committed review range before automatic repair. If the reviewed implementation includes uncommitted changes, write NEEDS CHANGES and stop rather than letting a worker absorb user-owned work into a commit.
2. Group findings into at most three coherent, dependency-ordered repair tasks. Use IDs REVIEW-FIX-<round>-<n>.
3. Launch one source-writing Pi worker at a time through raw SC. Give it the review path, available plan/todos paths, exact findings, acceptance criteria, and checkout. Require it to read ~/.pi/agent/skills/worker/SKILL.md.
4. Require one focused verified commit per repair task and no push. The worker must leave task-owned files clean after its final verification.
5. Wait and read the same stable worker target. Verify its reported SHA, diff scope, checks, and clean status independently before launching the next worker.
6. Record repair task IDs, commit SHAs, and verification in the review file.
7. Re-run a fresh independent review attempt against the original base through the new HEAD, using new ensemble labels.

Run at most two repair rounds. Stop early and report NEEDS CHANGES when a worker blocks, verification fails, a safety decision requires the user, or blocking findings remain after round two. Do not hide or downgrade unresolved findings to force approval.

4. Finish visibly

Always end with a normal assistant response containing:

• final verdict;
• review-file path;
• reviewed range;
• repair commit SHAs;
• remaining blocking findings or none;
• verification results.

Do not end after only writing or rereading the review file.

The coordinator owns every handover-file write. Do not create a captain protocol, custom state store, worktree, push, PR, merge, or cleanup action.

Delegated Reviewer Contract

When the launch prompt identifies this session as an ensemble reviewer:

• Read the supplied handovers and optional session path directly; treat them as read-only.
• Inspect the assigned diff and trace relevant unchanged logic before judging it.
• Stay within the assigned focus and avoid duplicating another role's scope.
• Run only safe, read-only, focused checks. Do not run a broad suite unless your assigned focus requires it.
• Report only concrete, introduced, actionable issues. Include priority, file/line, impact, and suggested fix.
• Do not edit files, write handovers, commit, push, or launch agents.
• Finish with a concise normal assistant response containing APPROVED or NEEDS CHANGES, followed by findings and evidence. Do not call sc team report; these model-pinned Chat UI reviewers are collected from their stable targets.

Priorities

• P0: production breakage, data loss, or exploitable security flaw.
• P1: likely functional failure or serious foot gun.
• P2: concrete scoped improvement; blocks only when required by acceptance criteria.
• P3: minor polish; never blocks approval.

Review File Format

# Code Review

**Verdict:** APPROVED | NEEDS CHANGES
**Session:** `/absolute/path/to/session.jsonl`
**Plan:** `/absolute/path/to/session.plan.md` | not provided
**Todos:** `/absolute/path/to/session.todos.md` | not provided
**Reviewed commits:** [base..HEAD]
**Repair rounds:** 0 | 1 | 2

## Summary
[Concise evidence-based assessment]

## Verification
- `[command]` — [result]

## Findings
### [P1] [title]
- **File:** `path/to/file:line`
- **Issue:** [specific problem]
- **Impact:** [observable consequence]
- **Suggested fix:** [concrete direction]
- **State:** open | addressed by `<sha>`

## Repair Commits
- `REVIEW-FIX-1-1` — `<sha>` — [summary and verification]

## Independent Reports
- **lead (`openai-codex/gpt-5.6-sol`, high):** [synthesized verdict and evidence]
- **grok (`openrouter/x-ai/grok-4.6`):** [verdict and evidence]
- **kimi (`openrouter/moonshotai/kimi-k3`):** [verdict and evidence]

## Residual Risks
- None | [nonblocking risk]

Omit empty findings or repair sections. Preserve concise attempt and repair evidence when replacing the file with the final verdict.