codex-review
installsforks
How to install codex-review?
jezweb/claude-skills/codex-review
$npx -y skills add jezweb/claude-skills --skill codex-reviewRun an independent code review using the OpenAI Codex CLI in headless mode. Gets a second opinion from a different model family (the current Codex models) on recent changes, a PR, a commit, or the whole app — covering bugs, regressions, security, data consistency, UX/state bugs,
SKILL.md
| 1 | # Codex Review |
| 2 | |
| 3 | Run an independent code review via the OpenAI Codex CLI (`codex review`). The value is a second opinion from a **different model family** than the one that wrote the code — Codex catches things Claude misses due to author bias. |
| 4 | |
| 5 | Complements `brains-trust` (generic multi-model opinions). This skill is specialised: git-aware, uses a tuned review prompt, saves structured output. |
| 6 | |
| 7 | ## When to Use |
| 8 | |
| 9 | - After a meaningful change, before committing or shipping |
| 10 | - Before opening a PR, to self-review with an independent reviewer |
| 11 | - When something feels off but you can't articulate what |
| 12 | - Periodic whole-app reviews for projects in active development |
| 13 | - When the user explicitly asks for an "independent" or "second opinion" review |
| 14 | |
| 15 | **Do NOT use** for: |
| 16 | - Trivial changes (typos, one-line fixes) |
| 17 | - Research questions or architecture discussions — use `brains-trust` instead |
| 18 | - Auto-fixing issues — this is advisory only |
| 19 | |
| 20 | ## Preflight |
| 21 | |
| 22 | 1. Confirm Codex CLI is installed: |
| 23 | ```bash |
| 24 | which codex |
| 25 | ``` |
| 26 | If missing: tell the user to install it (`brew install codex` on macOS, or see https://github.com/openai/codex) and stop. Do not continue. |
| 27 | |
| 28 | 2. Confirm auth: the first `codex review` call will fail clearly if not logged in. If that happens, instruct the user to run `codex login` and stop. |
| 29 | |
| 30 | ## Determine scope |
| 31 | |
| 32 | Pick the scope flag based on what the user asked for: |
| 33 | |
| 34 | | User intent | Flag | |
| 35 | |---|---| |
| 36 | | "codex review" / "review the app" / "full review" / default | no flag (reviews whole app at current HEAD) | |
| 37 | | "review my changes" / "review what I just did" / "review uncommitted" | `--uncommitted` | |
| 38 | | "review this branch vs main" / "review the PR" | `--base main` (or the branch they name) | |
| 39 | | "review commit abc123" | `--commit abc123` | |
| 40 | |
| 41 | **Default is whole-app review.** A bare "codex review" with no qualifier means review the entire codebase at HEAD — not just uncommitted changes. Only use `--uncommitted` if the user specifically refers to their recent/uncommitted work. |
| 42 | |
| 43 | If ambiguous, ask once. Don't guess on commits or branches. |
| 44 | |
| 45 | ## Run the review |
| 46 | |
| 47 | The canonical review prompt lives in `prompt.md` next to this skill. Pipe it via stdin to avoid shell escaping: |
| 48 | |
| 49 | ```bash |
| 50 | mkdir -p .jez/reviews |
| 51 | TS=$(date +%Y-%m-%d-%H%M) |
| 52 | OUT=".jez/reviews/codex-${TS}.md" |
| 53 | SKILL_DIR="$(dirname "$0")" # or use the skill's absolute path |
| 54 | |
| 55 | # Example: uncommitted changes |
| 56 | cat "${SKILL_DIR}/prompt.md" | codex review --uncommitted - 2>&1 | tee "$OUT" |
| 57 | ``` |
| 58 | |
| 59 | Other scopes: |
| 60 | |
| 61 | ```bash |
| 62 | # Vs base branch |
| 63 | cat prompt.md | codex review --base main - 2>&1 | tee "$OUT" |
| 64 | |
| 65 | # Specific commit |
| 66 | cat prompt.md | codex review --commit abc123 - 2>&1 | tee "$OUT" |
| 67 | |
| 68 | # Current HEAD (no scope flag) |
| 69 | cat prompt.md | codex review - 2>&1 | tee "$OUT" |
| 70 | ``` |
| 71 | |
| 72 | `codex review` can take several minutes on a large diff. Let it run. |
| 73 | |
| 74 | ## Summarise for the user |
| 75 | |
| 76 | After Codex finishes: |
| 77 | |
| 78 | 1. Print the output path: `Report saved to .jez/reviews/codex-<timestamp>.md` |
| 79 | 2. Read the saved report and extract the top findings (anything under **Critical** and **High**) |
| 80 | 3. Show them inline in the chat, with file:line references intact |
| 81 | 4. Offer to action specific findings: "Want me to fix the SQL injection in `auth.ts:42`?" |
| 82 | |
| 83 | ## Rules |
| 84 | |
| 85 | - **Advisory only.** Never auto-apply Codex's suggestions. Read the findings, discuss with the user, fix with their approval. |
| 86 | - **Don't leak Claude's reasoning into the prompt.** The `prompt.md` file is deliberately neutral — Codex reviews the code, not Claude's narrative about the code. Independence is the whole point. |
| 87 | - **Save to `.jez/reviews/`**, never `.claude/` (protected directory). |
| 88 | - **One report per run.** Don't overwrite — the timestamp makes each run unique so the user can compare. |
| 89 | - **Report what Codex actually found.** Don't soften, editorialise, or skip findings you disagree with. If you think Codex is wrong about something, say so as your own opinion after showing what Codex said. |
| 90 | |
| 91 | ## Verification |
| 92 | |
| 93 | The skill is working if: |
| 94 | - Preflight correctly detects a missing `codex` binary |
| 95 | - The right scope flag is chosen based on user intent |
| 96 | - The report file appears in `.jez/reviews/` with a sensible timestamp |
| 97 | - The file contains severity-prioritised findings with file:line refs |
| 98 | - Claude surfaces the top findings without auto-fixing them |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
