AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Codex Review

skill-benedictking-benedictking-skills-codex-review · by BenedictKing

Use this skill when users ask for code review, review pending changes, or inspect the latest commit with Codex-based review workflows. It prepares context, runs project linting, and reviews the result.

— No reviews yet
0 installs
27 views
0.0% view→install

Install

$ agentstack add skill-benedictking-benedictking-skills-codex-review

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • ✓ Prompt-injection patterns
  • ✓ Secret / credential exfiltration
  • ✓ Dangerous shell & filesystem operations
  • ✓ Untrusted network calls
  • ✓ Known-malicious package signatures

What it can access

  • ✓ Network access No
  • ✓ Filesystem access No
  • ✓ Shell / process execution No
  • ✓ Environment & secrets No
  • ✓ Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-benedictking-benedictking-skills-codex-review)

Reliability & compatibility

✓ Security review passed
0 installs to date
— no reviews yet
● 3mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Codex Review? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Codex Code Review Skill

Trigger Conditions

Triggered when user input contains:

  • "代码审核", "代码审查", "审查代码", "审核代码"
  • "review", "code review", "review code", "codex 审核"
  • "帮我审核", "检查代码", "审一下", "看看代码"

Core Concept: Intention vs Implementation

Running codex review --uncommitted alone only shows AI "what was done (Implementation)". Recording intention first tells AI "what you wanted to do (Intention)".

"Code changes + intention description" as combined input is the most effective way to improve AI code review quality.

Skill Architecture

This skill operates in two phases:

  1. Preparation Phase (current context): Check working directory, update CHANGELOG
  2. Review Phase (isolated context): Invoke Task tool to execute Lint + codex review (using context: fork to reduce context waste)

Execution Steps

0. [First] Check Working Directory Status

git diff --name-only && git status --short

Decide review mode based on output:

  • Has uncommitted changes → Continue with steps 1-4 (normal flow)
  • Clean working directory → Directly invoke codex-runner: codex review --commit HEAD

1. [Mandatory] Check if CHANGELOG is Updated

Before any review, must check if CHANGELOG.md contains description of current changes.

# Check if CHANGELOG.md is in uncommitted changes
git diff --name-only | grep -E "(CHANGELOG|changelog)"

If CHANGELOG is not updated, you must automatically perform the following (don't ask user to do it manually):

  1. Analyze changes: Run git diff --stat and git diff to get complete changes
  2. Auto-generate CHANGELOG entry: Generate compliant entry based on code changes
  3. Write to CHANGELOG.md: Use Edit tool to insert entry at top of [Unreleased] section
  4. Continue review flow: Immediately proceed to next steps after CHANGELOG update

Auto-generated CHANGELOG entry format:

## [Unreleased]

### Added / Changed / Fixed

- Feature description: what problem was solved or what functionality was implemented
- Affected files: main modified files/modules

Example - Auto-generation Flow:

1. Detected CHANGELOG not updated
2. Run git diff --stat, found handlers/responses.go modified (+88 lines)
3. Run git diff to analyze details: added CompactHandler function
4. Auto-generate entry:
   ### Added
   - Added `/v1/responses/compact` endpoint for conversation context compression
   - Supports multi-channel failover and request body size limits
5. Use Edit tool to write to CHANGELOG.md
6. Continue with lint and codex review

2. [Critical] Stage All New Files

Before invoking codex review, must add all new files (untracked files) to git staging area, otherwise codex will report P1 error.

# Check for new files
git status --short | grep "^??"

If there are new files, automatically execute:

# Safely stage all new files (handles empty list and special filenames)
git ls-files --others --exclude-standard -z | while IFS= read -r -d '' f; do git add -- "$f"; done

Explanation:

  • -z uses null character to separate filenames, correctly handles filenames with spaces/newlines
  • while IFS= read -r -d '' reads filenames one by one
  • git add -- "$f" uses -- separator, correctly handles filenames starting with -
  • When no new files exist, loop body doesn't execute, safely skipped
  • This won't stage modified files, only handles new files
  • codex needs files to be tracked by git for proper review

3. Evaluate Task Difficulty and Invoke codex-runner

Count change scale:

# Get summary line for ALL changes (staged + unstaged)
# IMPORTANT: Must use 'HEAD' as base to include both staged and unstaged changes
git diff --stat HEAD | tail -1

Why use git diff --stat HEAD:

  • git diff --stat only shows unstaged changes
  • git diff --cached --stat only shows staged changes
  • git diff --stat HEAD shows BOTH staged and unstaged changes combined
  • The last line (tail -1) is the summary line with total file count and line changes

Difficulty Assessment Criteria:

Model + Reasoning Effort Combinations:

Only recommend gpt-5.5; choose model_reasoning_effort and timeout based on task complexity.

| Combination | Quality | Time | Timeout | Recommended For | |-------------|---------|------|---------|-----------------| | model=gpt-5.5 model_reasoning_effort=xhigh | High | ~8-20 min | 15-40 min | Difficult tasks, critical code, architecture changes | | model=gpt-5.5 model_reasoning_effort=high | Good | ~5-6 min | 10 min | Normal tasks (default) |

Critical Tasks (meets any condition, use highest reasoning effort):

  • Modified files ≥ 30
  • Total code changes (insertions + deletions) ≥ 2000 lines
  • Involves core architecture/algorithm changes (user explicitly mentioned)
  • Config: --config model=gpt-5.5 --config model_reasoning_effort=xhigh, timeout 40 minutes

Difficult Tasks (meets any condition):

  • Modified files ≥ 10
  • Total code changes (insertions + deletions) ≥ 500 lines
  • Single metric: insertions ≥ 300 lines OR deletions ≥ 300 lines
  • Cross-module refactoring
  • Default config: --config model=gpt-5.5 --config model_reasoning_effort=xhigh, timeout 15 minutes

Normal Tasks (other cases):

  • Default config: --config model=gpt-5.5 --config model_reasoning_effort=high, timeout 10 minutes

Evaluation Method:

You MUST parse the git diff --stat HEAD output correctly to determine difficulty:

# Get the summary line (last line of git diff --stat HEAD)
git diff --stat HEAD | tail -1
# Example outputs:
# "20 files changed, 342 insertions(+), 985 deletions(-)"
# "1 file changed, 50 insertions(+)"  # No deletions
# "3 files changed, 120 deletions(-)"  # No insertions

Critical: Why the summary line matters:

  • Each file shows individual stats: file.go | 171 ++++++++++++++++++++-
  • Only the LAST line has the total: 6 files changed, 1341 insertions(+), 18 deletions(-)
  • You must extract the last line with tail -1 to get accurate totals

Parsing Rules:

  1. Extract file count from "X file(s) changed" (handle both "1 file" and "N files")
  2. Extract insertions from "Y insertion(s)(+)" if present (handle both "1 insertion" and "N insertions"), otherwise 0
  3. Extract deletions from "Z deletion(s)(-)" if present (handle both "1 deletion" and "N deletions"), otherwise 0
  4. Calculate total changes = insertions + deletions

Important Edge Cases:

  • Single file: "1 file changed" (singular form)
  • No insertions: Git omits "insertions(+)" entirely → treat as 0
  • No deletions: Git omits "deletions(-)" entirely → treat as 0
  • Pure rename: May show "0 insertions(+), 0 deletions(-)" or omit both

Decision Logic (check in order, first match wins):

  • IF filecount >= 30 OR totalchanges >= 2000 → Critical (gpt-5.5 + xhigh)
  • IF file_count >= 10 → Difficult (gpt-5.5 + xhigh)
  • IF total_changes >= 500 → Difficult (gpt-5.5 + xhigh)
  • IF insertions >= 300 OR deletions >= 300 → Difficult (gpt-5.5 + xhigh)
  • ELSE → Normal (gpt-5.5 + high)

Example Cases:

  • ⭐ "50 files changed, 2000 insertions(+), 1500 deletions(-)" → Critical task, use model=gpt-5.5 model_reasoning_effort=xhigh, timeout 40 minutes (core architecture change)
  • ✅ "20 files changed, 342 insertions(+), 985 deletions(-)" → Difficult task, use model=gpt-5.5 model_reasoning_effort=xhigh, timeout 15 minutes
  • ✅ "5 files changed, 600 insertions(+), 50 deletions(-)" → Difficult task, use model=gpt-5.5 model_reasoning_effort=xhigh, timeout 15 minutes
  • ❌ "3 files changed, 150 insertions(+), 80 deletions(-)" → Normal task, use model=gpt-5.5 model_reasoning_effort=high, timeout 10 minutes
  • ❌ "1 file changed, 50 insertions(+)" → Normal task, use model=gpt-5.5 model_reasoning_effort=high, timeout 10 minutes

Invoke codex-runner Subtask:

Use Task tool to invoke codex-runner, passing complete command (including Lint + codex review):

Task parameters:
- subagent_type: Bash
- description: "Execute Lint and codex review"
- timeout: 2400000 (40 minutes for critical tasks) / 900000 (15 minutes for difficult tasks) / 600000 (10 minutes for normal tasks)
- prompt: Choose corresponding command based on project type and difficulty

Build the prompt as:
   && codex review --uncommitted --config model=gpt-5.5 --config model_reasoning_effort=

Lint command (by project type):
  Go:     go fmt ./... && go vet ./...
  Node:   npm run lint:fix
  Python: black . && ruff check --fix .

Reasoning effort + timeout (by difficulty):
  Critical:  model_reasoning_effort=xhigh, timeout 2400000 (40 min)
  Difficult: model_reasoning_effort=xhigh, timeout 900000  (15 min)
  Normal:    model_reasoning_effort=high,  timeout 600000  (10 min)

Example (Go, Normal):
  go fmt ./... && go vet ./... && codex review --uncommitted --config model=gpt-5.5 --config model_reasoning_effort=high

Clean working directory (review last commit, no lint):
  codex review --commit HEAD --config model=gpt-5.5 --config model_reasoning_effort=high
  (timeout: 600000)

4. Self-Correction and Severity-Driven Fixes

If Codex finds Changelog description inconsistent with code logic:

  • Code error → Fix code
  • Description inaccurate → Update Changelog

If Codex reports P0 / P1 / P2 issues, you must proactively fix them immediately instead of stopping at reporting.

Required behavior:

  1. P0 / P1 / P2 present → directly modify code or related files to fix the issue
  2. After fixing → rerun the necessary lint / validation / review command to confirm the issue is resolved
  3. If rerun still reports any P0 / P1 / P2 → continue fixing and rerunning review in a loop
  4. Only report completion after the rerun review reports no P0 / P1 / P2 issues
  5. Clearly state what was fixed and what verification passed
  6. P3 or lower / suggestion only → may report without automatic modification unless the user explicitly asks for further cleanup

Review loop rule:

  • The workflow is not successful while any P0 / P1 / P2 issue remains
  • After each round of fixes, rerun the appropriate lint / validation / codex review steps
  • Repeat until Codex no longer reports P0 / P1 / P2 issues
  • Only then treat the review as passed and return the final result

Final pass reporting rule:

  • After the final rerun passes, explicitly report that the final review is complete and passed
  • The final result should include:
  • Codex final conclusion (for example: no functional errors, obvious regressions, or merge-blocking defects found)
  • Test results that actually ran in this round
  • Lint / formatting / validation results that actually ran in this round
  • Do not claim checks that were not actually executed
  • Prefer a concise final format similar to:
⏺ Final review complete. Passed.

Result:
- Codex final conclusion: No defects were found that would cause functional errors, obvious regressions, or block merge
- Tests passed: 
- Lint / validation passed: 

Fix priority:

  • P0: Blocker, security, data loss, correctness failure → must fix first
  • P1: High-impact functional or logic bug → must fix
  • P2: Important maintainability / correctness issue with clear fix → should proactively fix in the same run

Constraints:

  • Keep fixes minimal and directly related to the reported issue
  • Do not expand scope into unrelated refactors
  • Preserve existing style and architecture unless the issue requires structural adjustment

Complete Review Protocol

  1. [GATE] Check CHANGELOG - Auto-generate and write if not updated (leverage current context to understand change intention)
  2. [PREPARE] Stage Untracked Files - Add all new files to git staging area (avoid codex P1 error)
  3. [EXEC] Task → Lint + codex review - Invoke Task tool to execute Lint and codex (isolated context, reduce waste)
  4. [FIX LOOP] Severity-Driven Self-Correction - Fix code or update description when intention ≠ implementation; if any P0/P1/P2 appears, keep fixing and rerunning checks until none remain

Codex Review Command Reference

Basic Syntax

codex review [OPTIONS] [PROMPT]

Note: [PROMPT] parameter cannot be used with --uncommitted, --base, or --commit.

Common Options

| Option | Description | Example | | -------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------ | | --uncommitted | Review all uncommitted changes in working directory (staged + unstaged + untracked) | codex review --uncommitted | | --base | Review changes relative to specified base branch | codex review --base main | | --commit | Review changes introduced by specified commit | codex review --commit HEAD | | --title | Optional commit title, displayed in review summary | codex review --uncommitted --title "feat: add JSON parser" | | -c, --config | Override configuration values | codex review --uncommitted -c model="gpt-5.5" |

Usage Examples

# 1. Review all uncommitted changes (most common)
codex review --uncommitted

# 2. Review latest commit
codex review --commit HEAD

# 3. Review specific commit
codex review --commit abc1234

# 4. Review all changes in current branch relative to main
codex review --base main

# 5. Review changes in current branch relative to develop
codex review --base develop

# 6. Review with title (title shown in review summary)
codex review --uncommitted --title "fix: resolve JSON parsing errors"

# 7. Review using the recommended model
codex review --uncommitted -c model="gpt-5.5"

Important Limitations

  • --uncommitted, --base, --commit are mutually exclusive, cannot be used together
  • [PROMPT] parameter is mutually exclusive with the above three options
  • Must be executed in a git repository directory

Important Notes

  • Ensure execution in git repository directory
  • Timeout automatically adjusted based on task difficulty:
  • Critical tasks: 40 minutes (timeout: 2400000)
  • Difficult tasks: 15 minutes (timeout: 900000)
  • Normal tasks: 10 minutes (timeout: 600000)
  • codex command must be properly configured and logged in
  • codex automatically processes in batches for large changes
  • CHANGELOG.md must be in uncommitted changes, otherwise Codex cannot see intention description

Design Rationale

Why separate contexts?

  1. CHANGELOG update needs current context: Understanding user's previous conversation and task intention to generate accurate change description
  2. Codex review doesn't need conversation history: Only needs code changes and CHANGELOG, more efficient to run independently
  3. Reduce token consumption: codex review as independent subtask, doesn't carry irrelevant conversation context

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.