Solid Principles

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:

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 for SRP checks
• references/ocp.md for OCP checks
• references/lsp.md for LSP checks
• references/isp.md for ISP checks
• 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