Suppression Audit

Suppression Audit

Audit all code quality suppressions and lint config rule changes across the repository. For each suppression, determine whether a simple fix resolves the underlying issue or the suppression is genuinely needed. Fix unjustified suppressions, verify checks pass, and create a PR.

Suppression Types

Process

Step 1: Detect Check Commands

Run node ${CLAUDE_PLUGIN_ROOT}/scripts/detect-check-scripts.mjs (optionally pass a project dir as arg) to discover available check scripts. It prints KEY=value pairs (e.g. CHECK_ALL=..., TYPECHECK=..., LINT=..., FORMAT=..., TEST=..., TEST_E2E=..., plus _DIR companions and MONOREPO=true when applicable). Parse these and store the resulting command plan for Step 5.

Step 2: Scan for All Suppressions

Spawn an Explore sub-agent (breadth: very thorough, no model param) to find every suppression comment in source files (exclude node_modules, dist, .svelte-kit, lock files). For each match, have it record:

• File path and line number
• Suppression type and rule name
• Surrounding code context (3 lines before/after)

Step 3: Scan Config Files

Spawn an Explore sub-agent (breadth: medium, no model param) to find and read all lint config files (eslint.config.*, .eslintrc.*, .oxlintrc.*, oxlint.json). Have it, for each:

1. List every rule explicitly set to "off", "warn", or 0
2. Check git history for recent changes (last 2 weeks): git log --since="2 weeks ago" -p -- <config-file>
3. Flag any rule that was downgraded (error→warn) or removed recently

Step 4: Evaluate Each Suppression

For each suppression found in Steps 2-3, classify it:

REMOVE — suppression is unjustified, a straightforward fix exists:

• Rule violation is easy to fix (rename, restructure, add type)
• Suppression was added as a shortcut instead of fixing the issue
• The suppressed rule no longer triggers (code changed since suppression was added)

KEEP — suppression is justified:

• Framework/library limitation requires it (e.g., Svelte a11y for intentionally non-standard interactions)
• Fix would require major refactoring disproportionate to the benefit
• Rule is genuinely wrong for the context (e.g., no-undef disabled globally in TypeScript projects)
• Test files where the suppressed pattern is the thing being tested

UPGRADE — warning should be an error:

• Config recently downgraded a rule from error to warn without clear reason
• Rule removal weakens quality gates

Log the evaluation as a table (printed to the user) and immediately proceed to fixes:

| # | File | Type | Rule | Verdict | Reason |
|---|------|------|------|---------|--------|

Step 5: Fix Suppressions

Automatically fix every suppression marked REMOVE or UPGRADE — no confirmation needed.

For each fix:

1. Remove the suppression comment
2. Fix the underlying code issue
3. Run the fast check command (pre-commit tier) to catch regressions
4. If the fix breaks something, revert and reclassify as KEEP with explanation

After all individual fixes pass, run the full check suite once.

Step 6: Create PR

Use /mp:commit-push-pr skill to commit all changes and create a PR. Include the evaluation table in the PR body so reviewers can see the reasoning for each decision.

PR title format: chore: audit and fix code quality suppressions

Edge Cases

• Generated files (.svelte-kit/, dist/): skip entirely
• Test files: suppressions in test code are more often justified — evaluate with higher bar for removal
• Index/barrel files: unused-export suppressions on re-export files are usually justified
• Config-level "off" rules: check if the rule conflicts with another tool (e.g., ESLint no-undef off because TypeScript handles it) — these are usually justified