Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

precheck

Étoiles0

Forks0

Mis à jour2 mai 2026 à 18:37

Use when user has drafted file content that is NOT on disk yet and wants a reviewer verdict before writing — explicit phrases like "would this pass review?", "check before I save", "will this be accepted?" with content not yet persisted. Costs 1 LLM call per rule. If the user references an existing file ("does this file pass", "check src/foo.ts") use autoreview:review instead — precheck requires unsaved draft content (pasted, or pointed at via `--content-file`). For plain "I'm about to edit file X", use autoreview:context (free) — don't precheck every edit. Skip when no `.autoreview/` exists — use autoreview:setup first.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

krzysztofdudek

krzysztofdudek/AutoReview

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name

precheck

description

AutoReview Pre-check

Use only when user has a draft in hand and wants a verdict BEFORE writing to disk. For "list rules that apply to this path", use autoreview:context instead — it's free.

Cross-platform. Snippets below use bash-style env-var syntax (${CLAUDE_PLUGIN_ROOT}). Translate to your shell on PowerShell ($env:CLAUDE_PLUGIN_ROOT) or cmd (%CLAUDE_PLUGIN_ROOT%). The plugin requires Node ≥22 — that's the only assumed binary.

When NOT to use

User said "edit this file". Just run autoreview:context to see rules, then write. Precheck is overkill for routine edits.
User is about to commit an already-written file. Use autoreview:review instead.
User already has the content on disk. Use autoreview:review --files <path>.

Steps

Save the draft to a temp file. Resolve the platform tmp dir cross-platform:
```
node -e "console.log(require('os').tmpdir())"
```
Then write the draft into that dir under a unique name (e.g. <tmpdir>/ar-draft-<timestamp>.ts). Any writable path is fine — /tmp/... on POSIX, %TEMP%\... on Windows; the Node call returns the right one for whichever you're on.
Pick a rule that you suspect is the strictest/most relevant for the target path. Use autoreview:context first to list applicable rules.
Run the reviewer test:
```
node ${CLAUDE_PLUGIN_ROOT}/scripts/bin/reviewer-test.mjs \
  --rule <rule-id> --file <target-path> --content-file <tmpdir>/ar-draft-<timestamp>.ts
```
Where <target-path> is the logical destination (e.g. src/api/users.ts) and --content-file is where the draft actually lives. The reviewer automatically resolves the rule's tier from config.yaml — no provider flags needed. To get file:line reasoning, temporarily set tiers.<name>.mode: thinking in .autoreview/config.yaml before running, then revert.
Parse the === RESULT === JSON. If satisfied: false, revise the draft and re-run. If satisfied: true, commit the write to <target-path>.

For multiple rules, run once per rule. Each call is ~1 LLM invocation at the rule's configured tier.

Plus depuis ce dépôt

même dépôt

context

krzysztofdudek/AutoReview

Use when the agent has a concrete file path (about to edit `src/api/users.ts`) and needs the rules that apply to THAT path. Also use with no path to list all rule ids — triggers "what rules does this project have", "list all rules", "which rules exist", "show me the rules". Other triggers: "before I edit X, what rules apply?", a path reference without a review request. Skip when the agent wants an actual verdict (use autoreview:review); skip when no path yet and the user asks an abstract convention question (use autoreview:guide); skip when no `.autoreview/` exists — use autoreview:setup first.

2026-05-020

create-rule

krzysztofdudek/AutoReview

Use when user wants a new code convention rule added, regardless of phrasing — "add a rule", "enforce X", "forbid Y", "write a rule for Z", "create `.autoreview/rules/foo.md` with body ...". Once `.autoreview/` exists, invoke this skill for rule authoring even when the user asks to skip the wizard or specifies the exact file path and body — the wizard guards rule quality. Triggered whenever the user describes a pattern they want checked on every commit. Skip when no `.autoreview/` exists — use autoreview:setup first, then come back here.

2026-05-020

guide

krzysztofdudek/AutoReview

Use when the user asks a free-text question about a convention without a concrete file path ("how do I write a command handler here?", "what's the logging policy?"). The agent needs knowledge retrieval, not a review verdict. Skip when a file path is already known (use autoreview:context); skip when the user actually wants a pass/fail verdict on existing code (use autoreview:review); skip when no `.autoreview/` exists — use autoreview:setup first.

2026-05-020

history

krzysztofdudek/AutoReview

Use when the user asks about review verdicts over time — "what's been getting rejected", "rejection rate this week", "show recent reviews", "history of verdicts", "which rule fails most often", "show suppressed reviews", or filtering reviews by rule / file / date / verdict / tier / severity. Zero LLM cost — pure read of stored review records. Skip when the user wants a FRESH verdict (use autoreview:review) or when no `.autoreview/` exists (use autoreview:setup first).

2026-05-020

override-rule

krzysztofdudek/AutoReview

Use when user wants to adapt a remote rule's tier / triggers / severity / type WITHOUT forking the rule. Wizard for editing config.yaml's `remote_rules[].overrides` block. Triggers include "this corp rule is too noisy in my repo", "downgrade this rule to warning", "narrow this rule to only src/", "make this rule manual-only". Skip when the rule is local — local rules are owned by the user; edit the file directly. Skip when user wants to change rule body — that's a fork, not an overlay.

2026-05-020

pull-remote

krzysztofdudek/AutoReview

Use when the user wants to fetch or refresh remote rules — "pull rules from upstream", "update remote rules", "fetch latest rule version", "sync remote rules" — or right after editing `remote_rules` in `.autoreview/config.yaml`. Also use when a review fails because a referenced remote rule isn't yet on disk. Skip when no `remote_rules` are declared in config (the tool will warn and exit cleanly anyway).

2026-05-020

name

precheck

description

AutoReview Pre-check

Use only when user has a draft in hand and wants a verdict BEFORE writing to disk. For "list rules that apply to this path", use autoreview:context instead — it's free.

Cross-platform. Snippets below use bash-style env-var syntax (${CLAUDE_PLUGIN_ROOT}). Translate to your shell on PowerShell ($env:CLAUDE_PLUGIN_ROOT) or cmd (%CLAUDE_PLUGIN_ROOT%). The plugin requires Node ≥22 — that's the only assumed binary.

When NOT to use

User said "edit this file". Just run autoreview:context to see rules, then write. Precheck is overkill for routine edits.
User is about to commit an already-written file. Use autoreview:review instead.
User already has the content on disk. Use autoreview:review --files <path>.

Steps

Save the draft to a temp file. Resolve the platform tmp dir cross-platform:
```
node -e "console.log(require('os').tmpdir())"
```
Then write the draft into that dir under a unique name (e.g. <tmpdir>/ar-draft-<timestamp>.ts). Any writable path is fine — /tmp/... on POSIX, %TEMP%\... on Windows; the Node call returns the right one for whichever you're on.
Pick a rule that you suspect is the strictest/most relevant for the target path. Use autoreview:context first to list applicable rules.
Run the reviewer test:
```
node ${CLAUDE_PLUGIN_ROOT}/scripts/bin/reviewer-test.mjs \
  --rule <rule-id> --file <target-path> --content-file <tmpdir>/ar-draft-<timestamp>.ts
```
Where <target-path> is the logical destination (e.g. src/api/users.ts) and --content-file is where the draft actually lives. The reviewer automatically resolves the rule's tier from config.yaml — no provider flags needed. To get file:line reasoning, temporarily set tiers.<name>.mode: thinking in .autoreview/config.yaml before running, then revert.
Parse the === RESULT === JSON. If satisfied: false, revise the draft and re-run. If satisfied: true, commit the write to <target-path>.

For multiple rules, run once per rule. Each call is ~1 LLM invocation at the rule's configured tier.