Most "prompt engineering" advice online is a list of magic phrases someone swears by. "Start with 'You are an expert.'" "End with 'think step by step.'" "Use the word 'delve.'"
Here's the thing: none of those words matter on their own. What matters is structure. After writing and testing hundreds of prompts across GPT, Claude, Gemini, and open models, I've found that every prompt that works falls into one of seven patterns. Learn the patterns and you can write a good prompt for any task on any model — without memorizing magic phrases.
This is the guide I wish I'd had when I started.
Pattern 1: Give the model a role
Tell the AI who it's supposed to be. This isn't theater — it loads relevant context into the response.
Weak:
Write a bug report.
Strong:
You are a senior QA engineer who has filed 500+ bug reports. Write a bug report for this issue: [DESCRIBE].
The role "senior QA engineer" pulls in conventions the model knows: repro steps, expected vs actual, severity levels. Without the role, you get a generic description.
When to use it: Always. It's the cheapest improvement you can make.
Pattern 2: Give context and constraints separately
The two most common mistakes are (a) not giving enough context, and (b) burying constraints inside the context so the model ignores them.
Structure your prompt so context and constraints are visually separate:
Context: I'm writing a cold email to a VP of Engineering at a Series B startup. Our product is an AI code reviewer. They just posted about hiring 5 senior engineers.
Constraints:
- Subject line: max 5 words, no capitalization (looks human)
- Body: max 90 words
- No exclamation marks, no "revolutionary," no "game-changer"
- End with a question, not a meeting link
Output: The subject line on its own line, then the body.
Notice how the constraints are a bulleted list. Models follow bulleted constraints far more reliably than constraints buried in a paragraph.
When to use it: Anytime the output needs to follow rules (length, tone, format, banned words).
Pattern 3: Few-shot examples
Show, don't tell. Give the model 1–3 examples of the input → output you want, then give it a new input.
Convert each customer complaint into a structured ticket.
Example 1:
Input: "The app keeps crashing when I upload photos."
Output: {"issue": "crash", "trigger": "photo upload", "severity": "high", "area": "mobile"}Example 2:
Input: "Can't log in, says invalid token."
Output: {"issue": "auth_failure", "trigger": "login", "severity": "high", "area": "auth"}Now convert:
Input: "Took forever to load the dashboard this morning."
Few-shot is the single most reliable way to get consistent formatting. It works because the model learns the pattern from examples better than from description.
When to use it: Whenever you need a specific output format, especially structured data (JSON, tables, tickets).
Pattern 4: Chain-of-thought (but only when it helps)
"Think step by step" became famous because it improves performance on math and logic problems. But it doesn't help — and can hurt — on simple tasks.
Use chain-of-thought when the task has multiple reasoning steps:
A customer's order shipped on Tuesday and was supposed to arrive in 3 business days. Today is the following Monday. They're asking for a refund. Walk through whether they're eligible step by step, considering our policy: [PASTE POLICY]. Then give a verdict.
For simple tasks ("summarize this paragraph"), skip it. Adding "think step by step" to a summary just makes it longer for no benefit.
When to use it: Math, eligibility/logic checks, multi-step decisions, debugging.
Pattern 5: Specify the exact output format
The #1 reason AI output is hard to use: the model decides its own format. Fix this by being explicit.
Output a markdown table with these columns: Tool | Price | Best For | Limitation.
One row per tool. No intro paragraph, no outro paragraph. Just the table.
Or for code:
Output only the function. No explanation before or after. No markdown code fences if I'm pasting into an editor.
The "no intro, no outro" instruction alone will save you from deleting hundreds of words of filler.
When to use it: Always, if you're going to paste the output somewhere. Vagueness costs you editing time.
Pattern 6: Negative constraints (ban the filler)
Models have verbal tics. They love "certainly," "I'd be happy to," "it's important to note," and "in conclusion." You can ban them.
Do not use any of these phrases: "certainly," "I'd be happy to," "it's important to note," "in conclusion," "feel free to," "delve," "robust," "leverage," "seamless."
Do not add an opening or closing paragraph. Start with the content directly.
Negative constraints are powerful because models are predictable about which filler they reach for. Banning the top 5 cleans up most output.
When to use it: Whenever you're editing out filler repeatedly — that's a signal to ban it at the source.
Pattern 7: Iterate — your first prompt is a draft
Nobody writes a perfect prompt on the first try. The process is:
- Write the prompt
- Run it
- Look at the output and ask: what's wrong with it?
- Add a constraint or example that fixes that specific problem
- Run it again
- Repeat until the output is usable
I typically go through 3–5 iterations before a prompt is production-ready. The iteration is the engineering in "prompt engineering."
Pro tip: Save your final prompt in a document. Next time you have a similar task, start from it instead of from scratch. Over a few months you build a personal library that makes you dramatically faster.
Putting it all together: a real example
Here's a prompt that uses all seven patterns at once:
Role: You are a technical writer who simplifies API docs for junior developers.
Context: I'm documenting an endpoint that returns user notifications. The current docs assume the reader knows webhooks. Junior devs don't.
Constraints:
- Max 150 words for the explanation
- Assume the reader has never heard of a webhook
- Include one code example in JavaScript
- Ban these words: "simply," "just," "obviously," "straightforward"
Examples of the tone I want:
Instead of "Simply subscribe to the webhook," write "Tell our server to send you updates by registering a URL."Output: A heading, the explanation, then the code block. No intro or outro.
This prompt works because each pattern handles a different failure mode. The role loads the right conventions. The constraints control length and tone. The example shows the voice. The output format saves editing.
Common mistakes to avoid
- Too long, too early. Don't write a 500-word prompt for a simple task. Start minimal and add constraints only when the output disappoints you.
- Trusting the first output. Always check. Models hallucinate confidently.
- Copy-pasting magic phrases. "Act as a world-class expert" does nothing if the rest of your prompt is vague.
- Skipping the output format. This is the #1 time-waster. Tell the model exactly what shape you want.
These seven patterns are the foundation. Once you internalize them, you stop hunting for "the perfect prompt" and start engineering prompts that work. I've collected the prompts I use most — across writing, coding, marketing, and operations — into a few packs. If you want a tested starting point, the Developer Product-Launch Prompt Pack has 7 prompts you can copy today, and the Developer Productivity Prompt Library has 30 for everyday dev work.
What pattern has made the biggest difference in your prompts? I'm always refining the list.
Top comments (0)