add-rule

State the correction as a single "when X, do Y" sentence with the reason, then pick the cheapest mechanical enforcement layer: an existing linter rule, an import-boundary rule, or a custom guard script. Add the matching conventions-doc entry and verify the guard fails on a real violation before committing.

Prefer mechanical enforcement over prose: linter rules for AST patterns, dependency-cruiser or ESLint boundary plugins for import restrictions, and custom guard scripts for regex-checkable conventions. Prose conventions-doc rules are the fallback only when a rule cannot be mechanized.

No. A mechanical guard must be zero-false-positive on the current tree since it runs on every push. If violations exist that cannot be cheaply fixed, either fix them in the same change, narrow the guard's scope, or keep the rule as prose only.

Skip codification for genuine one-offs like typos or single-occurrence preferences with no plausible recurrence. Process preferences about working style belong in cross-session guidance, not lint rules. Only recurring, generalizable code mistakes justify a new enforced rule.

Invoke the skill in sweep mode to scan recent merged PRs, review outputs, and corrections from recent sessions. It proposes a batch of candidate rules for patterns worth codifying, and each proposal still requires your confirmation before anything is written.