원클릭으로 Manus에서 모든 스킬 실행

precheck

스타0

포크0

업데이트2026년 5월 2일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

krzysztofdudek

krzysztofdudek/AutoReview

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.