Run any Skill in Manus with one click

history

Stars0

Forks0

UpdatedMay 2, 2026 at 18:37

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).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

krzysztofdudek

krzysztofdudek/AutoReview

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name

history

description

AutoReview History

Cross-platform. Snippets below use bash-style env-var syntax (${CLAUDE_PLUGIN_ROOT}). Claude Code's Bash tool runs Git Bash on Windows so these work as-is; on native PowerShell substitute $env:CLAUDE_PLUGIN_ROOT, on cmd use %CLAUDE_PLUGIN_ROOT%. Plugin requires Node ≥22 — only assumed binary.

Query the verdict log written by every validate run. Zero LLM cost — purely a read of stored records.

Default — no args

node ${CLAUDE_PLUGIN_ROOT}/scripts/bin/history.mjs

Prints total record count, verdicts grouped by type, by rule, and the 10 most recent records. Good first invocation when the user says "what's been getting rejected lately?".

Common filters

--rule <id> — only records for one rule (e.g. --rule api/validate-input).
--verdict pass|fail|error|suppressed — narrow to a single outcome.
--file '<glob>' — glob filter on file paths (e.g. --file 'src/api/**').
--since YYYY-MM-DD --until YYYY-MM-DD — date range. Either end is optional.
--tier <name> — filter to records where the rule ran on a specific tier (e.g. --tier critical). Useful for auditing what the heavy reviewer is catching.
--severity <error|warning> — filter to records where the rule's severity matches. Useful for --severity warning to review non-blocking findings separately.

Combine freely: --rule auth/no-direct-db --verdict fail --since 2026-04-01 --tier critical.

Output formats

--format table (default) — aggregates + the 10 most recent.
--format json — single JSON object: { total, by_verdict, by_rule, records }. Good for "give me the totals as JSON".
--format jsonl — one record per line, raw. Pipe through jq (POSIX) / parse with node -e "for await (const line of process.stdin) ..." (cross-platform) for custom queries.

Record fields

Each record includes: rule, verdict, reason, provider, model, mode, duration_ms, usage, actor, host, commit_sha, plus two fields added in the tier redesign:

tier — the tier that handled the rule (effective post-overlay).
severity — the rule's severity at run time (effective post-overlay).

Storage layout

History lives at .autoreview/.history/<YYYY-MM-DD>.jsonl (one file per day). Long reason fields spill to sidecar files referenced by reason_sidecar in the record — read those with the Read tool when the inline reason is truncated.

Reporting

Quote the table or relevant records back to the user. For "rejection rate" questions, compute from by_verdict totals. For "which rule fails most" questions, sort by_rule by fail count.

More from this repository

same repository

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

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

precheck

krzysztofdudek/AutoReview

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.

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

history

description

AutoReview History

Cross-platform. Snippets below use bash-style env-var syntax (${CLAUDE_PLUGIN_ROOT}). Claude Code's Bash tool runs Git Bash on Windows so these work as-is; on native PowerShell substitute $env:CLAUDE_PLUGIN_ROOT, on cmd use %CLAUDE_PLUGIN_ROOT%. Plugin requires Node ≥22 — only assumed binary.

Query the verdict log written by every validate run. Zero LLM cost — purely a read of stored records.

Default — no args

node ${CLAUDE_PLUGIN_ROOT}/scripts/bin/history.mjs

Prints total record count, verdicts grouped by type, by rule, and the 10 most recent records. Good first invocation when the user says "what's been getting rejected lately?".

Common filters

--rule <id> — only records for one rule (e.g. --rule api/validate-input).
--verdict pass|fail|error|suppressed — narrow to a single outcome.
--file '<glob>' — glob filter on file paths (e.g. --file 'src/api/**').
--since YYYY-MM-DD --until YYYY-MM-DD — date range. Either end is optional.
--tier <name> — filter to records where the rule ran on a specific tier (e.g. --tier critical). Useful for auditing what the heavy reviewer is catching.
--severity <error|warning> — filter to records where the rule's severity matches. Useful for --severity warning to review non-blocking findings separately.

Combine freely: --rule auth/no-direct-db --verdict fail --since 2026-04-01 --tier critical.

Output formats

--format table (default) — aggregates + the 10 most recent.
--format json — single JSON object: { total, by_verdict, by_rule, records }. Good for "give me the totals as JSON".
--format jsonl — one record per line, raw. Pipe through jq (POSIX) / parse with node -e "for await (const line of process.stdin) ..." (cross-platform) for custom queries.

Record fields

Each record includes: rule, verdict, reason, provider, model, mode, duration_ms, usage, actor, host, commit_sha, plus two fields added in the tier redesign:

tier — the tier that handled the rule (effective post-overlay).
severity — the rule's severity at run time (effective post-overlay).

Storage layout

Reporting

Quote the table or relevant records back to the user. For "rejection rate" questions, compute from by_verdict totals. For "which rule fails most" questions, sort by_rule by fail count.