The Prompt Engineering Playbook

Why prompts behave differently from queries

Search engines rank documents that already exist. An LLM generates text autoregressively, one token at a time, sampling from a distribution shaped entirely by what precedes it. That means the prompt is not a filter — it is the only context the model has. Vague prompts produce vague, generic output because the model is filling the gap with probability, not intent.

Three concrete consequences follow. First, the model optimizes for what it can infer from your prompt, not what you meant in your head. Second, the last instruction you give it is weighted heavily, so order matters. Third, format instructions have to be explicit: the model will not guess you want a table, a JSON object, or bullet points unless you say so.

Practical rule: write the prompt the way you would brief a new contractor. Assume they know nothing about your project, your audience, or your house style. If you have to re-read the output and silently correct it, the prompt is under-specified.

The six-slot prompt skeleton

After hundreds of real-world prompts, the pattern that works reliably across GPT-4, Claude, Gemini and local models is a six-part structure. Put them in this order; the sequence is part of why it works.

Role prompting: pick a real job title

The role slot is the cheapest upgrade in the playbook. Models were trained on professional writing, so "act as a senior product manager" pulls a very different vocabulary than "act as an assistant." Use real job titles, not adjectives. "Senior" beats "helpful"; "staff engineer" beats "smart."

Role prompts to avoid

• Generic: "You are a helpful assistant" — gives no useful signal.
• Stacked: "You are a coach and a mentor and a friend" — dilutes the persona.
• Impossible: "You are a real person" — triggers disclaimers in many models.

Role prompts that work

• "Senior UX writer for a finance product"
• "Staff backend engineer evaluating API design"
• "Growth marketer writing LinkedIn posts for indie hackers"

The pattern is specific role + domain + deliverable context. Pick one persona per prompt; mixing personas gives the model permission to waver.

Few-shot prompting: one example beats a paragraph of instructions

Few-shot prompting is the single most effective technique in the playbook. Giving the model one or two ideal outputs is more powerful than describing the format in words. This is because the model is an autocomplete engine: showing it the shape of the completion is a more direct signal than telling it.

Best practices for examples:

• One is usually enough for format tasks; two when the logic is subtle.
• Pick realistic edge cases — an example that handles the tricky input teaches the model the boundary, not just the happy path.
• Keep examples the same style as the desired output. The model copies tone, length, and structure.
• Mark input and output clearly using separators like --- or explicit labels so the model does not confuse them with instructions.

After two examples like that, the model applies the classification to a third input with high accuracy — even when the third input is phrased very differently.

Constraints and negations: tell the model what not to do

LLMs are enthusiastic generators. Without explicit guardrails they add hedging, disclaimers, filler paragraphs, and emoji. Constraints are how you rein that in. Write them as positive and negative pairs.

• Positive: "Write 4-6 bullet points, plain English, no more than 30 words each."
• Negative: "No intro paragraph. No hedging phrases like 'it is important to note.' No emoji."

Negative constraints work, but they are weaker than positive ones. The model is better at following "do this" than "don't do that." Use negations only for things the model habitually adds: disclaimers, introductions, "here is the answer" framing.

Length constraints should be specific numbers, not relative terms. "About 500 words" produces anything from 300 to 800. "Exactly 4 paragraphs of 3-4 sentences each" is much tighter.

Chain-of-thought: ask for reasoning, not just answers

Chain-of-thought prompting asks the model to write out its reasoning before reaching a conclusion. For analysis, ranking, and diagnostic tasks, this is consistently better than a bare answer — the model does not skip steps, so it makes fewer silent errors.

How to request it

Note: you do not need the phrase "think step by step" verbatim. Different phrasings — "show your reasoning," "walk through your analysis before concluding" — achieve the same effect and avoid triggering filters on some models.

When NOT to use chain-of-thought

• Format-heavy tasks (JSON, tables) — reasoning prose will corrupt the output structure.
• Short extractions (dates, entities) — CoT adds tokens without improving accuracy.
• Production API pipelines where you need to parse output deterministically.

For pipeline tasks, separate the reasoning step from the output step. Ask for reasoning in one message, then in a follow-up say "Now give me just the structured output based on your analysis."

Prompting for RAG and context-heavy tasks

When you are feeding the model retrieved documents (RAG), the prompt has one job the general playbook does not: make the model respect the retrieved context and reject answers it cannot support from it.

Three rules for RAG prompts:

• Separate context from question with clear delimiters so the model does not treat retrieved text as instructions.
• Force a "don't know" path — models will hallucinate confidently without it.
• Keep the question separate from the context block to avoid prompt injection from retrieved documents.

Iterative refinement: version your prompts

No prompt is perfect on the first write. The working process is iterative: run the prompt on 3-5 real inputs, check the output, identify the failure mode, and fix one thing at a time. Treat your prompt like code — keep a version history.

Fix one thing per iteration. Changing role, format, and constraints at the same time makes it impossible to know what worked.

Limits and notes

Prompt engineering is not a substitute for a better model or better data. On a complex reasoning task, a well-prompted small model will still lose to a less-prompted large one. The playbook's value is in making prompts reproducible, auditable, and portable across models — so you can upgrade models without rewriting your prompts.

Two caveats worth noting. First, prompt ordering sensitivity varies by model: GPT-style models weight the end heavily, while some models are more front-loaded. Test, don't assume. Second, system messages (when your API supports them) should carry the role and style constraints, while the user message carries the task and context — this separation improves consistency.

See ChatGPT vs Claude: code generation and debugging for how these prompt patterns play out in practice across models, and AI coding assistant: code review workflows for a real prompt used in production code review.