review-work
A multi-angle post-implementation review that runs five agents in parallel.
review-work is a post-implementation review orchestrator. After meaningful implementation work, it launches five specialized sub-agents in parallel so the work is inspected from complementary angles. The review passes only when all five pass. If any lane fails, the review fails.
The triggers include "review work", "review my work", "review changes", "QA my work", "verify implementation", "check my work", "validate changes", and "post-implementation review".
Five Review Lanes
| # | Lane | Question | Execution in Codex |
|---|---|---|---|
| 1 | Goal and constraint verification | Did we build exactly what was asked? | Self-contained reviewer sub-agent. |
| 2 | QA execution | Does it work on the real surface? | Hands-on QA sub-agent. |
| 3 | Code quality | Is the code consistent and maintainable? | lazycodex-code-reviewer or reviewer sub-agent. |
| 4 | Security | Are there input, auth, secret, or data exposure risks? | Security-focused reviewer sub-agent. |
| 5 | Context mining | Did git history, issues, or nearby context reveal anything missed? | Context-mining sub-agent. |
The original Skill still contains some OpenCode-style examples, but Codex does not call them directly. It sends self-contained role messages through multi_agent_v1.spawn_agent, and uses installed roles such as lazycodex-code-reviewer, lazycodex-qa-executor, or lazycodex-gate-reviewer when available.
How It Works
Phase 0 — Collect Context
First collect the input, mostly from the conversation: original GOAL, CONSTRAINTS, and BACKGROUND. CHANGED_FILES and DIFF come from git. Read the full contents of each changed file, and infer RUN_COMMAND from package.json, Makefile, or docker-compose.yml.
git diff --name-only HEAD~1 # or: git diff --name-only main...HEAD
git diff HEAD~1 # or: git diff main...HEADDo not check out the PR branch in the main worktree. Create a new git worktree with git worktree add and work there.
Phase 1 — Launch All Five Lanes
Launch all five lanes in one turn, each in the background. Do not run them sequentially or wait between launches. The goal verifier checks requirement coverage, the QA executor runs real scenarios, the code reviewer and security auditor review the diff and related files, and the context miner checks git history, GitHub, surrounding context, and code cross-references.
Phase 2 — Wait and Collect
After launching, end the turn. Collect results as agents finish. Do not write the final report until all five have completed.
Phase 3 — Deliver Verdict
If all five return PASS, the result is REVIEW PASSED. If any lane returns FAIL, the result is REVIEW FAILED. The final report includes a table by lane, blocking issues, key findings, and, on failure, exactly what to fix and in what order.
Verdict Logic
- Every agent returns a verdict and confidence level.
- One FAIL makes the entire review fail.
- Timeout, empty response, ack-only, or explicit
BLOCKED:is not PASS. - On failure, findings must name the problem, file, and fix. Vague suggestions such as "improve X" are not enough.
- On success, keep the report short and include only non-blocking suggestions.