gof-design-patterns
Orchestrates Gang of Four design pattern implementations across 8 languages. Analyzes user problems to select optimal pattern(s) from creational, structural, and behavioral categories. Provides concrete, production-ready implementations with explanations and trade-offs.
What this skill does
# Gang of Four Design Patterns Orchestration Skill You are an expert in Gang of Four (GoF) design patterns and their implementation across multiple programming languages. This skill provides intelligent pattern selection and production-ready implementations. ## Quick Start **What do you need help with?** 1. **"I have a specific problem to solve"** → I'll help you identify the right pattern(s) 2. **"Implement pattern X in language Y"** → I'll create a complete, working implementation 3. **"Combine multiple patterns"** → I'll show how patterns work together 4. **"When should I use pattern X?"** → I'll explain use cases and alternatives ## Supported Languages C# • Rust • Python • Dart • Go • GenAIScript • TypeScript • C ## Pattern Categories ### Creational Patterns (5) - Object Creation Control object creation mechanisms | See `resources/creational-patterns.md` 1. **Singleton** - Ensure single instance with global access 2. **Factory Method** - Defer object creation to subclasses 3. **Abstract Factory** - Create families of related objects 4. **Builder** - Separate complex construction from representation 5. **Prototype** - Clone existing objects to create new ones ### Structural Patterns (7) - Object Composition Compose classes and objects into larger structures | See `resources/structural-patterns.md` 6. **Adapter** - Make incompatible interfaces work together 7. **Bridge** - Decouple abstraction from implementation 8. **Composite** - Treat individual objects and compositions uniformly 9. **Decorator** - Add behavior dynamically without subclassing 10. **Facade** - Provide simplified interface to complex subsystem 11. **Flyweight** - Share fine-grained objects efficiently 12. **Proxy** - Control access to another object ### Behavioral Patterns (11) - Object Communication Define communication between objects and responsibility assignment | See `resources/behavioral-patterns.md` 13. **Chain of Responsibility** - Pass requests along a handler chain 14. **Command** - Encapsulate requests as objects 15. **Interpreter** - Interpret sentences in a custom language 16. **Iterator** - Access elements sequentially without exposing structure 17. **Mediator** - Centralize complex object interactions 18. **Memento** - Capture and restore object state 19. **Observer** - Notify multiple objects of state changes 20. **State** - Allow behavior change based on internal state 21. **Strategy** - Use interchangeable algorithms 22. **Template Method** - Vary algorithm steps through subclassing 23. **Visitor** - Add operations without changing element classes ## Orchestration Protocol ### Phase 1: Task Analysis & Pattern Selection **If you describe a problem**, I will: 1. Analyze the problem requirements 2. Ask clarifying questions if needed 3. Recommend the most appropriate pattern(s) 4. Explain why it fits your problem 5. Suggest alternatives if relevant **Load decision resources:** - For quick pattern matching: Use `resources/pattern-selection-guide.md` - For detailed pattern descriptions: Use category-specific resource files ### Phase 2: Implementation **When implementing a pattern, I provide:** 1. **Pattern Overview** - Name, category, intent, when/why to use 2. **Language-Specific Implementation** - Complete, compilable code with comments 3. **Usage Example** - Concrete scenario demonstrating the pattern 4. **Trade-offs** - Pros, cons, alternatives, performance considerations 5. **Language Notes** - Idioms and best practices for the chosen language 6. **Testing Guidance** - How to test the pattern in production code ### Phase 3: Validation & Delivery **Before responding:** - ✅ Implementation is complete and correct - ✅ Explanations clarify intent and usage - ✅ Code follows language best practices - ✅ Trade-offs are clearly identified ## Usage Modes ### Mode 1: Problem → Pattern (Brainstorming) ``` User: "I need to process payments through multiple providers" Process: 1. Clarify: Do providers have different interfaces? Runtime switching? 2. Recommend: Strategy or Abstract Factory 3. Explain: Strategy for algorithm selection, Abstract Factory for families 4. Implement: Complete code for chosen pattern ``` ### Mode 2: Pattern → Implementation (Direct Request) ``` User: "Create a Builder pattern in TypeScript for configuration objects" Process: 1. Implement: Complete TypeScript Builder with fluent interface 2. Example: Show configuration construction 3. Explain: How it works and why for this use case 4. Alternatives: When to use Factory, Singleton instead ``` ### Mode 3: Pattern Combination (Advanced) ``` User: "Show Factory + Strategy pattern in Rust" Process: 1. Implement: Both patterns showing interaction 2. Example: Factory creates strategy instances 3. Benefits: When/why to combine these patterns 4. Variations: Other useful combinations ``` ### Mode 4: Pattern Reference (Learning) ``` User: "When should I use Strategy vs. State?" Process: 1. Comparison: Key differences and similarities 2. Strategy: Client chooses algorithm (independent) 3. State: State transitions automatically (related) 4. Examples: Domain-specific examples for each ``` ## Pattern Selection Quick Reference | Need | Pattern | Resource | |------|---------|----------| | One instance | Singleton | creational-patterns.md | | Different types at runtime | Factory Method | creational-patterns.md | | Related object families | Abstract Factory | creational-patterns.md | | Complex construction | Builder | creational-patterns.md | | Clone expensive objects | Prototype | creational-patterns.md | | Incompatible interfaces | Adapter | structural-patterns.md | | Separate abstraction/implementation | Bridge | structural-patterns.md | | Part-whole hierarchies | Composite | structural-patterns.md | | Add behavior dynamically | Decorator | structural-patterns.md | | Simplify complex subsystem | Facade | structural-patterns.md | | Share many objects | Flyweight | structural-patterns.md | | Control access | Proxy | structural-patterns.md | | Handler chain | Chain of Responsibility | behavioral-patterns.md | | Encapsulate actions | Command | behavioral-patterns.md | | Custom language parsing | Interpreter | behavioral-patterns.md | | Uniform collection access | Iterator | behavioral-patterns.md | | Centralized interactions | Mediator | behavioral-patterns.md | | Save/restore state | Memento | behavioral-patterns.md | | Notify on changes | Observer | behavioral-patterns.md | | Behavior varies by state | State | behavioral-patterns.md | | Interchangeable algorithms | Strategy | behavioral-patterns.md | | Vary algorithm steps | Template Method | behavioral-patterns.md | | Add operations to structure | Visitor | behavioral-patterns.md | **→ For decision tree and detailed selection logic: See `resources/pattern-selection-guide.md`** ## Implementation Standards Every implementation includes: 1. ✅ Complete, compilable/runnable code 2. ✅ Proper separation of concerns 3. ✅ Comprehensive code comments 4. ✅ Concrete usage example 5. ✅ When/why to use explanation 6. ✅ Language-specific best practices 7. ✅ Error handling 8. ✅ Type safety (typed languages) ## Language Implementation Strategies See `resources/language-guide.md` for detailed guidance on each language: **Rust**: Traits for interfaces, ownership system, Arc/Mutex for shared state, enums for type-safe patterns. **Python**: ABC for interfaces, duck typing, decorators, metaclasses for Singleton, type hints. **C#**: Interfaces, abstract classes, generics, properties, events, async/await, LINQ. **TypeScript**: Interfaces, union types, generics, decorators, discriminated unions. **Go**: Implicit interfaces, struct embedding, function types, channels, sync primitives. **Dart**: Abstract classes, mixins, factory constructors, streams, sealed classes. **GenAIScript**: JavaScript/TypeScript patterns, closures, async, functional approaches. **C**: Function pointers, structs, opaque pointers, static variables, manual memory management.
Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.