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 can be hardened without re-deriving the set.

This is a content skill, not a tool. It provides rules and snippets. For wiring those rules into git hooks, see the hk skill.

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, utilities ← server, UI ← schemas) are enforced with no-restricted-imports / no-restricted-syntax, not 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. Prefer opinionated presets, override minimally. Ultracite for Biome, @commitlint/config-conventional for commits, next/core-web-vitals for Next. Only override with a comment explaining why.
6. The why lives with the rule. Every non-obvious override has an inline comment saying what would break if it were removed.

When to use this skill

• Setting up linting in a new project → pick linters from the table below, copy snippets from references/, wire with the hk skill.
• Hardening an existing project → audit against the rules catalogue, add the missing ones.