SOLID Code Review Skill

Description

This skill reviews code specifically against SOLID principles, providing structured analysis for each principle. It identifies violations, explains why they matter, and provides concrete refactoring suggestions with before/after code examples.

Instructions

When reviewing code for SOLID compliance, analyze each principle:

S — Single Responsibility Principle (SRP)

"A class should have only one reason to change."

Look for:

• Classes/functions doing multiple unrelated things
• Methods longer than 30 lines
• Classes with mixed concerns (data + UI + business logic)

Copy
// VIOLATION: UserService handles auth, email, AND data
class UserService {
  async createUser(data) { /* ... */ }        // Data
  async sendWelcomeEmail(user) { /* ... */ }   // Email
  async validatePassword(pw) { /* ... */ }     // Auth
  async generateReport(userId) { /* ... */ }   // Reporting
}

// FIX: Split into focused services
class UserRepository { async create(data) { /* ... */ } }
class EmailService { async sendWelcome(user) { /* ... */ } }
class AuthService { async validatePassword(pw) { /* ... */ } }
class ReportService { async generateUserReport(id) { /* ... */ } }

O — Open/Closed Principle (OCP)

"Open for extension, closed for modification."

Look for:

• Long if/else or switch chains for type handling
• Adding new features requires modifying existing code

Copy
// VIOLATION: Adding a new payment type requires modifying this function
function processPayment(type: string, amount: number) {
  if (type === 'credit') { /* ... */ }
  else if (type === 'paypal') { /* ... */ }
  else if (type === 'crypto') { /* ... */ } // <-- had to modify
}

// FIX: Use strategy pattern
interface PaymentProcessor {
  process(amount: number): Promise<Result>;
}

class CreditCardProcessor implements PaymentProcessor { /* ... */ }
class PayPalProcessor implements PaymentProcessor { /* ... */ }
class CryptoProcessor implements PaymentProcessor { /* ... */ } // No modification needed

const processors = new Map<string, PaymentProcessor>();
function processPayment(type: string, amount: number) {
  return processors.get(type)!.process(amount);
}

L — Liskov Substitution Principle (LSP)

"Subtypes must be substitutable for their base types."

Look for:

• Subclasses that throw errors for inherited methods
• Overrides that change expected behavior
• instanceof checks in code using base type

I — Interface Segregation Principle (ISP)

"No client should be forced to depend on methods it does not use."

Look for:

• Large interfaces with many methods
• Classes implementing interfaces with unused methods
• God interfaces that cover multiple concerns

D — Dependency Inversion Principle (DIP)

"Depend on abstractions, not concretions."

Look for:

• Direct instantiation of dependencies (new Service())
• Importing concrete classes instead of interfaces
• No dependency injection pattern

Output Format

Copy
## SOLID Analysis Report

| Principle | Status | Violations | Severity |
|-----------|--------|------------|----------|
| SRP | FAIL | 3 | High |
| OCP | WARN | 1 | Medium |
| LSP | PASS | 0 | — |
| ISP | WARN | 2 | Low |
| DIP | FAIL | 4 | High |

### Detailed Findings

#### SRP-1: UserService has 4 responsibilities [HIGH]
**File:** src/services/UserService.ts
**Issue:** Handles auth, email, data, and reporting
**Fix:** Split into 4 focused services
[Before/after code...]

Rules

• Analyze ALL five principles — do not skip any
• Rate severity: HIGH (architectural problem), MEDIUM (should fix), LOW (nice to have)
• Provide concrete before/after code examples for each violation
• Do not dogmatically enforce SOLID on simple scripts or prototypes
• Acknowledge when pragmatism outweighs strict adherence
• Consider the project context — a 50-line utility does not need DIP
• Present findings in a summary table first, details after

Examples

User: Review this service for SOLID compliance Action: Analyze against all 5 principles, generate report with violation table and refactoring suggestions

User: Is this class violating SRP? Action: Focus on SRP analysis, identify responsibilities, suggest splitting strategy

User: How can I make this code more extensible? Action: Focus on OCP, suggest patterns (strategy, plugin, decorator) that enable extension without modification