receiving-code-review
Skill0 starsChanged 58 days agoMITView on GitHub
Use whenever Codex (or a human) returns a review verdict. Required to prevent Claude from rubber-stamping or performative-disagreeing. Verify before accepting; articulate disagreement with file/line specifics.
187 other projects use a version of this.
Adopted by
Most recently taken up by
- Binbin-miao/workbuddy-expert-teamtheir own version, first seen Nov 15, 2026
- roronoazoroshao369/vibe-coding-ostheir own version, first seen Nov 15, 2026
- mintunitish/tandemtheir own version, first seen Nov 15, 2026
- theishandubey/dotclaudetheir own version, first seen Nov 15, 2026
- FimawLLC/fimaw-skillstheir own version, first seen Nov 15, 2026
- mdiri-ai/SoduWorktheir own version, first seen Nov 15, 2026
Used with
Projects with it also use chinese-code-review, chinese-commit-conventions and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Leodorareluctant259Skillchinese-code-review
中文代码审查规范——在保持专业严谨的同时，用符合国内团队文化的方式给出有效反馈
Also in 8 projects that use this
- Leodorareluctant259Skill
chinese-commit-conventions
中文 Git 提交规范 — 适配国内团队的 commit message 规范和 changelog 自动化
Also in 8 projects that use this
obraSkilldiagnosing-superpowers
Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.
Also in 20 projects that use this
OpenAISkillrequesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Also in 200 projects that use this
- OpenAISkill
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Also in 154 projects that use this
- +3 more from Leodorareluctant259
- +3 more from openai
Other versions187 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 187
- obra/superpowers★ 314ksame name
- cloudflare/workerd★ 9.2ksame name
- jnMetaCode/superpowers-zh★ 8.4ksame name
- openai/plugins★ 7.8ksame name
- farm-fe/farm★ 5.6ksame name
- microsoft/FluidFramework★ 4.9ksame name
- lingyired/status-trio★ 1.8ksame name
- GanyuanRan/Aegis★ 1.4ksame name
- pcvelz/superpowers★ 1.3ksame name
- DemonDamon/AgenticX★ 1ksame name
177 more not listed
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 repository10 other files it gives its agents.
- app-autopilotSkill
- autopilotSkill
- brainstormingSkill
- doctorSkill
- executionSkill
- honest-reportingSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- writing-plansSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 179 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Read every critique item once for what it says, then once more for what it implies about the code.
- Distinctive: line 17
Before accepting any critique, open the cited file/line and confirm the claim.
- Distinctive: line 22
If the critique is factually wrong, say so with the actual code excerpt.
- Distinctive: line 31
If Codex's reply doesn't engage with your reasoning and just restates the original critique, push back again.
- Very specific: line 50
If you see errors mentioning Cannot find module, proper-lockfile, codex: command not found, codex not authenticated, ENOENT, or any …
“Common” is measured: kept by at least 6 in 10 of the 179 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
Receiving Code Review (Codex-paired)
What this changes vs. upstream
Adds explicit anti-rubber-stamp rules for handling Codex's <<<VERDICT>>> blocks. The discipline applies to all reviewers, but the bar is highest for Codex because Codex is paired with you — agreement matters structurally.
The four rules
1. Read slowly
Read every critique item once for what it says, then once more for what it implies about the code. If you don't fully understand a critique, ask Codex to clarify before responding.
2. Verify against actual code
Before accepting any critique, open the cited file/line and confirm the claim. Critiques can be wrong:
- Wrong file or line.
- Misreading control flow.
- Out-of-date assumption about the codebase.
If the critique is factually wrong, say so with the actual code excerpt. Do not silently accept.
3. Articulate disagreement, don't paper over it
If you disagree:
- Quote the specific critique item.
- Cite the file/line and the actual behavior.
- Explain why the critique is wrong OR why the trade-off Codex objects to is correct in context.
- Say what would change your mind.
If Codex's reply doesn't engage with your reasoning and just restates the original critique, push back again. Two such back-and-forths and the disagreement is "open contention" — record it.
4. No performative anything
- "Good catch, fixing now" without reading the critique = rubber stamp = failure.
- "I disagree" with no specifics = posturing = failure.
- "Let me think about it" with no follow-up = avoidance = failure.
The only acceptable shapes: agree-with-evidence, disagree-with-evidence, request-clarification.
When to escalate
- Same critique survives 3 rounds with neither side conceding → record as open contention, surface to user.
- Codex's verdict block is malformed twice in a row → surface to user with raw output (might be a model regression).
- A critique would change spec scope → push back: "this is a spec change; let's record as open contention and bring to user."
Sidecar logging
Both your verdict and Codex's must be recorded each round (the bridge does this automatically via appendRound). Don't skip rounds. Don't summarize multiple rounds into one.
Troubleshooting setup errors
If you see errors mentioning Cannot find module, proper-lockfile, codex: command not found, codex not authenticated, ENOENT, or any module-load / binary-not-found pattern, invoke /codex-paired-superpowers:doctor first. Resume after green.
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.