autoreview
starsforks
How to install autoreview?
minghinmatthewlam/agent-guards/autoreview
$npx -y skills add minghinmatthewlam/agent-guards --skill autoreviewRun OpenClaw structured code review as the default closeout check for local changes, branches, commits, and PR work. Uses Codex by default; Claude is optional for explicit second-model review.
SKILL.md
| 1 | # Auto Review |
| 2 | |
| 3 | Run the bundled structured review helper as a closeout check. This is code review, not Guardian `auto_review` approval routing. |
| 4 | |
| 5 | Codex review is the default when no engine is set. It usually delivers the best review results and should remain the normal final closeout engine. |
| 6 | |
| 7 | ## Local Defaults |
| 8 | |
| 9 | - Use this skill, not `codex-review`, for plain "autoreview", "review my changes", and default closeout review requests. |
| 10 | - Run Codex-only review by default. Use Claude only when the user explicitly asks for a second model or a panel. |
| 11 | - Keep upstream web search enabled by default so reviewers can check dependency contracts, upstream docs, current behavior, model names, and security implications. |
| 12 | - Do not force `--model` or `--thinking` unless the user asks or the run needs explicit reproducibility. The user's Codex CLI may already set the desired model/reasoning defaults. |
| 13 | - Ignore Droid and Copilot paths unless the user explicitly asks for those engines. |
| 14 | - Use `--no-web-search` only when the user explicitly requests an offline/local-only review or when network access would be inappropriate for the reviewed material. |
| 15 | |
| 16 | Use when: |
| 17 | |
| 18 | - user asks for Codex review / Claude review / autoreview / second-model review |
| 19 | - after non-trivial code edits, before final/commit/ship |
| 20 | - reviewing a local branch or PR branch after fixes |
| 21 | |
| 22 | ## Contract |
| 23 | |
| 24 | - Treat review output as advisory. Never blindly apply it. |
| 25 | - Verify every finding by reading the real code path and adjacent files. |
| 26 | - Read dependency docs/source/types when the finding depends on external behavior. |
| 27 | - Reject unrealistic edge cases, speculative risks, broad rewrites, and fixes that over-complicate the codebase. |
| 28 | - Prefer small fixes at the right ownership boundary; no refactor unless it clearly improves the bug class. |
| 29 | - Keep going until structured review returns no accepted/actionable findings. |
| 30 | - If a review-triggered fix changes code, rerun focused tests and rerun the structured review helper. |
| 31 | - 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. |
| 32 | - 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. |
| 33 | - 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. |
| 34 | - 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 and Claude filter tool/file chatter, other engines pass raw output through. |
| 35 | - 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. |
| 36 | - 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. |
| 37 | - 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. |
| 38 | - 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. |
| 39 | - 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. |
| 40 | - 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. |
| 41 | - 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. |
| 42 | - Treat the helper's successful exit plus absence of actionable findings as the clean review result, even |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
