elct9620/skills/design-patterns
skills/design-patterns/SKILL.md
--- name: design-patterns description: Select and apply GoF design patterns: Factory, Builder, Strategy, Observer, Adapter, Decorator. Use when solving recurring design problems or structuring multi-component changes. Make sure to use this skill whenever the user needs to decouple components, wrap legacy APIs, handle multiple algorithm variants, build complex objects step by step, or asks which pattern fits their situation. --- ## Related Skills - Modeling business concepts (Entity, Value Obje
$ install --global
skillsauthnpx skillsauth add elct9620/ai-coding-skills skills/design-patternsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 28, 2026, 3:31 PM180.3s1 file scanned
SKILL.md
- name:
- design-patterns
- description:
- Select and apply GoF design patterns: Factory, Builder, Strategy, Observer, Adapter, Decorator. Use when solving recurring design problems or structuring multi-component changes. Make sure to use this skill whenever the user needs to decouple components, wrap legacy APIs, handle multiple algorithm variants, build complex objects step by step, or asks which pattern fits their situation.
Related Skills
- Modeling business concepts (Entity, Value Object)? → Use domain-modeling instead
- Restructuring existing code toward a pattern? → Use refactoring for safe migration steps
- Deciding if a pattern is even needed (YAGNI)? → Use principles to evaluate first
Applicability Rubric
| Condition | Pass | Fail | |-----------|------|------| | Multi-component change | Feature affects multiple components | Single component change | | Recognizable problem | Matches known design problem | Unique/novel problem | | Flexibility needed | Requires extensible solution | Fixed requirements | | Recurring challenge | Solving common design issue | One-off implementation |
Apply when: Any condition passes
Core Principles
Pattern Selection Process
1. Identify the problem
↓
2. Match problem to pattern category
↓
3. Evaluate pattern candidates
↓
4. Consider trade-offs
↓
5. Apply pattern minimally
Pattern Categories
| Category | Purpose | Common Patterns | |----------|---------|-----------------| | Creational | Object creation | Factory, Builder, Singleton | | Structural | Object composition | Adapter, Decorator, Facade | | Behavioral | Object interaction | Strategy, Observer, Command |
Pattern Quick Reference
| Category | Pattern | Use When | Example |
|----------|---------|----------|---------|
| Creational | Factory Method | Object creation varies by context | createLogger(type) |
| Creational | Builder | Complex object with many optional parts | Fluent configuration |
| Creational | Singleton | Single instance needed globally | Configuration manager |
| Structural | Adapter | Interface incompatibility | Wrap legacy API |
| Structural | Decorator | Add behavior dynamically | Logging wrapper |
| Structural | Facade | Simplify complex subsystem | Unified API client |
| Structural | Composite | Tree structures | UI components |
| Behavioral | Strategy | Algorithm varies at runtime | Payment methods |
| Behavioral | Observer | One-to-many notifications | Event system |
| Behavioral | Command | Encapsulate operations | Undo/redo actions |
| Behavioral | State | Behavior changes with state | Order status |
Completion Rubric
Before Applying
| Criterion | Pass | Fail | |-----------|------|------| | Problem identification | Problem clearly defined | Vague problem statement | | Real need | Solves actual problem | Hypothetical/speculative | | Simpler alternatives | Considered simpler options first | Jumped to pattern | | Team familiarity | Team understands pattern | Pattern is obscure |
During Implementation
| Criterion | Pass | Fail | |-----------|------|------| | Minimal application | Pattern applied minimally | Over-applied | | Clear naming | Names reflect pattern intent | Generic/unclear names | | Intent preservation | Pattern intent maintained | Pattern misused | | Appropriate complexity | Complexity justified | Over-engineered |
After Implementation
| Criterion | Pass | Fail | |-----------|------|------| | Flexibility gained | Code more flexible | Same or less flexible | | Documented | Pattern documented if not obvious | Undocumented complexity | | Tested | Tests cover pattern behavior | Pattern untested |
Anti-Pattern Warning
Pattern Fever: Applying patterns everywhere
Signs:
- Patterns for trivial problems
- Multiple patterns where one suffices
- Code harder to understand than before
Cure: YAGNI - Use patterns only when they solve real problems
Related Skills
elct9620/architecture
development
VerifiedTrustedCommunity
Plan how a system is structured — which layers, modules, or contexts exist and how code is laid out — driven by the forces at play, not by a fixed pattern. The default is to add no extra structure; structure is introduced only when complexity calls for it, and the chosen shape (Clean Architecture, DDD, DCI, or another) is judged in the moment. Use this skill when following a recorded structure in docs/architecture.md, or when deciding the structural shape for a non-trivial feature, a new module, or a restructuring — especially after a design-forces memo recommends a layered or partitioned structure.
5SKILL.mdUpdated May 31, 2026
elct9620/design-forces
development
VerifiedTrustedCommunity
Surface design forces and lay out the option space — including framework defaults, scaffolds, and deferring — before committing to Clean Architecture, DDD, or any heavier pattern. Produces a Design Analysis Memo at the start of /write, /refactor, or non-trivial /fix. Make sure to use this skill whenever the user starts a non-trivial feature, restructures code, or asks "do we really need Clean Architecture / DDD / pattern X here".
5SKILL.mdUpdated May 29, 2026
elct9620/testing
development
VerifiedTrustedCommunity
Write tests using TDD (Red-Green-Refactor) and AAA pattern. Use for every new feature, behavior change, or bug fix. Covers unit, integration, and E2E test selection. Make sure to use this skill whenever the user asks to add tests, fix a bug (tests should come first), implement a feature with test coverage, or asks about what kind of tests to write — even for small one-line changes or trivial-looking fixes.
5SKILL.mdUpdated Apr 28, 2026
elct9620/security
development
VerifiedTrustedCommunity
Prevent security vulnerabilities through threat modeling, trust boundary analysis, and defense in depth. Use when writing code that crosses trust boundaries, handles authentication or authorization, processes external input, manages secrets, or stores sensitive data. Make sure to use this skill whenever the user works on login flows, processes data from external sources, builds interfaces between systems, manages credentials, or writes code that moves data across trust zones — even for seemingly simple changes like accepting a new parameter or calling an external service.
5SKILL.mdUpdated Apr 28, 2026