The Five Techniques Behind Every Good Prompt
Every prompt in this library uses some combination of these five techniques. If you only learn one thing about prompt engineering, learn how to combine them.
Why these five
The prompt-engineering literature has consolidated around a small set of structural moves that, applied together, consistently outperform free-form requests. They show up across coding, marketing, learning, and creative use cases. The 110 prompts in this library are built on top of these.
Each technique below has a description, an example phrase, and links to library prompts where you can see it in action.
1. Role & persona assignment
Start the prompt by telling the AI who it is. A specific role sets vocabulary, expertise level, and what the AI should care about. "You are a senior X" is the most efficient instruction in prompt engineering — three words that shift everything downstream.
Example phrase patterns:
- You are a senior software engineer.Sets technical voice and expertise level for code review or debugging.
- You are a copywriter who has banned "best-in-class" from your vocabulary.A role with a built-in constraint, sharper than a generic "marketer".
- You are a friend who knows that constraints unstick more often than freedom.A role with a posture, not just a job title. Useful for coaching prompts.
See it in: Debug a Stack Trace, Cold Outreach Email, Explain to a Skeptic.
2. Context & constraints
Give the AI the context it needs (audience, goal, format) and the boundaries it must respect (length, tone, banned words). Constraints aren't limitations — they're the thing that makes the output usable instead of generic.
The most powerful constraint is the banned-word list. Listing the specific clichés you don't want ("no 'best-in-class', 'leverage', 'seamless'") cuts more sludge than any positive instruction.
Example phrase patterns:
- Target audience is overworked founders; keep it under 150 words.Combines who and how-long in one sentence.
- Banned words: "amazing", "game-changing", "unlock", "next-level".A specific stop-list. The AI internalizes the pattern, not just the literal words.
- No "I hope this finds you well."Quoting a specific banned phrase rules out a whole class of openers.
See it in: Rewrite Jargon as Plain English, Meeting Recap, Cold Outreach.
3. Chain-of-thought structure
Force the AI to think step by step by giving the response a numbered structure. Each step gets its own section heading, in the order you want them addressed. This drastically reduces logical errors and "I forgot to do X" omissions.
The trick: don't ask for "step-by-step thinking" abstractly. Specify the actual steps, in order, with what each one should produce.
Example phrase patterns:
- Walk me through it in this exact order: 1. … 2. … 3. …Imposes a fixed sequence on the response.
- In this format:Two words that tee up a structured response. Followed by labeled sections.
- Do this: 1. Restate the problem neutrally. 2. Generate hypotheses. 3. Rank them.Names the cognitive moves the AI should make, in order.
See it in: Debug a Stack Trace, Investigate a Metric Anomaly, Weigh the Risks of a Decision.
4. Examples & few-shot patterns
When you want a specific format, register, or style, show the AI 2–5 examples of the input → output you want. Few-shot prompting is the strongest way to mirror a brand voice, enforce a JSON shape, or pin down a tone that's hard to describe in words.
Use it sparingly — examples eat context. But for formatting and voice, two good examples beat ten lines of description.
Example phrase patterns:
- Example — Weak: "Responsible for marketing campaigns." Strong: "Led 6 campaigns, lifting trial signups 34% YoY."A pair of contrasting examples teaches a pattern faster than a rule.
- Here's our voice: [paste 2-3 real posts]. Match this exact tone.Voice is easier to show than to describe.
- Output format example: { "field": "value", "ambiguities": [] }A literal JSON example pins down the shape better than a schema description.
See it in: Resume Bullets (Weak/Strong Pair), Text Extraction (JSON Example), Landing Page Copy (Angle Examples).
5. Self-critique & calibration
Tell the AI to evaluate its own output against your rules before finalizing. Or — more useful — give it permission to push back, mark uncertainty, and tell you what it's guessing about. This single move dramatically reduces hallucination and over-confidence.
The version of this that works best in practice isn't "rate yourself 1-10" — it's calibration tags: marking claims as [observed] / [inferred] / [guessing], or flagging fields with [uncertain].
Example phrase patterns:
- Mark every claim with [observed], [inferred], or [guessing]. Never pretend a guess is a fact.Forces honest hedging at the claim level, not just at the response level.
- If you need a column that isn't in my schema, say so.Permission to push back instead of fabricating.
- Be willing to tell me my draft is too strong. Don't pad with reassurance.Explicit license to disagree. AI defaults to agreeableness; this changes the default.
See it in: Competitive Teardown (Tagged Claims), Interpret Survey Results, Explain to a Skeptic.
How to combine them
Every strong prompt in this library uses at least three of these techniques. The recipe:
- Open with a role that sets posture and expertise.
- Give context and constraints in the next 2–3 sentences.
- Structure the response with a numbered or labeled section list.
- Show one or two examples if the format is unusual.
- End with permission to push back — name what the AI is guessing about, or tell it to say so honestly.
Read any prompt in this library and you'll see this pattern. Browse the full library to see the techniques in 110 concrete contexts.
Andrej Karpathy's notes on coding with LLMs
A companion set of guidelines, this time aimed at the AI itself — how it should behave when working as a pair-programmer. The five techniques above are about writing better prompts; these are about better defaults for the model. They bias toward caution over speed; for trivial tasks, use judgment.
Four guidelines to reduce common LLM coding mistakes:
- 1. Think before coding — don't assume, don't hide confusion, surface tradeoffs. State assumptions explicitly; if uncertain, ask. If multiple interpretations exist, present them — don't pick silently. If a simpler approach exists, say so. If something is unclear, stop, name what's confusing, and ask.
- 2. Simplicity first — minimum code that solves the problem, nothing speculative. No features beyond what was asked. No abstractions for single-use code. No "flexibility" that wasn't requested. No error handling for impossible scenarios. If 200 lines could be 50, rewrite it.
- 3. Surgical changes — touch only what you must, clean up only your own mess. Don't "improve" adjacent code or formatting. Don't refactor things that aren't broken. Match existing style. Remove imports your changes orphaned; don't delete pre-existing dead code unless asked. Every changed line should trace directly to the request.
- 4. Goal-driven execution — define success criteria, loop until verified. "Add validation" → "Write tests for invalid inputs, then make them pass." "Fix the bug" → "Write a test that reproduces it, then make it pass." Strong success criteria let the AI loop independently; weak ones ("make it work") require constant clarification.
Working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.