review-pr-codex
Skill5 starsChanged 33 days agoMITView on GitHub
Run a requested, read-only cross-model review of a pull request or branch diff using the installed Codex CLI. Use only when the user asks for review-pr-codex or a Codex PR review.
In this repository18 other files it gives its agents.
- closeSkill
- cloudflare-private-static-siteSkill
- code-frictionSkill
- commitSkill
- debate-claudeSkill
- debateSkill
- delegateSkill
- eli5Skill
- email-triageSkill
- friction-triageSkill
- issuesSkill
- m5-delegateSkill
- magnus-security-reviewSkill
- mimir-searchSkill
- presentifySkill
- ship-itSkill
- ticket-fleetSkill
- user-test-memorySkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Keep the review scoped to the selected base/head and the changed files plus directly relevant tests and callers.
- Distinctive: line 25
Before constructing the command, inspect the installed CLI rather than relying on remembered flags:
- Distinctive: line 32
Read references/cli-notes.md for dated, unverified local observations about invocation behavior.
- Very specific: line 36
Create a unique scratch directory with mktemp -d.
- Distinctive: line 38
Use an invocation supported by the help output that is explicitly read-only and ephemeral, for example:
- Distinctive: line 67
Read the complete returned message and distinguish a failed/empty invocation from a clean review.
- Distinctive: line 71
Remove the unique scratch directory after capturing the report unless the user asks to preserve it.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/review-pr-codex — Read-only Codex review
This Claude-facing skill invokes the installed Codex CLI as a separate reviewer. It reports findings for the current user to assess. It never edits files, commits, merges, pushes, posts comments, or silently substitutes another reviewer.
Resolve the review scope
For a PR number, read its base and head with:
gh pr view <number> --json baseRefName,headRefName,title,url- For a branch argument, resolve the branch and its intended base from the repository's PR or remote metadata.
- With no argument, first inspect whether the current branch has an open PR. If it does not, discover the remote default branch from Git rather than assuming
main; stop clearly if no reliable base exists. Confirm that the selected range contains changes.
Keep the review scoped to the selected base/head and the changed files plus directly relevant tests and callers. Do not send unrelated repository content or secrets to another model.
Prepare a read-only invocation
Before constructing the command, inspect the installed CLI rather than relying on remembered flags:
codex exec --help
codex exec review --helpRead references/cli-notes.md for dated, unverified local observations about invocation behavior. They are failure-handling hints, not CLI guarantees.
Create a unique scratch directory with mktemp -d; never use a shared fixed /tmp/codex-pr-review-* path. Store only the selected diff, commit summary, and returned report there. The scratch directory must not contain credentials or unrelated files.
Use an invocation supported by the help output that is explicitly read-only and ephemeral, for example:
set +e
codex exec -s read-only --ephemeral -C <worktree> -o <scratch>/result.md <prompt> \
</dev/null > <scratch>/stdout.log 2> <scratch>/stderr.log
review_exit=$?
set -eRedirect stdin when the prompt is a positional argument. Capture stdout, stderr,
and the exit status separately; inspect all three and treat a non-zero status as a
failed review. Do not assume -o produced a usable file: check that it exists and
is non-empty, and use captured stdout only when it contains the complete returned
report. If there is no complete result, report the invocation failure rather than a
clean review. Do not use workspace-write, danger-full-access, automatic approvals,
or commands that allow the reviewer to alter the repository. A read-only shell
sandbox does not by itself disable MCP, hooks, network access, or other configured
capabilities: inspect the effective configuration and available flags, and narrow
them where supported. Prefer a frozen, supplied diff/commit context with no tools
when the CLI supports that mode. If the installed CLI cannot provide a suitably
scoped review, stop and report the actual limitation.
Respect a model explicitly selected by the user. If no model is selected, use the configured/default model. Do not silently substitute a fallback model. Record the actual runtime model from CLI output or structured events; never infer it from the requested flag alone. If the CLI does not expose it, report that it was not exposed.
The prompt must tell the reviewer to inspect only the selected diff and relevant context, avoid all mutations and external communication, and return findings with severity, file/line, evidence, impact, and a concrete fix. Require it to say explicitly when no grounded findings exist.
Report findings
Read the complete returned message and distinguish a failed/empty invocation from a clean review. Present findings first, ordered by severity, with file and line references. Include residual test gaps and the actual reviewer/model identity when available.
Do not auto-fix or merge based on findings. The review process itself never mutates; code changes or publication require an explicit user request or an already-authorized task that includes them. If Codex is unavailable, report the failure and let the user choose a next step; do not silently replace the cross-model review with a forced multi-agent or self-review.
Remove the unique scratch directory after capturing the report unless the user asks to preserve it.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

