skills.rest
Joey-Tools
Joey-ToolsOFFICIAL
Explore all skills by this author →
GitHub

review-orchestration-playbook

Orchestrates single, double, and triple code-review lanes plus PR merge readiness gates.

Updated May 18, 2026
Search Tags:#code review#pull request#github#claude code#codex#orchestration#merge readiness
One-click install
npx skills add https://github.com/Joey-Tools/codex-private-workflows --skill review-orchestration-playbook-joey-tools
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-orchestration-playbook
Source: https://github.com/Joey-Tools/codex-private-workflows/tree/main/personal_codex/skills/review-orchestration-playbook
Command: npx skills add https://github.com/Joey-Tools/codex-private-workflows --skill review-orchestration-playbook-joey-tools

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Coordinating multiple independent code reviewers (local Codex, Claude Code, and GitHub Codex) over a frozen commit range is error-prone: scopes drift, evidence gets mixed between lanes, and merge decisions get made on stale heads. This Skill defines a strict orchestration contract so every named review shape runs with frozen Git ranges, isolated workspaces, and auditable evidence before a PR is declared merge-ready. ## Core Features & Use Cases - Named Review Shapes: Runs single (one fresh local Codex lane), double (adds an actual Claude Code lane), or triple (adds current-head GitHub Codex evidence) reviews over a frozen base_sha..head_sha range. - Isolated Lane Execution: Each local lane gets its own clean, detached, read-only Git workspace with pinned toolchain and validated Claude runtime provenance, stream-schema validation, and sandboxed launch profiles. - PR Readiness and Merge Gating: Drives the fix-and-rerun loop across CI, review conversations, and merge policy, binding direct merges and merge-queue enrollment to the exact reviewed head SHA. - Use Case: Before merging a critical pull request, request a triple review to get independent findings from a fresh Codex reviewer, a sandboxed Claude Code reviewer, and GitHub Codex, then loop on fixes until every lane and readiness gate passes on the final head. ## Quick Start Ask the assistant to run a triple review of the current pull request and report whether it is merge-ready.

Frequently Asked Questions about review-orchestration-playbook

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a double code review with Codex and Claude Code?▼

Request a double review and the orchestrator freezes one committed base_sha..head_sha range, runs a fresh local Codex lane, then launches an actual Claude Code process in a second independent validated workspace. Each lane returns its own findings-only result without seeing the other's output.

What is the difference between single, double, and triple review shapes?▼

Single is one fresh-context local Codex lane, double adds one actual Claude Code lane, and triple adds current-head GitHub Codex evidence on an existing GitHub PR. The shapes count logical reviewer lanes, not processes or retries.

Can this review workflow post @codex review comments on GitHub?▼

A bare triple request authorizes at most one scoped @codex review issue-comment POST per repository, PR, and head epoch on an existing supported PR. PR creation, branch mutation, merge, and other repository actions require separate explicit authorization.

Does the Claude Code lane support any Claude version?▼

The lane accepts installed Claude Code releases in the publisher-verified range >=2.1.211,<3.0.0 after provenance, capability, and stream-schema checks pass. The named-direct lane only accepts the guard-validated model claude-opus-4-8 and rejects other caller-selected models.

Why does a code fix invalidate previous review results?▼

Any fix creates a new head commit, which invalidates every old-head positive, pass, or clean result and every head-bound readiness gate. The orchestrator freezes a new range and reruns every lane required by the requested shape before merge.

When is a pull request considered merge-ready by this workflow?▼

A PR is merge-ready only after the effective review shape passes, required CI is green, all review conversations are read with complete pagination, no unresolved blocking finding remains, and a final stable reread confirms the intended base/head relationship. The merge itself must bind the exact reviewed head SHA server-side.

Related Skills

Explore More Software Engineering Skills→
mmnavarrmmnavarr

git-commit-push-pr

Commit, push, and open GitHub pull requests with adaptive value-first descriptions.

Community
Advanced
nebiusnebius
7

merge-pr

Verifies and merges ready GitHub pull requests with head SHA guards and branch protection compliance.

Official
Intermediate
simotasimota
68

Probe

Perform dynamic security testing with OWASP ZAP and Burp Suite.

Community
Advanced
cdxgencdxgen
1.0k

bom-slimmer

Analyzes direct dependencies and suggests lightweight custom replacements using cdxgen SBOM evidence.

Official
Advanced