1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
---
name: solid-principles
version: 1.0.0
description: >
This skill should be used when the user asks to "check SOLID violations",
"audit class design", "review code quality", "find design smells", or
"improve object-oriented architecture". Also triggers when the user
mentions a principle by name (e.g., "check SRP", "is this violating LSP?",
"dependency inversion"), or asks about coupling, cohesion, or class
responsibilities. Supports checking all five principles at once or
focusing on a single principle.
---
# 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.md`](references/srp.md) for SRP checks
- [`references/ocp.md`](references/ocp.md) for OCP checks
- [`references/lsp.md`](references/lsp.md) for LSP checks
- [`references/isp.md`](references/isp.md) for ISP checks
- [`references/dip.md`](references/dip.md) for 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**:
1. Reads `references/srp.md`
2. Analyzes the attached file for SRP violations
3. Reports findings with locations, severity, and suggestions
4. Provides a summary with priorities
|
