<< All versions
Skill v1.0.0
currentAutomated scan100/100wasabeef/claude-code-cookbook/design-patterns
──Details
PublishedOctober 25, 2026 at 04:03 PM
Content Hashsha256:660bc19d6cb2f139...
Git SHAd4a413b71311
──Files
Files (1 file, 5.1 KB)
SKILL.md5.1 KBactive
SKILL.md · 196 lines · 5.1 KB
version: "1.0.0" description: 'Suggest design patterns and evaluate SOLID principles. Trigger with "suggest design patterns", "which patterns apply?", "check SOLID principles", "detect anti-patterns", "evaluate code design".' allowed-tools:
- Read
- Grep
- Glob
Suggest design patterns and evaluate SOLID principles
Suggests design patterns for your code and checks if it follows SOLID principles.
Usage
bash
/design-patterns [analysis_target] [options]
Options
--suggest: Suggest applicable patterns (default)--analyze: Analyze existing pattern usage--refactor: Generate refactoring proposals--solid: Check compliance with SOLID principles--anti-patterns: Detect anti-patterns
Basic Examples
bash
# Analyze patterns for entire project/design-patterns# Suggest patterns for specific file/design-patterns src/services/user.js --suggest# Check SOLID principles/design-patterns --solid# Detect anti-patterns/design-patterns --anti-patterns
Pattern Categories
1. Creational Patterns
- Factory Pattern: Abstracts object creation
- Builder Pattern: Step-by-step construction of complex objects
- Singleton Pattern: Ensures only one instance exists
- Prototype Pattern: Creates object clones
2. Structural Patterns
- Adapter Pattern: Converts interfaces
- Decorator Pattern: Dynamically adds functionality
- Facade Pattern: Simplifies complex subsystems
- Proxy Pattern: Controls access to objects
3. Behavioral Patterns
- Observer Pattern: Implements event notifications
- Strategy Pattern: Switches algorithms
- Command Pattern: Encapsulates operations
- Iterator Pattern: Traverses collections
SOLID Principles We Check
text
S - Single Responsibility (one class, one job)O - Open/Closed (open for extension, closed for modification)L - Liskov Substitution (subtypes should be replaceable)I - Interface Segregation (don't force unused methods)D - Dependency Inversion (depend on abstractions, not details)
Output Example
text
Design Pattern Analysis Report━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Currently Used Patterns├─ Observer Pattern: EventEmitter (12 instances)├─ Factory Pattern: UserFactory (3 instances)├─ Singleton Pattern: DatabaseConnection (1 instance)└─ Strategy Pattern: PaymentProcessor (5 instances)Recommended Patterns├─ [HIGH] Repository Pattern│ └─ Where: src/models/*.js│ └─ Why: Separate data access from business logic│ └─ Example:│ class UserRepository {│ async findById(id) { ... }│ async save(user) { ... }│ }│├─ [MED] Command Pattern│ └─ Where: src/api/handlers/*.js│ └─ Why: Standardize how requests are handled│└─ [LOW] Decorator Pattern└─ Where: src/middleware/*.js└─ Why: Better way to combine featuresSOLID Violations Found├─ [S] UserService: Does too much (auth AND authorization)├─ [O] PaymentGateway: Must change code to add payment types├─ [D] EmailService: Depends on specific classes, not interfaces└─ [I] IDataStore: Has methods nobody usesHow to Fix1. Split UserService into AuthService and AuthorizationService2. Add a PaymentStrategy interface for new payment types3. Create an EmailService interface4. Break up IDataStore into smaller interfaces
Advanced Usage Examples
bash
# See what happens if you use a pattern/design-patterns --impact-analysis Repository# Get example code for a pattern/design-patterns --generate Factory --for src/models/Product.js# Find patterns that work well together/design-patterns --combine --context "API with caching"# Check your architecture/design-patterns --architecture MVC
Example: Before and After
Before (Problem Code)
javascript
class OrderService {processOrder(order, paymentType) {if (paymentType === "credit") {// Credit card processing} else if (paymentType === "paypal") {// PayPal processing}// Other payment methods...}}
After (Applying Strategy Pattern)
javascript
// Strategy interfaceclass PaymentStrategy {process(amount) {throw new Error("Must implement process method");}}// Concrete strategiesclass CreditCardPayment extends PaymentStrategy {process(amount) {/* Implementation */}}// Contextclass OrderService {constructor(paymentStrategy) {this.paymentStrategy = paymentStrategy;}processOrder(order) {this.paymentStrategy.process(order.total);}}
Anti-Patterns We Find
- God Object: Classes that do everything
- Spaghetti Code: Tangled mess of control flow
- Copy-Paste Programming: Same code everywhere
- Magic Numbers: Random numbers with no explanation
- Callback Hell: Callbacks inside callbacks inside callbacks
Best Practices
- Go slow: Add patterns one at a time
- Need first: Only use patterns to solve real problems
- Talk it out: Get team buy-in before big changes
- Write it down: Document why you chose each pattern