Mechanical Enforcement

Rules a reviewer would otherwise have to remember belong in a linter. This skill is the curated catalogue of rules, the linters that enforce them, and the rationale for each, so a new project is hardened without re-deriving the set.

A content skill, not a tool: rules and snippets. Wiring them into git hooks is the hk skill's job.

Principles

1. Mechanical over social. If a rule relies on a reviewer remembering it, it will drift. Encode it in a linter, a type, or a test - never in a convention.
2. Types first, lint second, tests third. Prefer strict TypeScript / Pydantic / clippy to a custom lint rule. Reach for a lint rule when the type system can't express it. Reach for a test only when neither can.
3. Architectural boundaries are linter rules. Layers (domain <- infra, UI <- schemas) are enforced with no-restricted-imports or a graph check when the rule is transitive, never trusted to vigilance.
4. Auto-fix where possible, gate where not. Formatters and whitespace fixers run with fix = true and re-stage. Correctness rules gate the commit.
5. Own the rule list where the rules are the point, take a preset where they are not. @commitlint/config-conventional for commits and next/core-web-vitals for Next are presets worth inheriting; the lint set that backs an idiom is a config this catalogue owns, because a preset that silences one of those rules does it silently. Override either only with a comment saying why.
6. The why lives with the rule. Every non-obvious override has an inline comment saying what would break if it were removed.
7. The diagnostic is part of the gate. A rule that says what is banned but not what to use instead costs a correction round - for a reviewer and for an agent. Where the linter takes a custom message, name the replacement and where it lives.

When to use this skill