Explore AI Agent Skills & Claude Prompts

star 236

Use when user wants to optimize or tune something measurable through repeated experiments — "make X faster", "improve [metric]", "find best config", "iterate overnight", "run experiments until it hits N". Triggers on quantitative goals (build time, latency, pass rate, accuracy) or qualitative ones scoreable against a rubric (prompt quality, doc parsing). Skip for one-shot bugs with a clear fix or tasks where the user wants direct implementation without exploration.

context

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.

create-rule

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.

guide

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.

history

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

override-rule

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.

pull-remote

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

review

Use when user asks "does this pass review?", "does this file pass our rules", wrapping up feature work before a commit, when a commit got blocked OR rejected by the pre-commit hook (any "[reject]", "commit rejected", "commit being rejected", "why is my commit being rejected", "why is my commit failing", "my commit is being blocked" phrasing), or when debugging a specific rule verdict. Runs the real LLM reviewer. Skip when no `.autoreview/` exists — use autoreview:setup.

setup

Use when the user asks to set up AutoReview in the repo ("setup autoreview", "init autoreview", "initialize autoreview", "bootstrap autoreview", "add autoreview here", "install autoreview") or when `.autoreview/` is missing and the user wants code review. Also triggers when the agent notices no config but rules are being discussed. Skip when `.autoreview/` already exists and the user is not asking for a reset (use autoreview:create-rule instead to add rules).

ratatoskr

Use on every user-facing turn, always — load it before you say anything to any user about this codebase or product. It is a standing discipline for how you communicate, not a tool tied to a particular activity; there is no turn on which you skip loading it. It governs change requests (feature, fix, refactor touching user-visible behavior, account management, data export or deletion, billing, payments, notifications, auth, retention, sharing, compliance like GDPR / PCI / HIPAA) and equally pure questions, explanations, code walkthroughs, and technical/user-visible translations. Plain-language discipline, the no-ceremony / no-machinery-names rule, no time or effort estimates, and question discipline apply on every turn without exception. Load it even when a written spec says implement verbatim, even for a pure internal rename, and even for an already-locked fix — loading is free; the skill itself decides how light to keep the turn, escalating to confirmation gates only when an operation is destructive, irrevers

schedule Updated 20 days ago

precheck

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.

urd

Use when transitioning from a plan, design doc, or spec into implementation - optimize for accuracy over speed and cost; ask the user when confused, when the spec is ambiguous, or when tempted by a hack rather than guessing or working around it