autoreview

A pre-commit or pre-release code review workflow that uses Codex by default and can optionally use other supported coding agents. It reviews the complete set of local changes before they are committed or shipped.

In plain words
What is it for?
Use it before committing or shipping non-trivial edits, or when reviewing a local branch or pull request with a selected review engine.
Why use it?
It provides an additional check for defects and risks before changes leave the working branch. Its findings are suggestions that still need to be verified against the real code.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/udecode/plate-template/autoreview
Any agent
npx skills add udecode/plate-template --skill autoreview
Clone the repo
git clone --depth 1 https://github.com/udecode/plate-template

Made for: Claude Code, Codex.

Per session 31 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 6,606 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 100% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00031 $0.06606
Opus 5 $0.00015 $0.03303
Sonnet 5 $0.00006 $0.01321
Haiku 4.5 $0.00003 $0.00661

Measured 3d ago against content hash 45631f438a4c, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

autoreview scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

The scan reads SKILL.md. This mod also ships 4 executable files (scripts/autoreview_test.py, scripts/test-review-harness.ps1, scripts/test-review-harness.py, …), listed below but not scanned — reading those needs a real analyzer, not pattern matching.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

100% identical to autoreview — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

.agents/skills/autoreview/SKILL.md · 359 lines

How it starts

The opening of the file, as written. The whole thing — 359 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Auto Review

Run the bundled structured review helper as a closeout check. This is code review, not Guardian auto_review approval routing.

Codex review is the default when no engine is set. It uses gpt-5.5 by default, usually delivers the best review results, and should remain the normal final closeout engine. Claude review is optional and uses claude-fable-5 by default.

For user-visible behavior, pair autoreview with behavior-validator. Autoreview is source-aware and judges the change bundle; behavior validation is source-blind and judges the running product or tool against a behavior contract. A clean autoreview is not proof that a UI, CLI, API, or generated artifact works from the user's perspective.

Use when:

  • user asks for Codex review / Claude review / Pi review / Droid review / Cursor review / OpenCode review / autoreview / second-model review
  • after non-trivial code edits, before final/commit/ship
  • reviewing a local branch or PR branch after fixes

Contract

  • Treat review output as advisory. Never blindly apply it.
  • Verify every finding by reading the real code path and adjacent files.
  • Read dependency docs/source/types when the 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; no refactor unless it clearly improves the bug class.
  • When an accepted finding shows a bug class or repeated pattern, inspect the current PR scope for sibling instances before fixing.
  • Fix the scoped bug class at once when practical; stop at touched surfaces, owner boundaries, and clear follow-up territory.
  • Keep going until structured review returns no accepted/actionable findings only while the work remains inside the original task scope.
  • If a review-triggered fix changes code, rerun focused tests and rerun the structured review helper.
  • For security-audit suppression changes, verify accepted findings remain auditable: suppressed findings stay in structured output, active output keeps an unsuppressible suppression notice, and aggregate findings cannot hide unrelated active risk.
  • Never switch or override the requested review engine/model. If the review hits model capacity, retry the same command a few times with the same engine/model.
  • Be patient with large bundles. Structured review can take up to 30 minutes while the model call is active, especially with Codex tools or web search.
  • Treat heartbeat lines like review still running: ... elapsed=... pid=... as healthy progress, not a hang. Let the helper continue while heartbeats are advancing. Pass --stream-engine-output when live engine text is useful; Codex, Claude, and Cursor filter tool/file chatter, other engines pass raw output through.
  • Do not kill a review just because it has been quiet for 2-5 minutes, or because it is still running under the 30-minute window. Inspect the process only after missing multiple expected heartbeats, after 30 minutes, or after an obviously failed subprocess; prefer letting the same helper command finish.
  • Tools are useful in review mode. The helper allows read-only inspection tools and web search by default so reviewers can check dependency contracts, upstream docs, and current behavior.
  • Security perspective is always included, but it should not cripple legitimate functionality. Report security findings only when the change creates a concrete, actionable risk or removes an important safety check.
  • For regression provenance, keep roles separate: blamed code author, blamed PR author, PR merger/committer, current PR author, and PR/date. If no blamed PR is traceable, use the blamed commit as the provenance: commit SHA, date, and author username. Do not guess a merger or frame missing PR metadata as a separate finding.
  • If the blamed PR was merged by clawsweeper[bot] or another automation, identify the human trigger when practical. Check timeline/comments first; if rate-limited, use gitcrawl/cache or public PR HTML. Look for maintainer commands such as @clawsweeper automerge, /landpr, or labels/status comments that armed automerge. Report automerge triggered by @login; if not found, say trigger unknown.
  • Do not invoke built-in codex review, nested reviewers, or reviewer panels from inside the review. The helper builds one bundle, calls one selected engine, validates one structured result, and stops.
  • Stop as soon as the helper exits 0 with no accepted/actionable findings. Do not run an extra review just to get a nicer "clean" line, a second opinion, or clearer closeout wording.
  • Treat the helper's successful exit plus absence of actionable findings as the clean review result, even if the underlying Codex CLI output is terse.
  • Multi-reviewer panels are opt-in only. Use them when explicitly requested or when risk justifies the extra spend; the main agent still verifies every accepted finding before fixing.
  • If rejecting a finding as intentional/not worth fixing, add a brief inline code comment only when it explains a real invariant or ownership decision that future reviewers should know.
  • If gh/Gitcrawl reports database disk image is malformed, run gitcrawl doctor --json once to let the portable cache repair before retrying review; do not bypass the shim unless repair fails and freshness requires live GitHub.
  • If Gitcrawl reports a portable manifest mismatch, source/runtime DB health error, or stale portable-store checkout, run gitcrawl doctor --json and inspect source_db_health, runtime_db_health, and portable_store_status before falling back to live GitHub.
  • Do not push just to review. Push only when the user requested push/ship/PR update.

Read the full file on GitHub · 359 lines

Files

What ships with it

6 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 359 lines · 31 tokens per session scan A 45631f438a4c

Subscribe to this mod's changes

autoreview is a skill published in the GitHub repository udecode/plate-template (59 stars, last pushed 2mo ago), licensed MIT. It adds 31 tokens to every session and 6,606 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to autoreview, differing in 0 lines, and is treated as a copy.