review-work
Has your agent review completed work, checking quality, security, and goal achievement. It's useful before handing off a project or requesting a review.
What it does
This tool checks if already completed work is good. It looks at the goals, constraints, code quality, security, and if everything was tested correctly.
When to use it
- ✓After finishing programming something and before handing it over to someone else.
- ✓When you want to be sure that the work done meets expectations.
- ✓If someone asks you to review work that has already been finalized.
Example of what to ask your AI
“Review this code that I finished.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
The tool simulates a manual review, checking the important points of the work. It uses a specialized 'reviewer' to ensure everything is correct.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add code-yeongyu/oh-my-openagent --skill review-workOr download just the file:
curl -L https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/packages/shared-skills/skills/review-work/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
Codex Harness Tool Compatibility
This skill may include examples copied from the OpenCode harness. In Codex, do not call OpenCode-only tools such as call_omo_agent(...), task(...), background_output(...), or team_*(...) literally. Translate those examples to Codex native tools:
| OpenCode example | Codex tool to use |
|---|---|
call_omo_agent(subagent_type="explore", ...) |
multi_agent_v1.spawn_agent({"message":"TASK: act as an explorer. ...","agent_type":"explorer","fork_context":false}) |
call_omo_agent(subagent_type="librarian", ...) |
multi_agent_v1.spawn_agent({"message":"TASK: act as a librarian. ...","agent_type":"librarian","fork_context":false}) |
task(subagent_type="plan", ...) |
multi_agent_v1.spawn_agent({"message":"TASK: act as a planning agent. ...","agent_type":"plan","fork_context":false}) |
task(subagent_type="oracle", ...) for final verification |
multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","agent_type":"lazycodex-gate-reviewer","fork_context":false}) |
task(category="...", ...) for implementation or QA |
multi_agent_v1.spawn_agent({"message":"TASK: act as an implementation or QA worker. ...","fork_context":false}) |
background_output(task_id="...") |
multi_agent_v1.wait_agent(...) for mailbox signals |
team_*(...) |
Use Codex native subagents via multi_agent_v1.spawn_agent and multi_agent_v1.wait_agent; use multi_agent_v1.send_input and multi_agent_v1.close_agent only when exposed in the active tools list |
Role-specific behavior must be described in a self-contained message. Use fork_context: false to start the child with only the initial prompt (no parent history); use fork_context: true only when full parent history is truly required. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's message. OMO installs these selectable agent roles into ~/.codex/agents/: explorer, librarian, plan, momus, metis, lazycodex-code-reviewer, lazycodex-qa-executor, and lazycodex-gate-reviewer — pass the matching name as agent_type so the child gets that role's model and instructions. If the spawn tool exposes no agent_type parameter, omit it and describe the role inside message. If a code block below conflicts with this section, this section wins. <!-- retired-name-allowed -->
Codex exposes ONE of two subagent tool surfaces per session; check your own tool list and route accordingly. If multi_agent_v1.* tools exist, use the table above as written. If instead a flat spawn_agent with a required task_name exists (multi_agent_v2), rewrite every multi_agent_v1.* example: multi_agent_v1.spawn_agent({...,"fork_context":false}) becomes spawn_agent({"task_name":"<lowercase_digits_underscores>","message":...,"agent_type":...,"fork_turns":"none"}) ("all" only when full parent history is truly required); send_input becomes send_message; do not call close_agent/resume_agent (finished agents end on their own; followup_task re-tasks one, interrupt_agent stops one); wait_agent takes only timeout_ms and returns on any child mailbox activity. agent_type works the same on both surfaces. If a code block below conflicts with this section, this section wins.
For work likely to exceed one wait cycle, require the child to send WORKING: <task> - <current phase> before long passes and BLOCKED: <reason> only when progress stops. A multi_agent_v1.wait_agent timeout only means no new mailbox update arrived. Treat a running child as alive. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly BLOCKED:, or no longer running.
Codex Subagent Reliability
Every multi_agent_v1.spawn_agent message must be self-contained. Start with
TASK: <imperative assignment>, then name DELIVERABLE, SCOPE, and
VERIFY. State that it is an executable assignment, not a context
handoff. Role or specialty instructions belong inside message.
Use fork_context: false unless full history is truly
required; paste only the review context that worker needs.
Review lanes are leaf agents: a lane does its own reading, running, and
judging inline and never spawns sub-reviewers of its own. Reviewers are
one-shot: a lane ends at its verdict; a re-review after fixes is a fresh
spawn scoped to the delta plus current evidence, never a followup_task
…
FAQ
What is a 'gate reviewer'?
It's a type of specialist the tool uses to ensure the work has passed all important checks before being approved.
Why use only one reviewer?
To get a focused and direct opinion on the work, avoiding the complexity of multiple viewpoints at once.
When should I use this tool?
Whenever you need a final and reliable check of work that has already been implemented.
Details
Original description by the author
Post-implementation gate review: run manual QA on the real surface yourself, then launch ONE gate reviewer (never a panel) to audit goal, constraints, code quality, security, missed context, and QA evidence. Use before a PR handoff or when the user explicitly asks to review completed work.
Popularity
- GitHub stars
- 70k
- Ranking position
- #1744
- License
- NOASSERTION
- Updated
- 10/16/2026
Comments
- …
More skills from this repository
comment-checker
Helps your agent understand and respond to feedback from automatic comment checkers. It's useful when the agent needs to process information from tools that automatically review code or content.
code-yeongyu/oh-my-openagent
lcx-contribute-bug-fix
Helps your agent contribute bug fixes for LazyCodex-related projects. It creates issues or pull requests to ensure code quality.
code-yeongyu/oh-my-openagent
lcx-doctor
Lets your agent check the health of LazyCodex and Codex CLI installations. It's useful when the system behaves oddly after updates or changes.
code-yeongyu/oh-my-openagent
lcx-report-bug
Helps your agent report bugs in detail for LazyCodex projects. It creates issues with useful information for developers to fix the problem.
code-yeongyu/oh-my-openagent
Similar skills
benchmark-optimization-loop
Has your agent improve something's speed in a measured way. It tests multiple versions and chooses the fastest one that still works correctly.
affaan-m/ECC
change-impact
Helps your agent analyze the impact of code changes before making them. It compares the planned vs. actual results afterward, covering paths, data, tests, and documentation. Useful for risky or system-wide changes.
affaan-m/ECC
click-path-audit
Lets your agent trace all user buttons and interactions to find bugs. It finds issues where functions seem to work alone but fail together. Useful when bugs persist even after debugging.
affaan-m/ECC