Agent skill

design-patterns

Guidance on when and how to apply design patterns. Use when: (1) asking which pattern to use, (2) refactoring code, (3) discussing code smells, (4) need to decouple components, (5) building extensible systems.

Stars 163
Forks 31

Install this agent skill to your Project

npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/design-patterns-0x7067-claude-code-setup

Metadata

Additional technical details for this skill

domains
[
    "design-patterns",
    "architecture",
    "refactoring",
    "oop"
]
language
typescript

SKILL.md

Design Patterns

Expert guidance on applying Gang of Four design patterns to solve common software design problems. This skill helps you identify code smells, match them to appropriate patterns, and implement solutions effectively.

Triggers

  • which pattern should I use - Pattern selection guidance
  • refactor this code - Identify and apply patterns to improve existing code
  • how to decouple - Find patterns to reduce coupling
  • design pattern for - Specific pattern recommendations
  • code smells - Identify problems that patterns can solve

Quick Reference

Input Output Duration
Code problem/smell Pattern recommendation + implementation guide 2-5 min
Existing code Refactoring plan with pattern 5-10 min
Pattern name Implementation example + guidance 1-2 min

Agent Behavior Contract

  1. Analyze first - Always examine existing code before recommending patterns
  2. Identify the problem - Clearly state the code smell or design issue
  3. Don't over-engineer - Apply patterns only when they solve real problems
  4. Explain trade-offs - Discuss pros and cons of each pattern
  5. Prefer simplicity - If a simpler solution exists, recommend it
  6. Show examples - Provide TypeScript code examples
  7. Consider alternatives - Mention related or alternative patterns

Pattern Selection Decision Tree

Object Creation Problems?

├─ Need to create objects without specifying concrete classes?
│  └─→ Factory Method
│
├─ Need families of related objects to work together?
│  └─→ Abstract Factory
│
├─ Complex object with many optional parameters?
│  └─→ Builder
│
└─ Need exactly one instance with global access?
   └─→ Singleton (⚠️ use sparingly)

Behavior/Algorithm Problems?

├─ Need to swap algorithms at runtime?
│  └─→ Strategy
│
├─ Behavior changes based on internal state?
│  └─→ State
│
├─ Need to notify multiple objects of changes?
│  └─→ Observer
│
├─ Want to queue, log, or undo operations?
│  └─→ Command
│
├─ Need to save/restore object state (undo/redo, snapshots)?
│  └─→ Memento
│
└─ Define algorithm skeleton, let subclasses override steps?
   └─→ Template Method

Structure/Interface Problems?

├─ Incompatible interfaces need to work together?
│  └─→ Adapter
│
├─ Need to add responsibilities without subclassing?
│  └─→ Decorator
│
└─ Want to simplify complex subsystem?
   └─→ Facade

Process

Phase 1: Identify the Problem

Analyze the code to identify specific issues.

  1. Read the code - Understand current implementation
  2. Identify code smells - Look for:
    • Tight coupling between classes
    • Large constructors or parameter lists
    • Conditional logic that changes frequently
    • Duplicate code across similar classes
    • Global state or singletons everywhere
    • Classes with too many responsibilities

Verification: You can clearly articulate the specific problem or limitation.

Phase 2: Match Problem to Pattern

Select the most appropriate pattern.

  1. Use decision tree - Navigate the decision tree above
  2. Consult reference files - Read detailed pattern documentation:
    • references/creational.md - Factory Method, Abstract Factory, Builder, Singleton
    • references/structural.md - Adapter, Decorator, Facade
    • references/behavioral.md - Observer, Strategy, Command, State, Template Method
  3. Consider alternatives - Evaluate 2-3 patterns if multiple fit
  4. Explain trade-offs - Discuss pros/cons of recommended approach

Verification: The pattern directly addresses the identified problem.

Phase 3: Implement Solution

Guide implementation with concrete examples.

  1. Show structure - Explain key participants (interfaces, classes, relationships)
  2. Provide example - Write TypeScript code demonstrating the pattern
  3. Explain flow - Walk through how components interact
  4. Point out gotchas - Warn about common mistakes

Verification: Implementation follows pattern principles and solves the original problem.

Common Scenarios → Patterns

Scenario Pattern Why
Multiple button types trigger save, but implementation differs Strategy Swap save algorithms at runtime
UI needs to update when data changes Observer Automatic notification system
Need to add logging, validation to existing objects Decorator Add behavior without modifying originals
Working with legacy API that doesn't match your interface Adapter Bridge incompatible interfaces
Complex library with 50 classes, just need simple operations Facade Simplified interface to subsystem
Creating game characters with many customization options Builder Step-by-step construction
Document editor with undo/redo Command Encapsulate operations as objects
Connection states: disconnected, connecting, connected State Behavior changes with state
Need to save object snapshots for rollback Memento Capture and restore state without breaking encapsulation

Anti-Patterns

Avoid Why Instead
Pattern for pattern's sake Adds unnecessary complexity Identify actual problem first
Singleton everywhere Hidden dependencies, hard to test Dependency injection
Deep decorator chains Debugging nightmare Consider composition or other patterns
Premature abstraction YAGNI violation Wait for clear pattern of repetition
Factory for single product Over-engineering Direct instantiation is fine
Observer for everything Memory leaks, performance issues Use only when truly needed

Verification

After applying a pattern:

  • The original problem is solved
  • Code is more maintainable, not more complex
  • Pattern participants have clear responsibilities
  • Tests pass and cover new structure
  • Team members understand the pattern choice
  • No unnecessary abstraction layers added

Extension Points

  1. Custom patterns: Document your own domain-specific patterns based on these fundamentals
  2. Pattern combinations: Some problems benefit from combining multiple patterns
  3. Refactoring catalog: Build a library of before/after refactorings for your codebase

References

  • Creational Patterns - Factory Method, Abstract Factory, Builder, Singleton
  • Structural Patterns - Adapter, Decorator, Facade
  • Behavioral Patterns - Observer, Strategy, Command, State, Template Method, Memento
  • Refactoring.Guru - Complete catalog with examples

Note: Pattern selection requires judgment. When in doubt, prefer simpler solutions over pattern application.

Expand your agent's capabilities with these related and highly-rated skills.

Didn't find tool you were looking for?

Be as detailed as possible for better results