What this prompt does
This prompt makes the AI a design patterns expert that diagnoses a [code_smell] and recommends the right pattern to fix it, with full before/after code. You describe the smell, the [pain_points] it causes, your [tech_stack], and your [team_size], and it returns a six-part analysis: a named diagnosis, a recommendation of one or two patterns, a complete before-and-after refactor, a step-by-step implementation guide, trade-offs and warnings, and a testing strategy.
The structure works because it refuses to apply a pattern blindly. It names the specific smell (God Class, Feature Envy, Shotgun Surgery), explains why it is problematic rather than just that it is, and rates how much worse it gets as the codebase grows. It draws recommendations from the creational, structural, and behavioral categories, notes any [framework]-specific implementations, and is explicit about when the pattern becomes over-engineering. Your [team_size] and [additional_consideration] shape the advice, because the wrong abstraction is worse than the smell it replaces.
When to use it
- You have a God class or tangled conditional and aren't sure which pattern fits
- You want a before/after refactor that touches every affected file, not just the main class
- You need a migration plan that won't break production while you refactor
- You want honest trade-offs, including when a pattern is overkill for your team
- You are weighing two patterns and need a reasoned comparison
- You need a testing strategy that would have caught the original smell
Example output
You get a named diagnosis with a severity rating, a recommendation of one or two patterns with reasoning against the alternatives, a complete before-and-after code transformation across all affected files, a step-by-step migration guide, a trade-offs section flagging over-engineering and performance, and a testing strategy with unit and integration tests that pin the new behavior.
Pro tips
- Paste the actual code or describe
[code_smell]concretely; vague smells get vague pattern advice - Spell out
[pain_points]in terms of real cost ("can't unit test providers") so severity is judged accurately - Set
[framework]so it surfaces built-ins; Laravel's container already provides some patterns for free - Use
[additional_consideration]for the constraint that matters, like A/B testing flows per region - Match
[team_size]honestly, since discoverability advice differs for a solo dev versus a mixed team - Push back if the recommendation feels heavy; ask it to justify the pattern against the simpler do-nothing option
