Code Review Task Card

Use this explicit opt-in for a merge-readiness review. Shared operating invariants live in templates/AGENTS.md; this card only defines review-specific behavior.

When to use

• The user asks for a code review or quality/security assessment.
• A change is ready for review before merge, or a major feature needs an independent review.
• Do not activate this card for implementation, broad planning, or automatic cleanup.

Inputs

• Scope: the requested files, commit, PR, or whole diff.
• Requirements/specification, acceptance criteria, and relevant test/CI evidence.
• Existing review artifacts and known risks, if any.
• If the user says continue, advance the current verified review step rather than restarting discovery.

Start by recording the scope:

git status --short
git diff --stat
git diff -- <scope>

Execution

1. Identify changed files and review boundaries; do not silently widen the scope.
2. Launch the code-reviewer and architect agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report independent review unavailable; do not substitute the current/authoring lane, and do not approve or mark the review merge-ready.
3. Respect the user's current model and reasoning/effort selection. Do not pass model or reasoning_effort overrides in review-lane calls.

task(
  agent_type="code-reviewer",
  prompt="CODE REVIEW TASK

Review the supplied scope for spec compliance, security, quality, performance, and maintainability.
Return files reviewed, severity-rated findings with file:line evidence and concrete fixes,
and a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.
Scope: [scope and artifacts]"
)

task(
  agent_type="architect",
  prompt="ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK

Review the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,
and the strongest counterargument against approval. Return file:line evidence,
recommendations, and Architectural Status: CLEAR / WATCH / BLOCK.
Scope: [scope and artifacts]"
)

Review taxonomy

• code-reviewer checks Security, Code Quality, Performance, Best Practices, and Maintainability.
• Rate each finding: CRITICAL (security or data-loss blocker), HIGH (bug/major smell), MEDIUM (important improvement), or LOW (style/suggestion).
• architect checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is CLEAR, WATCH (non-blocking concern), or BLOCK (merge blocker).
• Every finding names file:line, issue, risk, and a concrete fix; distinguish facts from suggestions.

State/HUD Phase Contract

• Standalone $code-review relies on hook-owned skill-active-state.json (skill:"code-review", phase:"planning"); do not create code-review-state.json.
• Inside Autopilot, keep mode:"autopilot" active with current_phase:"code-review" / skill-active phase:"code-review"; do not activate a peer workflow.
• On clean review, persist the artifact under Autopilot handoff_artifacts.code_review before moving to ultraqa. On non-clean review, persist findings and use rework or ralplan as appropriate.

omx state write --input '{"mode":"autopilot","active":true,"current_phase":"code-review"}' --json

Final Synthesis and gate

Architectural Status Contract

Combine the code-reviewer recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.

• If architect status is BLOCK, final recommendation is REQUEST CHANGES.
• Else if code-reviewer recommendation is REQUEST CHANGES, final recommendation is REQUEST CHANGES.
• Else if architect status is WATCH, final recommendation is COMMENT.
• Else final recommendation follows the code-reviewer lane.

Approval criteria: APPROVE only when code-reviewer returns APPROVE, architect status is CLEAR, and both independent lanes returned evidence. REQUEST CHANGES for a blocker, unresolved high/critical finding, or unavailable lane. COMMENT may record non-blocking findings.

Do not self-review as a fallback. If the code-reviewer or architect path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the explicit Ralph path, findings may trigger automatic fix follow-up without another permission prompt; plain code-review itself remains read-only and does not promise auto-fix.

Evidence/output contract

Return a concise report containing:

CODE REVIEW REPORT
Files Reviewed: <count>
Total Issues: 0
Architectural Status: CLEAR | WATCH | BLOCK
CRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)
Findings: file:line -> issue, risk, concrete fix (or none)
ARCHITECTURE WATCHLIST: concern, status, recommendation (or none)
- code-reviewer recommendation: COMMENT
- architect status: WATCH
- final recommendation: COMMENT
RECOMMENDATION: COMMENT

Replace the illustrative counts and verdict with observed values. Include scope, lane evidence/artifact references, unresolved risks, and validation gaps.

Exit condition

Stop when the scoped diff has two independent lane results and a deterministic final recommendation. Report APPROVE only under the approval criteria; otherwise leave a bounded REQUEST CHANGES, COMMENT, or unavailable-review result. Never claim merge-ready without the required evidence.