Menú
Run a code review with Codex. In Codex, use native review behavior; in Claude, invoke the Codex CLI.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
How to invoke the Codex CLI (`codex`) from the shell. Read this BEFORE shelling out to `codex` for any nontrivial task — it covers calling the real binary (not the Superconductor wrapper, which hangs) and capturing output with `-o` so the answer doesn't get buried in the agent-session stream.
Interact with Google Docs & Drive — read, edit, search, comment, share, create docs, list/pull/push content. Use whenever JP wants to read or modify a Google Doc or Drive file (fetch a doc's text, leave a comment, find a file, etc.).
Batch-process Asana tickets — bugs and small / well-specified features — tagged jpa-bugfixes-today into PRs. Spawns a subagent per ticket in parallel worktrees with Codex plan-review and diff-review.
Interact with Asana — tasks, My Tasks, projects, sections, tags, users, workspaces. Use whenever JP wants to read or modify Asana data (look up or edit a task, list My Tasks, comment, find a project, etc.).
Query Better Stack Telemetry logs — errors, warnings, full-text search, request traces, tail, stats. Use whenever JP wants to look at logs or investigate the context around a failure (what happened around an error, logs for a request id, recent errors, etc.).
Interact with Sentry — issues, errors, events, traces, releases, projects, dashboards. Use whenever JP wants to read or modify Sentry data (triage an issue, look up an error, inspect a trace, manage a release, etc.).
| name | review-codex |
| description | Run a code review with Codex. In Codex, use native review behavior; in Claude, invoke the Codex CLI. |
| allowed-tools | ["Bash","Read","Edit","Grep","Glob"] |
Run a Codex review. The implementation depends on which agent is executing this skill:
/review-codex or $review-codex - run review and display output
(pass-through mode)/review-codex collaborative or $review-codex collaborative - run review,
then discuss findings/review-codex fix or $review-codex fix - run review, then fix issues
autonomously/review-codex base main or $review-codex base main - review changes
against a base branch/review-codex mini or $review-codex mini - run the basic review without
the extra standards checklistModes can be combined: /review-codex mini fix base main.
Parse arguments from: $ARGUMENTS in Claude, or the user's prompt after
$review-codex in Codex.
Determine mode:
Spawn two subagents in parallel:
For the first, please ask for a general review, and then the "follow-up" can be run in parallel.
Do not invoke bare codex. Superconductor installs a wrapper at ~/.superconductor/bin/codex (first on PATH) that injects its own MCP server via -c config overrides. That MCP handshake can hang codex review indefinitely when run non-interactively from inside a Superconductor-managed Claude session. Call the real binary directly:
CODEX_BIN="$(which -a codex | grep -v '/.superconductor/' | head -n1)"
Bash state does not persist between your tool calls, so either re-resolve $CODEX_BIN each call or substitute the absolute path (e.g. ~/.nvm/versions/node/v22.16.0/bin/codex) into subsequent commands.
Run the initial review:
"$CODEX_BIN" review [--uncommitted OR --base <branch>]
Skip this step in mini mode.
Resume the session with custom review instructions:
"$CODEX_BIN" exec resume --last "A few things I like to double check with code that my AI coding agent has produced:
1) Types:
a) Are there any type casts that it added. (I often find it doesn't tell me about them like I ask it to.) It's required to at least add a comment explaining them, but I like to review them myself in any case.
b) Are there any weak typings, such as Record<string, string> or similar.
2) We follow a \"Fail fast, fail loud\" philosophy here. I want you to carefully review what the code does when expected information is missing. The classic thing I don't want is \`foo?.bar ?? \"\"\` – that's just hiding the fact that data is missing. I also don't like catching errors without \`recordError\`-ing them or re-throwing.
3) (Pet peeve): when refactoring, it likes to go halfway. \`NEW_VAR = x; OLD_VAR = NEW_VAR; // For backwards compatibility\`. Or similar for re-exporting variables/functions that have moved. It should fix the consumer to use the new name, with the exception of server/client API boundaries.
You may ignore these issues inside test files. When in doubt, tell me about something you're unsure about.
**IMPORTANT**: Do not make any changes. This is only a review."
Pass-through mode: Display the Codex output directly. Do not add commentary, analysis, or suggestions. Just show what Codex said.
Collaborative mode: After showing the Codex output, provide your own analysis. Note agreements, disagreements, or additional concerns Codex may have missed. Offer to help address any issues found.
Fix mode: After reviewing the Codex output, make executive decisions and fix issues autonomously. Use your own judgment on what's worth fixing.
One warning: Your judgment tends to be too lenient on type system issues, fail-fast violations, and backwards-compatibility hacks. When Codex flags these, lean toward fixing them rather than dismissing them.
After fixing, briefly summarize what you changed and why. If you skipped any flagged issues, explain your reasoning.