Prompt Engineering Cheat Sheet

A vague prompt gets a vague, average answer. Every gap you leave gets filled with the model's guess about what you probably meant — and that guess is rarely the specific thing you had in mind.

Put the actual task first, then list the rules for how to do it. The model locks onto what you're asking for before it has to start filtering how to phrase the answer.

One concrete example of the input/output shape you want teaches the model far more precisely than a paragraph describing that shape in the abstract.

Your first attempt rarely nails a task completely. Read the output, find the specific way it went wrong, and edit the prompt to close that exact gap — don't rewrite from scratch every time.

Framing who the model is speaking as changes its vocabulary and what it treats as obvious versus worth explaining — a senior security engineer and a friendly tutor answer the same question very differently.

The one sentence that states exactly what output you want produced — phrased as an instruction, not a question.

Information the model needs but shouldn't have to guess at: prior conversation, source documents, real-world constraints that shape what a good answer even looks like.

Specify the output shape explicitly. Don't assume the model will default to whatever shape you were picturing — it hasn't seen your picture, only your words.

The boundary conditions: what's off-limits, how long, what tone. Boundaries left unstated get whatever the model's default happens to be, which varies task to task.

For tasks the model has clearly seen many times (summarizing, translating, basic classification), zero-shot is often enough. Every example you add costs context budget and can bias output toward that example's specific style.

Use when the format is unusual or ambiguous enough that a single example removes the guesswork, but the task itself is simple enough that a second example wouldn't teach anything new.

The highest-leverage technique for consistent formatting and tone. The examples teach whatever pattern is common to all of them — including patterns you didn't intend, like always using the same sentence length.

Explicitly asking the model to reason through a problem before answering measurably improves accuracy on multi-step logic, math, and analysis tasks.

Separating reasoning from the final answer — with a clear divider or tag — makes it easy to extract just the answer programmatically, without giving up the accuracy benefit of visible reasoning.

For genuinely ambiguous problems, asking the model to consider multiple approaches before committing surfaces options a single-shot answer would have skipped straight past.

Run the same prompt more than once and compare. For problems with one correct answer, agreement across independent attempts is a strong signal of correctness — disagreement flags a genuinely hard case worth double-checking by hand.

The single most reliable way to get structured, parseable output — pair it with an explicit schema or example. 'Respond in JSON' alone still leaves the shape ambiguous.

Naming the literal headers you want gets far more consistent structure than describing the sections in prose.

XML-style delimiter tags make it trivial to parse out just the part you need from a longer response — and it's a pattern Claude in particular was extensively trained to follow precisely.

For anything you'll parse programmatically, explicitly defining the behavior for missing or inapplicable data prevents a parser from choking on an unexpectedly absent field.

System-level instructions set the persistent frame for the whole conversation and are generally treated as higher-priority than instructions embedded later in a user message. Put durable rules here, not one-off task details.

Mixing 'you are a helpful assistant' with 'today, summarize this specific document' in the same system prompt makes it harder to reuse across different requests. Task-specific detail belongs in the user message.

Explicitly defining the fallback behavior — say you're not sure, versus give your best guess and flag the uncertainty — prevents confident-sounding hallucination on exactly the questions where a shrug would have been more honest.

Instead of one giant prompt trying to research, draft, and polish in a single pass, run three focused prompts in sequence. Each step is easier to verify, and easier to fix independently when something goes wrong.

A second pass ('review the answer above for errors, then provide a corrected version') catches a meaningful fraction of mistakes the first pass made, because critiquing existing text is a different, often easier task than generating it from scratch.

When you're not sure why a prompt isn't working, asking 'how would you rewrite this prompt to get a more reliable answer?' often surfaces the exact ambiguity you missed.

For problems with no single obvious approach, having the model sketch 2-3 strategies and weigh their tradeoffs before picking one avoids committing early to the first idea it happened to think of.

Telling a model what NOT to do (don't be verbose) requires it to first model the thing you don't want in order to avoid it. Stating the positive target directly (answer in 2-3 sentences) is more reliable.

Asking for a response that's both comprehensive and under 50 words forces the model to silently pick one requirement over the other, inconsistently. Resolve the tension yourself before the model has to.

More context isn't automatically better. Irrelevant material competes for the model's attention with the material you actually need it to use, and can measurably reduce accuracy on the parts that count.

Claude was extensively trained on XML-tagged structure, so wrapping distinct parts of a prompt in tags like <document>...</document> tends to produce more reliable adherence than the equivalent instruction written out in plain prose.

If a prompt needs to work across different models or providers, plain markdown structure (##, numbered steps) is the safest common denominator — model-specific conventions don't transfer universally.

Some models expose an extended-reasoning mode that's more reliable and doesn't cost you visible output tokens the way manually requesting 'think step by step' does. Check the model or provider's docs first.