SOLID Principles
Analyze source code for violations of Robert C. Martin's SOLID principles of object-oriented design. Produce actionable findings with severity ratings, code locations, and concrete refactoring suggestions.
Subcommands
Request a full audit or focus on a single principle:
| Command Pattern | Principle | Reference |
|---|---|---|
solid all / solid check / solid | All five principles | All references |
solid srp | Single Responsibility | references/srp.md |
solid ocp | Open/Closed | references/ocp.md |
solid lsp | Liskov Substitution | references/lsp.md |
solid isp | Interface Segregation | references/isp.md |
solid dip | Dependency Inversion | references/dip.md |
When no subcommand is specified, default to checking all five principles. When a principle is mentioned by name (even without saying "solid"), match it to the appropriate subcommand.
Workflow
1. Identify Target Code
Determine what code to analyze:
- When files or a directory are provided, use those.
- When a class/module is referenced by name, locate it.
- When ambiguous, ask which files or directories to scan.
Supported languages: any OO language (Python, Java, TypeScript, C#, C++, Kotlin, Go with struct methods, Rust with impl blocks, etc.). Adapt the principle checks to the idioms of the target language — not every principle manifests identically across languages.
2. Load Principle References
Before analyzing, read the reference file(s) for the requested principle(s):
references/srp.mdfor SRP checksreferences/ocp.mdfor OCP checksreferences/lsp.mdfor LSP checksreferences/isp.mdfor ISP checksreferences/dip.mdfor DIP checks
For a full audit (solid all), read all five.
3. Analyze
For each target file/class, apply the violation patterns from the loaded references. Think carefully about each pattern — not every heuristic match is a true violation. Consider context, project size, and pragmatism. A 50-line script doesn't need the same architectural rigor as a large production system.
4. Report Findings
Present findings using this structure:
Per Violation
**[PRINCIPLE] Violation — Severity: HIGH | MEDIUM | LOW**
Location: `filename.py`, class `ClassName`, lines ~XX-YY
Issue: Clear description of what violates the principle and why it matters.
Suggestion: Concrete refactoring approach with brief code sketch if helpful.Severity guidelines:
- HIGH: Active maintenance pain, bug risk, or blocks extensibility.
- MEDIUM: Code smell that will cause problems as the codebase grows.
- LOW: Minor design impurity, worth noting but fine to defer.
Summary
After all findings, provide:
- A count table:
| Principle | HIGH | MEDIUM | LOW | - Top 3 priorities: which violations to fix first and why.
- Overall assessment: one paragraph on the code's structural health.
5. Refactor Mode (Optional)
When a fix or refactoring is requested (e.g., "fix this", "refactor it", "show me the clean version"), produce refactored code that resolves the identified violations. Explain each change briefly.
Pragmatism Guidelines
These are guidelines, not laws. Apply judgment:
- Small utility scripts and prototypes get a lighter touch. Don't flag a 30-line script for lacking dependency injection.
- Some "violations" are conscious trade-offs. When a rationale is provided for a trade-off, acknowledge it rather than insisting on purity.
- Language idioms matter. A Python module with top-level functions isn't violating SRP just because it's not a class. Go interfaces are implicitly satisfied, so ISP looks different there.
- Prefer actionable findings over exhaustive catalogs. Five important findings beat twenty trivial ones.
Example Interaction
User: solid srp (with a file attached)
Claude:
- Reads
references/srp.md - Analyzes the attached file for SRP violations
- Reports findings with locations, severity, and suggestions
- Provides a summary with priorities