codex-plan-review
Skill12 starsChanged 8 months agoMITView on GitHub
Send a design document to Codex CLI for review, then revise the document based on the findings. Automatically loops until no critical issues remain or 5 rounds are completed.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- Smirnov-Labs/claude-skillstheir own version, first seen Nov 1, 2026
- ultimatile/development-skillstheir own version, first seen Oct 20, 2026
- dgrissen2/persona-review-kittheir own version, first seen Aug 9, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- Smirnov-Labs/claude-skills★ 6same name
- dgrissen2/persona-review-kit★ 0same name
- ultimatile/development-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-testsSkill
- best-practiceSkill
- bootstrapSkill
- briefSkill
- changesSkill
- claude-code-reviewSkill
- claude-plan-reviewSkill
- codex-code-reviewSkill
- commit-pushSkill
- depsSkill
- design-researchSkill
- designSkill
- doc-driftSkill
- doc-syncSkill
- doc-tidySkill
- executeSkill
- explainSkill
- full-briefSkill
- goSkill
- grandmaSkill
- planSkill
- post-design-reviewSkill
- recordSkill
- self-reviewSkill
- tech-researchSkill
- testSkill
- timelineSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
19 rules. 0 are common, 12 are distinctive, and 7 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
12
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
No arguments: pick the target as in step 1
- Distinctive: line 19
If the user specified a file path, use it
- Distinctive: line 21
If no plan file exists either, review the current conversation context — find the most recently discussed design proposal, refactoring …
- Distinctive: line 26
Loops automatically without prompting the user each round: Stop when either is met:
- Very specific: line 33
Run in the background (Bash tool, run_in_background: true):
- Distinctive: line 41
Round 2 onward: If the previous round had findings marked as over-engineered, append a custom prompt with context:
- Very specific: line 47
Read <filename>_review.md and summarize the findings for the user by severity ([Critical], [Moderate], [Suggestion]).
- Distinctive: line 50
Verify every critical and moderate finding with a subagent, not with a quick look of your own.
- Distinctive: line 66
Consolidation: After all subagents return, present each finding's verdict and evidence (citing file paths and key code) to the user.
- Distinctive: line 69
Only fix verified and confirmed issues.
- Very specific: line 77
If this round had [Critical] issues that were confirmed and fixed → automatically start the next round (back to 2a)
- Very specific: line 78
If every [Critical] this round was rejected and nothing was fixed → end the loop and report the rejections with their reasons
- Very specific: line 79
If this round had no [Critical] issues → output "Review passed" and end the loop
- Distinctive: line 80
If 5 rounds have been completed → output final status and end the loop
- Distinctive: line 85
After the review loop ends (for any reason), clean up the gate marker:
- Very specific: line 93
After the review loop ends, recommend the next step, and list every "Needs the user's decision" entry this run added (also in --auto mode.
- Very specific: line 98
--automode: run qq-execute-checkpoint.py pipeline-advance --project . - Distinctive: line 102
Do not change design intent on your own initiative — only fix issues identified by the review
- Distinctive: line 103
When editing, preserve the document's overall structure.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Run qq scripts as
${CLAUDE_PLUGIN_ROOT}/bin/<name>: they are not on PATH, so a bareplan-review.shexits 127.
Respond in the user's preferred language (detect from their recent messages, or fall back to the language setting in CLAUDE.md).
Workflow: take
--workflow <name>from$ARGUMENTSif present, else runqq-config.py field workflow. Onprototype-loop, run one round only and verify the findings yourself (shared/prototype-loop.md§Plan), then hand off to/qq:execute; onheavy-review(the default), follow this file as written.
Arguments: $ARGUMENTS
- A file path to a design document or plan
- No arguments: pick the target as in step 1
Execution Flow
1. Determine the Target File
Try in order of priority:
- If the user specified a file path, use it
- Otherwise check the current conversation for a Claude-generated plan (typically under
Docs/or similar), use the most recent one - If no plan file exists either, review the current conversation context — find the most recently discussed design proposal, refactoring suggestion, or review conclusion, write it as a temporary spec file (
Docs/qq/<branch-name>/tmp-review-spec_<YYYYMMDD-HHmm>.md, timestamped). Get branch name with:git branch --show-current | tr '/' '_' - Last resort: use
ls -t Docs/**/*.md | grep -v '/qq/' | grep -vE '(_review|-review_[^/]*)\.md$' | head -1to find the most recently modified design document (excluding qq-generated artifacts and review reports:<doc>_review.md,<doc>_claude_review.md,codex-code-review_<timestamp>.md, including ones older qq versions left inDocs/<branch>/)
2. Review Loop
Loops automatically without prompting the user each round. Stop when either is met:
- No
[Critical]issues in the Codex review result - 5 rounds have been completed
Each round:
2a. Send to Codex for Review
Run in the background (Bash tool, run_in_background: true):
${CLAUDE_PLUGIN_ROOT}/bin/plan-review.sh <file_path>The script calls codex exec --sandbox read-only and writes results to stdout and <filename>_review.md (same directory as the document).
It always points Codex at the project root's CLAUDE.md and adds a provenance check, even with a custom prompt; don't repeat them in your round-2 prompt.
A review takes 5-10 minutes and you are notified when it finishes; meanwhile you can keep talking with the user.
Round 2 onward: If the previous round had findings marked as over-engineered, append a custom prompt with context:
${CLAUDE_PLUGIN_ROOT}/bin/plan-review.sh <file_path> "Review the updated document using the same review criteria as the first round (architecture, correctness, completeness, feasibility). Additional context: the following suggestions from the previous round were judged as over-engineered and replaced with simpler alternatives: <list items and rationale>. Do not re-suggest more complex approaches unless the simpler version introduces a real defect. Grade by severity: [Critical] [Moderate] [Suggestion]."2b. Read and Summarize Review Results
Read <filename>_review.md and summarize the findings for the user by severity ([Critical], [Moderate], [Suggestion]).
2c. Independent Verification
Verify every critical and moderate finding with a subagent, not with a quick look of your own.
For a Provenance: finding, first check this conversation yourself for the user's words on each item: note the ones you find (quote them into the document in 2d), and send the verifier only the items still unbacked. If that leaves no finding to verify, run the Clean Up Gate command (step 3) before 2d: a gate expecting 0 verifiers blocks Docs/*.md edits.
Dispatch the verifiers with the Agent tool (subagent_type: "general-purpose", model: "opus"). By default hand all of this round's findings to one verifier, which gives a verdict for each; split them into a few groups verified in parallel only when there are too many for one agent to check properly. Each prompt must include the original findings (verbatim), relevant file paths, and the instructions from ../../shared/verification-prompt.md.
The review script leaves a gate: Edit/Write on .cs and Docs/*.md files stays blocked until you write the number of verifiers to it and that many have returned. Write it right after dispatching them:
source "${CLAUDE_PLUGIN_ROOT}/scripts/platform/detect.sh"
if qq_session_id && [[ -f "$QQ_TEMP_DIR/review-gate-$QQ_SESSION_ID" ]]; then
IFS=: read -r ts count _ < "$QQ_TEMP_DIR/review-gate-$QQ_SESSION_ID"
echo "${ts}:${count}:N" > "$QQ_TEMP_DIR/review-gate-$QQ_SESSION_ID"
fi(N = the number of verification subagents dispatched. The gate file is per session; if this session has none, there is nothing to write.)
Consolidation: After all subagents return, present each finding's verdict and evidence (citing file paths and key code) to the user.
2d. Revise the Design Document
- Only fix verified and confirmed issues; skip rejected ones
- For findings marked as Confirmed but over-engineered, fix using the simpler alternative, not Codex's original suggestion
- For each confirmed critical issue, revise the relevant section of the design document
- For confirmed moderate issues, revise as appropriate
- Provenance findings: follow
shared/user-decisions.md. Quote the user's words if they exist; if the user wrote the document themselves, reject the finding; otherwise put the item on the "Needs the user's decision" list and write the body with the normal rule (no protection, no added restriction, a cut item back in scope). Never mark it as your own call. Moved items count as fixed - Present a summary of changes to the user after editing
2e. Decide Whether to Continue
- If this round had
[Critical]issues that were confirmed and fixed → automatically start the next round (back to 2a) - If every
[Critical]this round was rejected and nothing was fixed → end the loop and report the rejections with their reasons - If this round had no
[Critical]issues → output "Review passed" and end the loop - If 5 rounds have been completed → output final status and end the loop
Output === Round N/5 === at the start of each round.
3. Clean Up Gate
After the review loop ends (for any reason), clean up the gate marker:
source "${CLAUDE_PLUGIN_ROOT}/scripts/platform/detect.sh"
if qq_session_id; then rm -f "$QQ_TEMP_DIR/review-gate-$QQ_SESSION_ID"; fiHandoff
After the review loop ends, recommend the next step, and list every "Needs the user's decision" entry this run added (also in --auto mode; don't wait for answers):
- Review passed, plan is solid → "Plan looks good. Want to run
/qq:execute <path>to start implementing?" - Issues were found and fixed → "Plan revised. Want to run
/qq:execute <path>, or another review round?"
--auto mode: run qq-execute-checkpoint.py pipeline-advance --project . --completed-skill "/qq:codex-plan-review" --next-skill "/qq:execute", then invoke /qq:execute <path> --auto.
Notes
plan-review.shneeds a configured Codex CLI.- Do not change design intent on your own initiative — only fix issues identified by the review
- When editing, preserve the document's overall structure; only change what needs to change
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.

