krzysztofdudek
- 14 skills
- 0 followers
- 22 hours ago last updated
- ▌ Grain · krzysztofdudekAsk the repository about its own conventions BEFORE writing code. Use whenever you are about to create a source file, add a class/function/handler/command/component/test, are unsure where something belongs, or want to know how a kind of change has been done here before — `grain where <intent>` names the directory, the group and the exemplar to copy; `grain obligation <path>` names what a new file there has historically had to come with; `grain how <intent>` cites the past commits that did something like it; `grain what <words>` reports what a concept already is here; `grain check <file>` shows where your change departs from the local norm; `grain completeness <file>` names co-changing files before you call a change done; `grain propose` mines a whole proposed Yggdrasil architecture graph for a repository that has none. Statistical answers from this repo's code and full git history; tells you which exemplar to open, never blocks.
- ▌
- ▌
- ▌ Researcher · krzysztofdudekUse 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.
- ▌ Urd · krzysztofdudekUse 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
- ▌ Guide · krzysztofdudekUse 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.
- ▌ Setup · krzysztofdudekUse 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).
- ▌ Review · krzysztofdudekUse 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.
- ▌
- ▌ History · krzysztofdudekUse 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).
- ▌ Precheck · krzysztofdudekUse 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.
- ▌ Create Rule · krzysztofdudekUse 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.
- ▌ Pull Remote · krzysztofdudekUse 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).
- ▌ Override Rule · krzysztofdudekUse 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.