name: override-rule
description: 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.
AutoReview Override-Rule Wizard
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.
Seven steps. Overlays let a repo tune remote (corp-shipped) rules without forking. Changes live in remote_rules[<name>].overrides[<rule-id>] in .autoreview/config.yaml (or config.personal.yaml for personal-scope changes).
Only frontmatter is overridable (name, triggers, tier, severity, type, description). If the user wants to change the rule body, that requires forking the rule into a local copy — explain this and stop.
The 7 steps
Pick remote rule. List rules grouped by source. Show rule ids, names, and current effective tier/severity. Ask user to pick one by id.
Example listing:
corp-standards: corp/audit-log-on-handlers tier: critical severity: error corp/no-todo-without-ticket tier: standard severity: error [manual] vendor-pack: vendor/naming-conventions tier: trivial severity: warningShow effective frontmatter. Read the upstream frontmatter from
.autoreview/remote_rules/<name>/<ref>/<path>/<rule>.mdand merge any existing override from config. Display both the raw upstream values and the currently applied overrides side by side:Field Upstream Current override Effective --- --- --- --- tier critical trivial trivial ←override severity error (none) error type auto manual manual ←override triggers dir:"src" (none) dir:"src"Decide what to change. Ask which field(s) to adjust. Overridable:
tier,triggers,severity,type,description,name. Not overridable: body (explain why and stop if that's what they want).If
triggerschanged — breadth check. Runnode ${CLAUDE_PLUGIN_ROOT}/scripts/bin/check-breadth.mjs --expr '<new-expr>'against the new trigger expression. Zero LLM cost. Iterate until the match set looks right. A trigger that matches 0 files is dead code; a trigger that matches too many files will inflate review cost.If
tierchanged — test-drive. Read.autoreview/config.yamland explain the cost/time tradeoff at the new tier:Tier Typical use Relative cost trivialStyle, naming, simple patterns Cheapest / fastest defaultGeneral conventions Baseline standardCross-cutting concerns, API contracts Moderate heavyArchitectural rules, security invariants Slow / expensive criticalCompliance, audit, zero-tolerance violations Most thorough If the target tier is not defined in the repo's
tiers:config, walk the user through adding it (same as step 5 ofautoreview:create-rule). Then runnode ${CLAUDE_PLUGIN_ROOT}/scripts/bin/reviewer-test.mjs --rule <id> --file <path>against 2–3 sample files at the new tier so the user can see how the new model behaves before committing.Write overlay. Run the save command, choosing scope:
--scope repo→ writes to.autoreview/config.yaml(committed, shared with team).--scope personal→ writes to.autoreview/config.personal.yaml(gitignored, local only).
Ask the user which scope to use if not obvious from context. Get explicit user consent before writing.
node ${CLAUDE_PLUGIN_ROOT}/scripts/bin/override-rule.mjs save \ --remote <source-name> \ --rule <rule-id> \ --field tier=trivial \ --field severity=warning \ [--scope personal]Multiple
--fieldflags are accepted. Field format is<name>=<value>. To explicitly unset an override field (revert to upstream value), pass<name>=null.Confirm + advise. Print the saved overlay block. Suggest next steps:
- Run
autoreview:reviewto verify the overlay applied as expected. - If triggers changed, run
autoreview:context <some-path>to confirm which files now match. - Commit
config.yamlif scope wasrepo.
- Run
What an overlay looks like in config.yaml
remote_rules:
- name: corp-standards
url: https://github.com/acme/autoreview-rules
ref: v1.2.0
path: rules
overrides:
audit-log-on-handlers:
tier: trivial # downgraded from corp's critical
severity: warning # non-blocking in this repo
no-todo-without-ticket:
type: manual # opt-in only; don't run on every commit
Red flags — STOP
| Situation | Action |
|---|---|
| User wants to change the rule body | Explain that body is not overridable. Offer to fork: copy the upstream .md file into .autoreview/rules/ under a local id, then edit freely. |
Rule is local (id has no <source>/ prefix) |
Local rules are owned by the user — edit the file directly. |
| User wants to override a field not in the allowed list | Tell them the allowed fields: name, triggers, tier, severity, type, description. |
| Tier not defined in config | Walk through adding it (step 5) before saving. Don't save an overlay referencing an undefined tier. |