Let's clear something up before we start.
Prompt engineering is not magic. It's not a career path. It's not dead because models got smarter. It's writing clearly for a specific kind of reader — a statistical language model with strengths and failure modes that are now well understood enough to work with deliberately.
You don't need a framework. You need a handful of reliable patterns. Here are the ones that actually work.
1. Role Priming: Tell It Who It Is
Models respond to context about their role. Not because they "become" that role, but because framing shifts the distribution of likely outputs toward the kind of response that person would give.
Without priming:
Review my code.
With priming:
You are a senior engineer doing a production readiness review. Flag anything that could cause issues at scale, anything with security implications, and anything that would make this hard to maintain in 12 months. Be direct — I don't need encouragement.
The second prompt reliably produces more specific, more critical, more useful output. The role frames what "good" looks like for this task. It also signals tone — "be direct" is a real instruction, not decoration.
Use this any time you want expert-level output rather than general output.
2. Context Before Question
This is the most commonly violated rule in prompting, and fixing it alone will improve your outputs significantly.
Most people write their question first and add context after. Models are reading your prompt in sequence. If you front-load the question, the model starts generating a response trajectory before it has the context that should shape the answer.
Wrong order:
What should I use for rate limiting in my API? It's a Next.js app deployed on Cloudflare Pages with no server, just edge functions.
Right order:
I have a Next.js app deployed on Cloudflare Pages. It uses static export with edge functions — there's no Node.js server, just the Cloudflare edge runtime. Given that constraint, what's the best approach for rate limiting my API routes?
In the second version, the model processes the constraint before arriving at the question. The answer is more likely to account for the Cloudflare-specific limitations from the start, rather than giving a general answer and then hedging.
Front-load context. Ask the question last.
3. Few-Shot Examples: The Most Underused Technique
If you want a specific output format, structure, or style — show an example. One or two examples will outperform even very detailed instructions describing the same thing.
Without examples:
Write a tweet about our new feature launch. Keep it punchy, under 280 characters, with a hook at the start.
With an example:
Write a tweet about our new feature launch. Here's the style we're going for:
"We just shipped dark mode. The light mode tax is over. Update your app."
Same energy, different topic: [your feature here].
The example tells the model exactly what "punchy" means in practice — the sentence rhythm, the declarative tone, the specific word count. Describing that style in words takes much longer and produces less consistent results.
Use examples for: tone, format, length, terminology, structure. Literally anything where "show, don't tell" applies to humans also applies here.
4. Chain-of-Thought for Anything That Requires Reasoning
If your task involves multi-step reasoning, analysis, or decision-making — add "think through this step by step before giving an answer." This single instruction measurably improves output quality on reasoning tasks.
Why it works: it forces the model to generate intermediate reasoning before committing to a conclusion. The conclusion is then constrained by that reasoning, rather than being generated directly. Errors in reasoning become visible and are less likely to compound.
Example:
I need to decide between PostgreSQL and SQLite for my new project. It's a multi-tenant SaaS with up to 500 users per account, and I'm deploying to a single VPS for now. Think through the relevant tradeoffs step by step, then give me a clear recommendation.
Ask for the reasoning. The answer at the end will be better for it.
5. Constrain the Output Format
If you need a specific structure, say so explicitly. Models default to prose unless told otherwise. Prose is often not what you need.
- "Respond in JSON matching this schema:
{ name: string, pros: string[], cons: string[] }" - "Give me a markdown table with columns: Approach | Pros | Cons | When to use"
- "Respond with only the code, no explanation"
- "List the top 5 points. Each point: one sentence. No preamble."
Format constraints do two things. They make output immediately usable without editing. They also force the model to fit its response into a structure, which tends to strip out hedging and padding — both common failure modes in AI-generated prose.
If you're writing code to process the output, always constrain the format. Freeform prose is hard to parse. JSON is not.
6. The Critic Pattern
Generate a response. Then ask the model to critique it. Then ask it to produce an improved version based on the critique.
Step 1:
Write an introduction for a blog post about prompt engineering.
Step 2:
Now critique that introduction. What's weak about it? What's missing? What would make a reader want to stop reading?
Step 3:
Rewrite the introduction addressing those criticisms.
This three-step pattern reliably produces better output than a single-shot request for the best possible version. The reason is that generating and evaluating are different tasks — the model's "editor" and "writer" modes produce different outputs, and separating them captures the benefit of both.
Works especially well for: writing, code review, decision-making, analysis of your own work.
7. Break Complex Tasks Into Explicit Sub-Tasks
A single mega-prompt asking for everything at once is a recipe for mediocre output across all dimensions. Break it up.
Mega-prompt (worse):
Research the competitor landscape, identify our key differentiators, and write a positioning statement for our landing page.
Sub-tasks (better):
- "List the top 5 competitors in this space. For each: their core positioning, their main audience, and one key weakness."
- "Based on [competitor output], what are three ways our product is meaningfully different? Be specific."
- "Write a landing page positioning statement based on differentiator #2. Keep it to two sentences."
Each sub-task is simpler, produces better output, and gives you an intervention point if something goes wrong. If step 2 identifies the wrong differentiator, you can fix it before it cascades into step 3.
Complex tasks have interdependencies. Make those explicit rather than hiding them inside a single prompt.
A Note on Calibration
These patterns work best when calibrated to the model you're using. Modern frontier models — Claude, GPT-4 class and above — don't need as much scaffolding as earlier generations did. Chain-of-thought matters less when the model already reasons well. Role priming matters less when the model defaults to expert-level output.
The value of these techniques is highest when the task is complex, the output format is specific, or the model is less capable. Don't over-engineer prompts for simple tasks on good models. Complexity has a cost — it makes prompts harder to maintain, harder to debug, and harder to iterate.
Start minimal. Add structure when the output quality demands it. Know which lever you're pulling and why.
The Bookmark Version
If you're skimming: here's the list.
- Role priming — tell it who it is and what "good" looks like for this task
- Context before question — front-load constraints, ask last
- Few-shot examples — show the format/style rather than describing it
- Chain-of-thought — ask for step-by-step reasoning on complex tasks
- Format constraints — JSON, tables, lists, character limits — say it explicitly
- Critic pattern — generate, critique, improve
- Sub-tasks over mega-prompts — break complex work into explicit steps
These aren't hacks. They're just clear writing, adapted for how these models actually work. Use the ones that fit your task. Ignore the rest.