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.