ESLint Rule Rationalizer

What this skill does

Reads an .eslintrc (legacy) or eslint.config.js (flat) and proposes a cleaned-up config: drop rules that are subsets of extends, drop rules in conflict with Prettier, and regroup the rest by intent. Output is a unified diff and a one-page rationale.

Inputs

• config_path: path to the ESLint config (any of .eslintrc.{js,json,yml}, eslint.config.{js,mjs,ts}).
• repo_dir: repo root (used to resolve extends: targets and run lint).
• Optional prettier_config: path to a Prettier config to detect conflicts.

Steps

1. Run npx eslint --print-config <a-source-file> to dump the fully-resolved config including all extends. Save to /tmp/eslint-resolved.json.
2. Read the explicit rules block from config_path. For each rule, compare its severity and options to the resolved baseline.
3. Drop rules where the explicit setting equals the inherited setting (no-op).
4. Detect Prettier conflicts by intersecting the explicit rule names with the list at eslint-config-prettier's exported set; flag each conflict.
5. Detect deprecated rules by checking each rule against the ESLint metadata: node -e "console.log(Object.keys(require('eslint/use-at-your-own-risk').builtinRules.entries()))".
6. Group survivors by category: errors-and-correctness, imports-and-modules, react, a11y, typescript, style, formatting-deferred-to-prettier.
7. Emit a new config file using flat-config syntax with one object per category, comments explaining the group.
8. Run npx eslint <repo_dir> --config <new_config> to confirm no new errors.
9. Write a unified diff with diff -u <old> <new> and a markdown rationale summary.

Output

Two files: eslint.config.cleaned.mjs (the rewritten config) and eslint-rationale.md (the diff plus a categorized table of dropped rules with reasons). Exit code 0 if the new config passes lint with the same or fewer errors.

Verification

Run npx eslint --print-config against the cleaned config and confirm the resolved set matches the original for non-redundant rules. Lint a representative file with both configs and compare error counts: the cleaned config must produce the same set of error codes (added or removed codes are a regression). If counts diverge, restore the original.

Edge cases

• Config uses dynamic extends (e.g., spread of computed array): skip dynamic branches and warn.
• Plugin rules without metadata (custom plugins): keep them as-is and note them under unknown-plugin group.
• Mixed legacy + flat config in the same repo: process the active one (whichever ESLint resolves) and ignore the other.
• No extends, all explicit: skip the redundancy phase, only run Prettier-conflict and grouping.