Use when a developer has a design problem and needs help identifying and implementing the most appropriate design pattern. Activate for structuring code around a recurring architectural challenge, applying OOP or functional patterns, or improving extensibility. Do NOT use for refactoring without a pattern goal, API design, or database schema design.
Identify, justify, and implement the optimal design pattern for a specific architectural challenge.
| Variable | Type | Req | Description |
|---|---|---|---|
tech_stack | string | Yes | e.g., "Java + Spring Boot" |
problem_description | string | Yes | Core design issue and maintenance pain points |
context | string | Yes | Existing structure, constraints, or related modules |
| Case | Strategy |
|---|---|
| Multiple valid patterns | Implement both in brief; recommend based on existing codebase conventions. |
| Existing anti-pattern | Identify it, explain why it's harmful, and provide a migration path. |
| Functional stack | Adapt OOP patterns to functional equivalents (e.g., Strategy → HOF). |
flowchart TD
A([Start: problem_description + tech_stack + context]) --> B{Anti-pattern\nin existing context?}
B -- Yes --> C[Name the anti-pattern\nExplain why it's problematic\nRecommend migration path]
B -- No --> D
C & D --> E{Functional language\ne.g. Elixir, Haskell?}
E -- Yes --> F[Adapt to functional equivalents:\nStrategy → higher-order functions\nObserver → pub/sub with processes]
E -- No --> G[Apply OOP/structural patterns]
F & G --> H{Problem fits\nmultiple patterns equally?}
H -- Yes --> I[Implement both in abbreviated form\nRecommend based on team conventions\nin context]
H -- No --> J[Select single best pattern]
I & J --> K[Pattern Recommendation\nName the pattern\nExplain in 2-3 sentences\nwhy it fits THIS specific problem\nnot a generic description]
K --> L[Alternatives Considered\n2 alternative patterns:\nwhy each could work\nwhy recommended is better for this case]
L --> M[Implementation\nComplete and runnable\nIdiomatic language features:\ninterfaces, generics, decorators\nInline comments on key structural elements]
M --> N[Usage Example\nRealistic scenario from problem domain\nshowing how developer uses the pattern]
N --> O[Trade-offs\nWhat it makes easier\nWhat it makes harder\nWhen NOT to use this pattern\nanti-pattern conditions]
O --> P([Output: Pattern recommendation\n+ Alternatives + Implementation\n+ Usage example + Trade-offs])
@upstash/context7-mcp: Library documentation and examples.| Version | Date | Description |
|---|---|---|
| 1.1.0 | 2026-03-20 | Restructured: moved examples to examples/, references to references/, added compatibility and license fields |
| 1.0.0 | 2026-03-20 | Initial release |