with one click
with one click
Alias for $plan --consensus
[OMX] Strict autonomous loop: $deep-interview -> $ralplan -> $ultragoal (+ $team if needed) -> $code-review -> $ultraqa
Socratic deep interview with mathematical ambiguity gating before execution
N coordinated agents on shared task list using tmux-based orchestration
Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams
Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.
| name | code-review |
| description | Run a comprehensive code review |
Conduct a thorough code review for quality, security, and maintainability with severity-rated feedback.
This skill activates when:
Delegates to the code-reviewer and architect agents in parallel for a two-lane review:
Identify Changes
git diff to find changed filesLaunch Parallel Review Lanes
code-reviewer lane - owns spec compliance, security, code quality, performance, and maintainability findingsarchitect lane - owns the devil's-advocate / design-tradeoff perspectiveindependent review unavailable; do not substitute the current/authoring lane, and do not approve or mark the review merge-ready.Review Categories
Severity Rating
Architectural Status Contract
Specific Recommendations
Final Synthesis
code-reviewer recommendation and the architect status into one final verdictcode-reviewer recommendation is REQUEST CHANGES, final recommendation is REQUEST CHANGEScode-reviewer laneDo not self-review as a fallback. If the code-reviewer or architect agent path is missing, unavailable, skipped, or fails, emit a clear unavailable-review result and block approval until the independent lane evidence exists.
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.
The code-reviewer agent SHOULD consult Codex for cross-validation.
code-reviewer and architect lanesPrefer native code-reviewer agent consultation or CLI-backed ask_codex surfaces when available. Optional MCP compatibility ask tools may be used only when already enabled. If optional external consultation tools are unavailable, continue with the required independent code-reviewer and architect lanes; do not replace those lanes with self-review.
Note: Codex calls can take up to 1 hour. Consider the review timeline before consulting.
CODE REVIEW REPORT
==================
Files Reviewed: 8
Total Issues: 12
Architectural Status: WATCH
CRITICAL (0)
-----------
(none)
HIGH (0)
--------
(none)
MEDIUM (7)
----------
1. src/api/auth.ts:42
Issue: Email normalization logic is duplicated instead of reusing the shared helper
Risk: Validation rules can drift between authentication paths
Fix: Route both paths through the shared normalization helper
2. src/components/UserProfile.tsx:89
Issue: Derived permissions are recalculated on every render
Risk: Avoidable work during profile refreshes
Fix: Memoize the derived permissions list or compute it upstream
3. src/utils/validation.ts:15
Issue: Form-layer and server-layer validation messages are defined separately
Risk: User-facing validation guidance can become inconsistent
Fix: Share one validation message helper across both call sites
LOW (5)
-------
...
ARCHITECTURE WATCHLIST
----------------------
- src/review/orchestrator.ts:88
Concern: Review result synthesis relies on implicit ordering rather than an explicit blocker contract
Status: WATCH
Recommendation: Define deterministic merge gating before expanding reviewers
SYNTHESIS
---------
- code-reviewer recommendation: COMMENT
- architect status: WATCH
- final recommendation: COMMENT
RECOMMENDATION: COMMENT
Address any WATCH concerns before treating the change as merge-ready.
The code-reviewer lane checks:
The architect lane checks:
CLEAR, WATCH, or BLOCKBLOCK concern cites the reason merge-ready status should be withheldAPPROVE - code-reviewer returns APPROVE, architect status is CLEAR, and both independent lanes returned evidence
REQUEST CHANGES - code-reviewer returns REQUEST CHANGES, architect status is BLOCK, or required independent review delegation is unavailable/skipped/failed
COMMENT - code-reviewer returns COMMENT with architect status CLEAR, architect status is WATCH, or only LOW/MEDIUM improvements remain
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.
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
On the explicit Ralph path, review findings should flow into automatic fix follow-up without another permission prompt. Plain code-review itself remains read-only and does not promise auto-fix.
With Ultrawork:
/ultrawork review all files in src/
Parallel code review across multiple files.