Last updated: 2026-07-13
Prompt engineering is not model-specific magic; it is a small set of reusable structural moves that hold across Claude, GPT, Gemini, and open models because they all read the same signals: clear intent, relevant context, worked examples, explicit output shape, and space to reason. This chapter gives you the ten load-bearing patterns, a single skeleton you can drop any prompt into, and a debugging loop for turning a bad output into a good one. Every technique here is drawn from the current (2026) official guides and the largest empirical prompting survey to date. Treat it as a toolkit, not a checklist: the best prompt is the shortest one that hits your goal reliably, not the longest.
What matters most
- Every strong prompt is assembled from up to six blocks, in this order: role/system framing -> context & motivation -> the task/instructions -> examples -> the data/input -> output-format spec. You rarely need all six; add a block only when its absence causes a failure.
- Order matters. Put long reference material (documents, transcripts, code) NEAR THE TOP, above your instructions, and put the actual question LAST. Anthropic reports this placement alone can improve quality on 20k+ token prompts by up to ~30%.
- Separate the blocks with delimiters so the model never confuses instructions with data. XML-style tags (<instructions>, <context>, <examples>, <input>) are the most portable; markdown headers or triple-backticks also work. This is the single highest-leverage formatting habit.
- Keep 'what' and 'how' in different blocks: requirements in one, tone/style in another, validation steps in a third. Mixing them is the top cause of contradictory instructions that models silently resolve the wrong way.
- Instructions should lead with an action verb and be specific about format, length, and constraints. 'Write a 150-word cold email' beats 'write a short email'; ranges ('3-6 sentences') beat adjectives ('be concise').
- The colleague test: show the prompt to someone with no context. If they'd be confused about what you want, the model will be too.
Common mistakes to avoid
- Don't dump a wall of text with no delimiters and hope the model separates your question from your data — it will often answer the wrong one.
- Don't over-engineer. Applying all six blocks to a one-line task adds noise and can degrade output. Reach for structure only when a plain request fails.
- Don't rely on role alone to fix a vague task — a persona with no concrete instructions still guesses.
- Avoid contradictory system + user instructions (e.g., system says 'always be brief', user asks for a deep dive). The model may pick either; reconcile them or the system rule can sabotage the request.
The short version
- One skeleton fits everything: role -> context -> instructions -> examples -> data -> output-format, with long inputs at the top and the actual question last. Add a block only when its absence causes a failure.
- Delimiters (XML tags) separating instructions from data are the highest-leverage, most portable habit across all models.
- Examples beat descriptions for format/tone/structure; start with one, use 3-5 diverse ones including an edge case, and audit order/quality/balance before adding more.
- Phrase every constraint positively (what TO do), specify the exact output shape, and use prefill to lock format and kill preamble.
- Let the model reason for multi-step tasks, but on reasoning models control depth with an effort parameter and verify — CoT is steerable, not self-proving.
This is one lane of the full system. Get all ten — prompt skeletons, copy-paste templates, worked examples, and the 2026 tool picks — in The AI Creator's Playbook: get the complete 70-page playbook ▸