codex-coop
Skill2 starsChanged 4 months agoMITView on GitHub
Co-operative workflow with OpenAI Codex CLI for plan review and pre-commit code review. Use this skill whenever Claude is about to present a plan to the user, propose an implementation approach, or commit code changes. Also triggers when the user mentions "codex", "co-op", "second opinion", "review with codex", or asks Claude to validate plans or changes before proceeding. This skill should fire before ANY plan is shown to the user and before ANY git commit — even if the user doesn't explicitly ask for Codex review.
In this repository25 other files it gives its agents.
- brutal-deepresearchSkill
- brutal-grillSkill
- brutal-idea-evalSkill
- brutal-inf-fix-loopSkill
- brutal-planSkill
- brutal-pr-finding-fixerSkill
- brutal-pr-fix-loopSkill
- brutal-project-reviewSkill
- brutal-pr-reviewSkill
- brutal-realitySkill
- brutal-reviewSkill
- brutal-specSkill
- brutal-swarmSkill
- brutal-ticketsSkill
- brutal-wayfinderSkill
- brutal-workerSkill
- design-jepa-modelsSkill
- factory-designSkill
- funcvec-dedupe-fixerSkill
- grill-meSkill
- handoffSkill
- opencode-delegateSkill
- rust-architecture-reviewSkill
- rust-pr-reviewSkill
- supply-chain-analyzerSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Verify availability before first use:
- Very specific: line 21
If codex is not found, inform the user and skip the review steps (proceed normally without Codex review).
- Distinctive: line 41
Read Codex's feedback carefully: Look for:
- Distinctive: line 83
Always run Workflow 1 before presenting a plan: Do not skip this step, even for small plans — a quick "looks good" confirmation from Codex …
- Distinctive: line 85
Be transparent: When presenting to the user, mention that Codex reviewed the work.
- Very specific: line 86
Handle failures gracefully: If the codex command fails, times out, or is unavailable, proceed without it — do not block the user's workflow.
≈ “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
Co-op with Codex
This skill defines a two-agent workflow where Claude collaborates with OpenAI Codex CLI to get a second opinion before presenting plans or committing code. The goal is to catch blind spots, validate approaches, and improve output quality by routing work through an independent reviewer before the human ever sees it.
Prerequisites
codexCLI must be installed and available on PATH- A working OpenAI API key configured for Codex
Verify availability before first use:
which codex && codex --versionIf codex is not found, inform the user and skip the review steps (proceed normally without Codex review).
Workflow 1: Plan Review
When: You have drafted a plan, implementation approach, architecture decision, or multi-step strategy — and are about to present it to the user for review.
Before showing the plan to the user, submit it to Codex for independent review:
codex exec """
review my plan and suggest improvements, flag risks, or confirm it looks good:
<INSERT FULL PLAN HERE>
"""How to handle the response
- Read Codex's feedback carefully. Look for:
- Missed edge cases or failure modes
- Better ordering of steps
- Unnecessary complexity that can be removed
- Missing dependencies or prerequisites
- Alternative approaches worth considering
- Integrate valid suggestions into your plan before presenting it to the user. You do not need to accept everything — use your judgment. Discard feedback that is incorrect, irrelevant, or lower quality than your original approach.
- Present the improved plan to the user. Briefly note that you consulted Codex and incorporated feedback where relevant, so the user has full transparency into the process.
Workflow 2: Pre-Commit Code Review
When: You have made code changes and are about to commit them (or present final changes to the user).
Before committing, ask Codex to review the uncommitted diff:
codex exec """
review the uncommitted changes in this repository. Flag bugs, style issues, missing error handling, or anything that looks off. If everything looks good, confirm.
$(git diff)
$(git diff --cached)
"""How to handle the response
- Review Codex's suggestions against the actual changes.
- Apply fixes for any legitimate issues found (bugs, missing error handling, typos, logic errors).
- Ignore suggestions that are stylistic preferences without substance, incorrect, or would introduce regressions.
- Then proceed with the commit or present the finalized changes to the user.
General Rules
- Always run Workflow 1 before presenting a plan. Do not skip this step, even for small plans — a quick "looks good" confirmation from Codex is still valuable.
- Always run Workflow 2 before committing. This is your last line of defense before code goes in.
- Be transparent. When presenting to the user, mention that Codex reviewed the work. If Codex caught something meaningful, briefly note what changed.
- Handle failures gracefully. If the
codexcommand fails, times out, or is unavailable, proceed without it — do not block the user's workflow. Mention that Codex review was skipped and why. - Don't loop endlessly. One round of Codex review per plan or commit is sufficient. Do not re-submit to Codex after incorporating feedback unless the plan changed substantially.
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.

