quality-patterns

name	quality-patterns
description	Identifies code quality anti-patterns and provides best practices. Applied when analyzing code smells, architecture decisions, complexity, or technical debt.
user-invocable	false

Quality Patterns & Anti-Patterns

Code quality isn't subjective. These patterns are proven signals — each backed by decades of engineering wisdom. When this skill is active, evaluate code against these patterns. Flag violations with evidence and specific remediation.

Anti-Patterns to Flag

Complexity

• God objects: Classes with many unrelated public methods or excessive dependencies (typically 8+ public methods across multiple concerns, or 10+ dependencies). Fix: Extract focused collaborators.
• Feature envy: A function that accesses another object's data more than its own. Fix: Move the behavior to where the data lives.
• Primitive obsession: Using strings or numbers where a domain type would add clarity. Fix: Introduce a value object (EmailAddress, Money, UserId).
• Deep nesting: More than 3 levels of indentation. Fix: Extract to functions, use early returns, invert conditions.

Coupling

• Temporal coupling: Functions that must be called in a specific order. Fix: Make the dependency explicit through function composition or a builder pattern.
• Stamp coupling: Passing a large object when only one field is needed. Fix: Pass only what's needed. Narrow the interface.
• Leaky abstractions: Implementation details surfacing through a public API. Fix: Introduce an interface boundary.

Duplication

• Shotgun surgery: A single change requires edits in many places. Fix: Centralize the varying behavior behind an abstraction.
• Copy-paste code: Identical or near-identical blocks in multiple locations. Fix: Extract a shared function. If the duplication is structural, extract a pattern.
• Long parameter lists: Functions taking 4+ parameters that travel together. Fix: Introduce a parameter object or config type.
• Data clumps: Groups of values that always appear together across multiple functions. Fix: Extract a cohesive type that represents the concept.

Error Handling

• Silent failures: Catching errors without logging or rethrowing. Fix: At minimum, log. Better: rethrow or return a Result type.
• Overly broad catches: catch (e: any) or catch (Exception e). Fix: Catch the narrowest type possible.
• Error codes as control flow: Using return values instead of exceptions (or vice versa) inconsistently. Fix: Pick one pattern and use it consistently within a boundary.

Positive Patterns to Encourage

• Single Responsibility: Each module has one reason to change.
• Dependency Inversion: Depend on abstractions, not concretions.
• Fail Fast: Validate inputs at the boundary, trust internals.
• Composition over Inheritance: Combine behaviors through composition.
• Immutability by Default: Mutable state is opt-in, not opt-out.
• Explicit over Implicit: Make side effects, dependencies, and state transitions visible.

Severity Classification

When reporting issues, classify by impact:

• Critical: Will cause bugs, data loss, or security vulnerabilities. Must fix.
• Warning: Increases maintenance cost or risk. Should fix.
• Suggestion: Improves clarity or follows best practices. Consider fixing.

Only flag issues you are confident about. False positives erode trust.