Agent Skills
› omnigent-ai/omnigent
› cross-review
cross-review
GitHub通过调用不同厂商的独立子代理对代码Diff进行交叉审查,先运行确定性门禁(测试/Lint),再根据结构化报告将阻塞性问题转化为修复任务分派给原实现者,循环直至无阻塞问题且门禁通过。
Trigger Scenarios
需要独立于实现者的第三方代码审查
PR合并前的自动化质量验证与缺陷修复闭环
Install
npx skills add omnigent-ai/omnigent --skill cross-review -g -y
SKILL.md
Frontmatter
{
"name": "cross-review",
"description": "Verify an implementer's diff with an INDEPENDENT, different-vendor sub-agent (diff plus contract only); turn blocking issues into fix-tasks and loop until clean."
}
cross-review — independent verification
The implementer never signs off on its own work — a different model does, and review is a sub-agent that returns a structured report, not a transcript anyone needs to read through.
Procedure
- Get the task's diff —
sys_os_shell("gh pr diff <pr>")(orgit -C .worktrees/<task_id> diff main...HEAD). - Run the deterministic gates first — tests / lint / typecheck via
sys_os_shell. If red, re-dispatch the implementer to drive it green first; don't involve the reviewer yet. If a pytest result's count must be recorded or reconciled, collect ground truth withpython -m pytest --collect-only -q <same files>against the exact file set/command/commit the implementer reported. Never usegrep -c 'def test_'as a pytest count: it counts functions, not collected cases, and misses parametrized case expansion. - Dispatch a DIFFERENT-vendor sub-agent as reviewer: pick any AVAILABLE worker
whose vendor differs from the implementer's —
claude_code,codex,opencode,cursor,hermes,agy, orpi(e.g. Claude built it → any ofcodex/opencode/cursor/hermes/agy/pi, and so on). Use a task-based title such asreview-auth-refactor, never the raw vendor name:sys_session_send(agent="claude_code"|"codex"|"opencode"|"cursor"|"hermes"|"agy"|"pi", title="review-<task_slug>", args={purpose: "review", input: "<the diff> + <the acceptance contract>. Review ONLY against the contract. Report blocking / non-blocking / suggestions. Do not edit code."}). Give it the diff as text — do NOT point it at the implementer's worktree. Fetch the diff and emit thesys_session_sendcall in the SAME turn you decide to review — never end a turn having only announced "I'll load cross-review and fetch the diff" with no tool call (that dropped turn stalls the run; nothing dispatches and no inbox wake arrives). Once the reviewer dispatch is in flight, end your turn; collect the inbox-delivered structured report withsys_read_inboxwhen it returns. Usesys_session_get_historyonly to debug an empty or unclear review result. - The reviewer SURFACES issues; it does not fix them.
- For each blocking issue: add a fix-task to the registry scoped to the
same worktree, and send the concrete fixes back to the SAME implementer
conversation via
sys_session_send— reuse the original implementer'sagent+title(or address it bysession_id) withpurpose: "implement", so the worker keeps its worktree/branch context and updates its existing PR. A new title would spawn a fresh worker with no memory of the task. Then loop to step 1. - When gates are green AND there are zero blocking issues, the PR passes review — mark it ready in the registry (with its PR URL) and leave it for the human to merge. polly does NOT merge it.
- If the contract can't be satisfied after a few loops, stop and escalate to the user with specifics.
Notes
- Cross-review requires a reviewer from a DIFFERENT vendor than the implementer, so it needs at least two AVAILABLE workers (per polly's roster preflight). If only one worker — or only one vendor that can review this implementer's PR — is available on the machine, you CANNOT run independent cross-vendor review: don't dispatch a reviewer that can't boot, say so explicitly, and pull in the human at the plan gate.
- Give the reviewer ONLY the diff + contract — never the implementer's transcript or worktree. The cross-vendor independence is the whole point.
- Review is a coding sub-agent (
claude_code/codex/opencode/cursor/hermes/agy/pi) dispatched withpurpose: "review"— a DIFFERENT vendor from the one that built the diff. It reports issues and never edits; only the implementer opens a PR, so a stray reviewer edit never reaches the deliverable. - Non-blocking issues / suggestions go in the registry as follow-ups; they don't block the PR.
Version History
- a8f41cb Current 2026-08-12 09:03


