Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the review is grounded.
Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.

Delegates to the code-reviewer and architect agents in parallel for a two-lane review:

Identify Changes
- Run git diff to find changed files
- Determine scope of review (specific files or entire PR)
Launch Parallel Review Lanes
- code-reviewer lane - owns spec compliance, security, code quality, performance, and maintainability findings
- architect lane - owns the devil's-advocate / design-tradeoff perspective
- Both lanes run in parallel and produce distinct outputs before final synthesis
Review Categories
- Security - Hardcoded secrets, injection risks, XSS, CSRF
- Code Quality - Function size, complexity, nesting depth
- Performance - Algorithm efficiency, N+1 queries, caching
- Best Practices - Naming, documentation, error handling
- Maintainability - Duplication, coupling, testability
Severity Rating
- CRITICAL - Security vulnerability (must fix before merge)
- HIGH - Bug or major code smell (should fix before merge)
- MEDIUM - Minor issue (fix when possible)
- LOW - Style/suggestion (consider fixing)
Architectural Status Contract
- CLEAR - No unresolved architectural blocker was found
- WATCH - Non-blocking design/tradeoff concern that must appear in the final synthesis
- BLOCK - Unresolved design concern that prevents a merge-ready verdict
Specific Recommendations
- File:line locations for each issue
- Concrete fix suggestions
- Code examples where applicable
Final Synthesis
- Combine the code-reviewer recommendation and the architect status into one final verdict
- Deterministic merge gating rules:
  - 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
- The final report must make architect blockers impossible to miss

Agent Delegation

delegate(
  role="code-reviewer",
  tier="THOROUGH",
  prompt="CODE REVIEW TASK

Review code changes for quality, security, and maintainability.

This is the code/spec/security lane. Do not absorb architectural ownership.

Scope: [git diff or specific files]

Review Checklist:
- Security vulnerabilities (OWASP Top 10)
- Code quality (complexity, duplication)
- Performance issues (N+1, inefficient algorithms)
- Best practices (naming, documentation, error handling)
- Maintainability (coupling, testability)

Output: Code review report with:
- Files reviewed count
- Issues by severity (CRITICAL, HIGH, MEDIUM, LOW)
- Specific file:line locations
- Fix recommendations
- Approval recommendation (APPROVE / REQUEST CHANGES / COMMENT)"
)

delegate(
  role="architect",
  tier="THOROUGH",
  prompt="ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK

Review the same code changes from the architecture/tradeoff perspective.

Scope: [git diff or specific files]

Focus:
- System boundaries and interfaces
- Hidden coupling or long-term maintainability risks
- Tradeoff tension the main reviewer might miss
- Strongest counterargument against approving as-is

Output:
- Architectural Status: CLEAR / WATCH / BLOCK
- File:line evidence for each concern
- Concrete tradeoff or design recommendation"
)

Run both lanes in parallel, then synthesize them with the deterministic rules above.

External Reasoning Cross-Check (Preferred)

The code-reviewer agent SHOULD consult the external reasoning surface for cross-validation. In OMB, that surface is currently exposed through the ask_codex compatibility MCP tool.

Protocol

Form your OWN review FIRST - Complete the review independently
Consult for validation - Cross-check findings with the external reasoning surface
Critically evaluate - Never blindly adopt external findings
Graceful fallback - Never block if tools unavailable

When to Consult

Security-sensitive code changes
Complex architectural patterns
Unfamiliar codebases or languages
High-stakes production code

When to Skip

Simple refactoring
Well-understood patterns
Time-critical reviews
Small, isolated changes

Tool Usage

Before first MCP tool use, call ToolSearch("mcp") to discover deferred MCP tools. Use mcp__x__ask_codex with agent_role: "code-reviewer". If ToolSearch finds no MCP tools, fall back to the code-reviewer agent.

Note: External reasoning calls through the ask_codex compatibility MCP surface can take up to 1 hour. Consider the review timeline before consulting.

Output Format

CODE REVIEW REPORT
==================

Files Reviewed: 8
Total Issues: 15

CRITICAL (0)
-----------
(none)

HIGH (3)
--------
1. src/api/auth.ts:42
   Issue: User input not sanitized before SQL query
   Risk: SQL injection vulnerability
   Fix: Use parameterized queries or ORM

2. src/components/UserProfile.tsx:89
   Issue: Password displayed in plain text in logs
   Risk: Credential exposure
   Fix: Remove password from log statements

3. src/utils/validation.ts:15
   Issue: Email regex allows invalid formats
   Risk: Accepts malformed emails
   Fix: Use proven email validation library

MEDIUM (7)
----------
...

LOW (5)
-------
...

RECOMMENDATION: REQUEST CHANGES

Critical security issues must be addressed before merge.

Review Checklist

The code-reviewer agent checks:

Security

No hardcoded secrets (API keys, passwords, tokens)
All user inputs sanitized
SQL/NoSQL injection prevention
XSS prevention (escaped outputs)
CSRF protection on state-changing operations
Authentication/authorization properly enforced

Code Quality

Functions < 50 lines (guideline)
Cyclomatic complexity < 10
No deeply nested code (> 4 levels)
No duplicate logic (DRY principle)
Clear, descriptive naming

Performance

No N+1 query patterns
Appropriate caching where applicable
Efficient algorithms (avoid O(n²) when O(n) possible)
No unnecessary re-renders (React/Vue)

Best Practices

Error handling present and appropriate
Logging at appropriate levels
Documentation for public APIs
Tests for critical paths
No commented-out code

Approval Criteria

APPROVE - No CRITICAL or HIGH issues, minor improvements only REQUEST CHANGES - CRITICAL or HIGH issues present COMMENT - Only LOW/MEDIUM issues, no blocking concerns

Scenario Examples

Good: The user says continue after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.

Good: The user changes only the output shape or downstream delivery step (for example make a PR). Preserve earlier non-conflicting workflow constraints and apply the update locally.

Bad: The user says continue, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.

Use with Other Skills

With Team:

/team "review recent auth changes and report findings"

Includes coordinated review execution across specialized agents.

With Ralph:

/ralph code-review then fix all issues

Review code, get feedback, fix until approved.

With Ultrawork:

/ultrawork review all files in src/

Parallel code review across multiple files.

Best Practices

Review early - Catch issues before they compound
Review often - Small, frequent reviews better than huge ones
Address CRITICAL/HIGH first - Fix security and bugs immediately
Consider context - Some "issues" may be intentional trade-offs
Learn from reviews - Use feedback to improve coding practices