review
Skill1 starsChanged 34 days agoApache-2.0View on GitHub
Use when Codex should ask Claude CLI for an independent ordinary read-only code review, second-pass review, or sanity check. Trigger on requests such as ask Claude to review, run Claude review, get a Claude pass, use Claude Bridge review, or compare Claude's review against Codex findings.
192 other projects use a version of this.
Adopted by
Most recently taken up by
- microsoft/veronatheir own version, first seen Nov 8, 2026
- microsoft/FluidFrameworktheir own version, first seen Nov 8, 2026
- charliee1w/consolidation-memorytheir own version, first seen Nov 8, 2026
- jisuzzzz/haechitheir own version, first seen Nov 8, 2026
- apokamo/kajitheir own version, first seen Nov 8, 2026
- dirien/yet-another-agent-harnesstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use close-spec, design-with-images and 10 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.
dzhngSkillclose-spec
When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).
Also in 5 projects that use this
dzhngSkilldesign-with-images
Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.
Also in 5 projects that use this
LambenthanSkilldaily-arxiv
每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新
Also in 5 projects that use this
LambenthanSkillexp-eval
实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges
Also in 5 projects that use this
- +3 more from dzhng
- +5 more from Lambenthan
Other versions192 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 192
- garrytan/gstack★ 141ksame name
- ansible/ansible★ 71ksame name
- docling-project/docling★ 70ksame name
- traefik/traefik★ 65ksame name
- ClickHouse/ClickHouse★ 51ksame name
- temporalio/temporal★ 24ksame name
- tisfeng/Easydict★ 15ksame name
- juicedata/juicefs★ 15ksame name
- elie222/inbox-zero★ 13ksame name
- gitkraken/vscode-gitlens★ 10ksame name
182 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 repository4 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- adversarial-reviewSkill
- rescueSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. 0 are common, 11 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 157 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use the local claude executable as an external reviewer.
- Distinctive: line 12
Do not run automatic executable validation or print-mode smoke tests.
- Very specific: line 14
If the user explicitly requests executable validation, setup remains available as an explicit diagnostic command:
- Distinctive: line 26
Do not execute project code or validation commands unless the user explicitly and directly requests that execution.
- Distinctive: line 27
Read-only repository inspection commands required to obtain the requested scope are allowed, including git diff, git status, git show, git …
- Distinctive: line 28
When the scope is current uncommitted work, include staged, unstaged, and untracked files.
- Very specific: line 29
Do not use shell commands for any other purpose, and do not run commands that modify files, the index, refs, configuration, or other …
- Distinctive: line 31
Do not retry, add reviewers, expand the scope, or switch to a deeper model automatically.
- Distinctive: line 32
If the available time or evidence is insufficient, return the supported findings and state the remaining gap.
- Distinctive: line 33
Start with the exact diff or named files in scope and inspect only directly relevant dependencies needed to support a concrete finding.
- Distinctive: line 34
Do not perform repository-wide discovery, recursively follow references, or pursue speculative context.
- Distinctive: line 39
Use Fable 5.1 only when the user explicitly requests Fable.
- Very specific: line 43
Use claude-sonnet-5-5 by default for an ordinary review.
- Very specific: line 44
Use claude-opus-5-5 only when the user explicitly asks for Opus or --deep.
- Distinctive: line 49
Use this shape and preserve the user's scope:
- Distinctive: line 72
Prefer the bundled helper over hand-rolled Claude CLI calls.
- Very specific: line 78
If using this skill from its installed plugin cache, resolve the helper relative to this SKILL.md as ../../scripts/claude-bridge.mjs.
“Common” is measured: kept by at least 6 in 10 of the 157 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
Claude Review
Use the local claude executable as an external reviewer. Treat Claude output as advisory and verify findings against the repository before editing or reporting them as true.
Preflight
Do not run automatic executable validation or print-mode smoke tests. Limit local verification to static file and line inspection.
If the user explicitly requests executable validation, setup remains available as an explicit diagnostic command:
node .\scripts\claude-bridge.mjs setupRuntime Isolation
The helper runs Claude Code with safe mode, no MCP configuration, slash commands disabled, Chrome disabled, and built-in tools limited to Read, Glob, Grep, and Bash. It uses dontAsk permission mode so unavailable actions fail instead of pausing for approval. Organization-managed policy may still apply.
Bounded Execution Policy
Do not execute project code or validation commands unless the user explicitly and directly requests that execution. This includes tests, builds, package managers, scripts, servers, applications, CI, deployment, release, and workflow automation. A review or investigation request alone is not permission to execute them.
Read-only repository inspection commands required to obtain the requested scope are allowed, including git diff, git status, git show, git log, git blame, and git ls-files.
When the scope is current uncommitted work, include staged, unstaged, and untracked files; enumerate them with read-only Git inspection before reviewing only those changes.
Do not use shell commands for any other purpose, and do not run commands that modify files, the index, refs, configuration, or other repository state.
Complete one bounded pass within the helper-selected timeout, including any explicit --timeout override.
Do not retry, add reviewers, expand the scope, or switch to a deeper model automatically.
If the available time or evidence is insufficient, return the supported findings and state the remaining gap.
Start with the exact diff or named files in scope and inspect only directly relevant dependencies needed to support a concrete finding.
Do not perform repository-wide discovery, recursively follow references, or pursue speculative context.
Once a finding has enough static evidence, report it; if evidence remains insufficient, state the uncertainty and remaining gap instead of continuing to investigate.
Executable validation, Opus, --deep, retries, and fixes each require explicit user intent. Do not infer that intent from risk, difficulty, a failed review, or a review request.
Use Fable 5.1 only when the user explicitly requests Fable.
Model Selection
- Use
claude-sonnet-5-5by default for an ordinary review. - Use
claude-opus-5-5only when the user explicitly asks for Opus or--deep. - Normalize shorthand only after the user selects a model:
sonnetandsonnet5.5->claude-sonnet-5-5; explicitsonnet5andsonnet-5->claude-sonnet-5;opusandopus5.5->claude-opus-5-5;fableandfable5.1->claude-fable-5-1; explicitopus5andfable5remain pinned to version 5; explicit legacyopus4.8,opus 4.8, and clearopsu4.8typos ->claude-opus-4-8.
Review Prompt
Use this shape and preserve the user's scope:
You are an independent code reviewer.
Scope: <exact diff, branch, files, or user-provided scope>
Do not edit files.
Do not execute project code or validation commands unless the user explicitly and directly requests that execution. This includes tests, builds, package managers, scripts, servers, applications, CI, deployment, release, and workflow automation. A review or investigation request alone is not permission to execute them.
Read-only repository inspection commands required to obtain the requested scope are allowed, including `git diff`, `git status`, `git show`, `git log`, `git blame`, and `git ls-files`.
Do not use shell commands for any other purpose, and do not run commands that modify files, the index, refs, configuration, or other repository state.
Complete one bounded pass within the helper-selected timeout, including any explicit `--timeout` override.
Do not retry, add reviewers, expand the scope, or switch to a deeper model automatically.
If the available time or evidence is insufficient, return the supported findings and state the remaining gap.
Start with the exact diff or named files in scope and inspect only directly relevant dependencies needed to support a concrete finding.
Do not perform repository-wide discovery, recursively follow references, or pursue speculative context.
Once a finding has enough static evidence, report it; if evidence remains insufficient, state the uncertainty and remaining gap instead of continuing to investigate.
Limit verification to static file and line inspection.
Prioritize correctness bugs, behavioral regressions, security risks, and missing tests.
Return findings first, ordered by severity, with file/line references.
If there are no actionable findings, say that clearly and mention residual test gaps.Preferred Helper
Prefer the bundled helper over hand-rolled Claude CLI calls. From a checked-out plugin source tree, run:
node .\scripts\claude-bridge.mjs review --scope "all current uncommitted changes, including staged, unstaged, and untracked files"If using this skill from its installed plugin cache, resolve the helper relative to this SKILL.md as ../../scripts/claude-bridge.mjs.
Useful options:
--model claude-sonnet-5-5for the default ordinary review model.--deeponly when the user explicitly requests a deeper Opus pass.--timeout <duration>to override the hard limit; the default is15m0s,45m0sfor model names containingopus, or60m0sfor model names containingfable.--scope "<scope>"to preserve the user's exact target.
The helper stores prompt, JSON, markdown, and logs under .codex/claude-bridge/.
Result Handling
Preserve Claude's findings, evidence boundaries, uncertainty notes, and file/line references. Verify claims locally before acting on them. Discard unsupported findings even when they sound plausible. Do not count a failed Claude run as a completed review. After presenting review findings, stop and ask the user which issues, if any, they want fixed before touching files.
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.

