code-quality-antipatterns

Enforce approval-based, line-level suppression pragmas for lint, type, and coverage issues.

2|Updated Mar 5, 2026
One-click install
npx skills add https://github.com/grimlor/universal-dev-skills --skill code-quality-antipatterns
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-quality-antipatterns
Source: https://github.com/grimlor/universal-dev-skills/tree/main/skills/code-quality-antipatterns
Command: npx skills add https://github.com/grimlor/universal-dev-skills --skill code-quality-antipatterns

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents quality-degrading suppression pragmas and disguised evasions from silently hiding real type, lint, and coverage problems in production and test code.

Core Features & Use Cases

  • Suppression guardrails with an approval workflow: For any candidate pragma (e.g., type-ignore, noqa, eslint-disable, SuppressWarnings, no cover), the agent must fix first, then seek explicit user approval only after presenting the diagnostic, the correct fix, and proof no fix pattern resolves it.
  • Anti-evasion enforcement: Blocks runtime “silencing” through catch-all exceptions or other practices that function like suppression, and rejects test-only plumbing added into production APIs.
  • Line-level, rule-specific restrictions: Requires narrow, justified, line-level suppressions (no file-level disables, no broad blocks) and mandates the same approval flow for coverage gaps.
  • Generated-code exclusion: Excludes build-generated artifacts from pragma auditing, steering fixes to generator/config or post-processing rather than modifying generated outputs.

Quick Start

Ask the agent to fix a failing lint/type/coverage finding without introducing any suppression during implementation work, and require an approval-only, line-level pragma if the diagnostic truly cannot be cleaned up.

Frequently Asked Questions about code-quality-antipatterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I stop eslint-disable and type-ignore comments from hiding real code quality issues?

To stop suppression pragmas from hiding code quality issues, enforce a fix-first workflow that requires explicit user approval before adding any line-level, rule-specific suppression comments. File-level disables and broad blocks must be rejected during lint and type-check passes.

What is the best way to handle linting and coverage failures without suppressing errors?

The best way to handle linting and coverage failures without suppressing errors is to resolve the underlying diagnostic pattern directly. You should only seek approval for a pragma after proving no code-pattern remedy exists for the failing check.

Does this code review approach work with generated build artifacts and coverage exclusions?

This code review approach works with generated build artifacts by explicitly excluding them from pragma auditing. Instead of modifying generated outputs, fixes are steered toward the generator configuration or post-processing steps.

Why should I avoid catch-all exceptions during static analysis and code review?

You should avoid catch-all exceptions during static analysis because they act as runtime suppression evasions that silently hide real type and lint problems. Anti-evasion enforcement blocks these practices and rejects test-only plumbing added into production APIs.

When should I use a no cover pragma instead of fixing a coverage gap?

You should use a no cover pragma only when you have evidence that no code-pattern remedy exists for the coverage gap. The same fix-first approval flow mandated for type-ignore and eslint-disable comments applies to coverage suppressions.