name: jb-autoreview description: Use when the user asks for autoreview, Codex/Claude second-model review, or final review of dirty changes, a branch, commit, or PR before ship.
JB Autoreview
Generic structured closeout review for any git repo JB owns or works in.
This is a JB-generic fork of the OpenClaw/Steipete autoreview skill.
- Original URL: https://github.com/openclaw/agent-skills/blob/main/skills/autoreview/SKILL.md
- Upstream repository: https://github.com/openclaw/agent-skills
- Original author/source: Peter Steinberger / OpenClaw
- Fork intent: keep the portable review helper and review discipline, but remove OpenClaw-specific assumptions so the skill can run in any repo.
When asked to check for upstream updates, compare this skill and scripts/autoreview against the original URL/repository above.
Use When
Use this skill when the user asks for:
- autoreview / auto review
- Codex review / Claude review / second-model review
- a final review before commit, merge, publish, or ship
- a review of local dirty changes, a branch, a commit, or a PR branch
- a structured review that should keep running until no accepted/actionable findings remain
This is a review workflow, not an approval gate. Treat output as advisory.
Prerequisites
Required:
git- Python 3
- at least one review engine CLI, usually
codex
Optional:
claudefor Claude reviews or review panelsghfor PR base detectiondroidorcopilotif intentionally using those engines
The helper resolves executables from absolute PATH entries outside the reviewed checkout, and rejects binaries inside the repo. This avoids accidentally running repo-provided fake tools.
Helper Path
From this skill directory:
scripts/autoreview --help
If installed globally, resolve the script path from the skill directory before running it. Do not assume the current repo contains this skill.
Pick Target
Let the helper auto-select when the user just says “autoreview”:
<autoreview-helper> --mode auto
Auto mode chooses:
- dirty worktree → local review
- non-main branch → branch review, using PR base via
gh pr viewwhen available, elseorigin/main - clean
main→ fails with “no review target” because there is no diff to review
Dirty Local Work
Use only for staged/unstaged/untracked work in the current checkout:
<autoreview-helper> --mode local
--mode uncommitted is accepted as an alias.
Branch or PR Work
Use for committed branch work:
<autoreview-helper> --mode branch --base origin/main
If a PR exists, prefer its actual base:
base=$(gh pr view --json baseRefName --jq .baseRefName)
<autoreview-helper> --mode branch --base "origin/$base"
Optional review context is first-class:
<autoreview-helper> --mode branch --base origin/main --prompt-file /tmp/review-notes.md --dataset /tmp/evidence.json
Single Commit
Use for an already committed change or landed commit:
<autoreview-helper> --mode commit --commit HEAD
For small stacks, review each commit explicitly or review the whole branch against its base.
Engines
Codex is the default and usually the best closeout engine:
<autoreview-helper> --engine codex
Claude is available when requested:
<autoreview-helper> --engine claude
Do not silently switch engines or models. If the requested engine hits capacity, retry the same command a few times with the same engine/model.
Parallel Tests
After formatting, it is OK to run focused tests and review in parallel:
<autoreview-helper> --parallel-tests "npm test -- --runInBand"
If tests or review cause code changes, rerun focused tests and rerun autoreview until the helper exits cleanly with no accepted/actionable findings.
Review Panels
Multi-reviewer panels are opt-in only. Use them when explicitly requested or when risk justifies the extra spend:
<autoreview-helper> --panel
<autoreview-helper> --reviewers codex,claude
<autoreview-helper> --reviewers codex:gpt-5.1:high,claude:sonnet:max
Guardrails
- Never blindly apply review output.
- Verify each finding by reading the actual code path and adjacent files.
- Read dependency docs/source/types when a finding depends on external behavior.
- Reject unrealistic edge cases, speculative risks, broad rewrites, and fixes that over-complicate the codebase.
- Prefer small fixes at the right ownership boundary.
- When an accepted finding reveals a repeated bug class, inspect the current review scope for sibling instances.
- Stop at touched surfaces, ownership boundaries, and clear follow-up territory.
- Do not push just to review. Push only when explicitly requested.
- Do not invoke nested reviewers from inside a review.
- Do not run an extra review just to get nicer wording after a clean helper result.
- Security findings should be concrete and actionable, not generic fear around shell/filesystem/network/auth code.
Long-Running Reviews
Structured review can take up to 30 minutes.
Heartbeat lines like this are healthy progress:
review still running: codex elapsed=120s pid=12345
Do not kill the helper just because it has been quiet for 2–5 minutes. Let it continue while heartbeats advance. Use --stream-engine-output only when live engine text is useful.
Review Loop
- Run the helper against the correct target.
- Inspect accepted/actionable findings.
- Verify each finding manually.
- Reject non-issues with a brief explanation.
- Fix accepted issues when in scope.
- Rerun focused tests if fixes changed code.
- Rerun the helper.
- Stop when the helper exits 0 with no accepted/actionable findings.
Final Report
Include:
- exact review command used
- tests/proof run
- findings accepted/rejected, briefly why
- the clean final helper result, or why a remaining finding was consciously rejected
If the final helper run exited 0 and produced no actionable findings, report that exact clean run as the closeout result.