Skip to content
Skillpedia
General coding70k · #1744

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

https://github.com/code-yeongyu/oh-my-openagent/blob/dev/packages/shared-skills/skills/review-work/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/code-yeongyu/oh-my-openagent/blob/dev/packages/shared-skills/skills/review-work/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
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-work

Or 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.md
Technical 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.

repo: code-yeongyu/oh-my-openagent

Popularity

GitHub stars
70k
Ranking position
#1744
License
NOASSERTION
Updated
10/16/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills