This skill should be used when the user asks about "SOLID principles", "single responsibility", "open/closed principle", "Liskov substitution", "interface segregation", "dependency inversion", or when analyzing code for design principle violations. Provides comprehensive guidance for detecting and fixing SOLID violations.
Detects SOLID principle violations in code and provides specific refactoring guidance. Triggers when analyzing code quality or when users ask about SOLID principles, single responsibility, open/closed, Liskov substitution, interface segregation, or dependency inversion.
/plugin marketplace add shabaraba/shabaraba-cc-plugins/plugin install dev-org@shabaraba-cc-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/refactoring-examples.mdreferences/violation-patterns.mdSOLID is a set of five object-oriented design principles that promote maintainable, flexible, and scalable code. This skill provides guidance for detecting violations and applying correct patterns across multiple languages.
A class should have only one reason to change.
Detection Patterns:
Refactoring Strategy:
Software entities should be open for extension but closed for modification.
Detection Patterns:
Refactoring Strategy:
Subtypes must be substitutable for their base types.
Detection Patterns:
Refactoring Strategy:
Clients should not be forced to depend on interfaces they don't use.
Detection Patterns:
Refactoring Strategy:
High-level modules should not depend on low-level modules; both should depend on abstractions.
Detection Patterns:
Refactoring Strategy:
| Severity | Description | Action |
|---|---|---|
| Critical | Principle completely ignored, major maintenance issues | Immediate refactoring required |
| High | Clear violation affecting multiple areas | Schedule refactoring soon |
| Medium | Partial violation, localized impact | Refactor during related changes |
| Low | Minor deviation, minimal impact | Note for future improvement |
To analyze code for SOLID violations:
Focus on module boundaries, class size, and interface definitions. Check for barrel exports hiding complex dependencies.
Examine class hierarchies, interface implementations, and package dependencies. Look for "util" packages violating SRP.
Check module organization, abstract base classes, and duck typing patterns. Verify protocol compliance.
Analyze interface definitions (should be small), struct composition, and package dependencies.
Examine trait usage, interface implementations, and namespace organization.
When reporting SOLID violations, structure findings as:
## SOLID Analysis Results
### Critical Violations
#### [File:Line] Principle Violated
- **Issue**: Description of the problem
- **Impact**: Why this matters
- **Suggestion**: How to fix it
- **Example**: Code snippet showing fix
### High Severity
...
For detailed patterns and language-specific examples:
references/violation-patterns.md - Comprehensive violation detection patternsreferences/refactoring-examples.md - Before/after code examplesCombine with:
code-quality-metrics for complexity analysisrefactoring-patterns for specific refactoring techniquesUse when working with Payload CMS projects (payload.config.ts, collections, fields, hooks, access control, Payload API). Use when debugging validation errors, security issues, relationship queries, transactions, or hook behavior.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.