💬Prompting Patterns That Actually Work
Five reusable prompt shapes for builders. Steal them, adapt them, ship faster.
What you'll get
- Recognise five high-leverage prompt shapes
- Know which shape to reach for in which situation
- Spot and rewrite vague prompts before sending them
- Build your own prompt library you can reuse forever
A great prompt is mostly structure. Once you internalise a few shapes, you stop staring at the blank box and start shipping. This guide walks through five patterns that cover ~90% of real builder workflows, when to use each, and the anti-patterns to avoid.
- Outcome + constraint
- Example-driven
- Diff prompt
- Persona + task
- Self-review
- Persona + task
Shape 1 — Outcome + constraint
The default opening shape. You describe what success looks like, then add one or two constraints to narrow the solution space. 'Build X. Use Y. Don't use Z.' Surprisingly powerful for first prompts because it tells the AI both the destination and the rails.
Without constraints, the AI tends to grab whatever framework or pattern it saw most recently. With constraints, you get something that fits your project.
Build a pricing page with three tiers. Use only the existing design tokens. No new fonts. No external libraries.
Shape 2 — Persona + task
Personas focus the model on a particular value system. 'Act as a senior product designer reviewing this landing page. List the three most impactful changes.' That sentence is doing a lot of work — it tells the AI what taste to apply, what format to use, and how long to be.
Use this when you want judgement, not code. It's a tiny on-demand expert.
Act as a senior accessibility consultant. Review this checkout flow and list the top 5 issues, in priority order, with a one-sentence fix for each.
Shape 3 — The diff prompt
The single most important shape once you have something on screen. A diff prompt tells the AI exactly what to keep and what to change. The AI loves to 'helpfully' redesign things — diff prompts shut that down.
Two-thirds of your prompts after the first one should be diff prompts.
Leave the layout alone. Just swap the call-to-action copy from 'Sign up' to 'Start free' and make the button slightly larger. Don't touch anything else.
Shape 4 — Example-driven
Show, don't tell. Paste a snippet of the style, voice, or structure you want and say 'continue in this voice' or 'apply this pattern to the rest of the file'. This is dramatically more reliable than describing a style in adjectives.
Example-driven prompts are how you get consistent design across many screens, consistent tone across many blog posts, and consistent code patterns across many files.
Here's how I write feature descriptions: '<paste 2 examples>'. Now write descriptions for these 5 features in the same voice: <list>.
Shape 5 — Self-review
After the AI produces something, ask it to critique its own output. 'Now review this as a critical engineer and list the three biggest weaknesses.' You get a free QA pass, and often the AI will catch and fix bugs you would have missed.
Bonus: this also works as a learning tool. The critique teaches you what to look for next time.
Now review the code you just wrote as a senior engineer. List the three biggest weaknesses (security, performance, or maintainability) and propose a fix for each.
Anti-patterns to avoid
Most failed prompts fall into one of a few traps. Recognising them in your own writing is half the battle.
- 'Make it better' — better how?
- 'Fix the bugs' — which bugs?
- 'Make it more modern' — by whose definition?
- Pasting 5,000 lines and asking 'thoughts?'
- 'Increase the headline to 64px and centre it'
- 'When I submit the form twice, two rows are created — fix that'
- 'Apply the visual style of Stripe's pricing page'
- 'In auth.ts, simplify the session refresh logic'
Build your prompt library
Every prompt that worked is an asset. Save it. A simple markdown file in your project is enough — `prompts.md` with sections for design, features, refactors, and reviews.
Over time, your library becomes the most valuable thing in your repo. New projects get faster because you start from a shelf of proven shapes instead of a blank page.
Prompt examples
Build a pricing page with three tiers. Use only the existing design tokens. No new fonts.
Leave the layout alone. Just swap the call-to-action copy from 'Sign up' to 'Start free' and make the button slightly larger.
Now review the output as a critical engineer and suggest the three biggest weaknesses.
- 'Make it better' (better how?)
- Pasting an entire 5,000-line file and asking for 'fixes'
- Forgetting to constrain the stack and getting a different framework every time
- Skipping the self-review pass on anything that ships
- One verb, one noun, one constraint
- Always tell the AI what to keep, not just what to change
- Save your favourite prompts in a notes file
- End any non-trivial change with a self-review prompt
Prompts aren't deployed, but they are versioned. Keep a markdown file in your repo with the prompts that produced each major change.