Quick reference
The prompt engineering cheat sheet (2026)
All ten patterns on one page, each in a sentence, with copy-ready examples. Bookmark it, print it, share it. Verified against official documentation.
The ten patterns at a glance
- 01 Be the architect, not the coder Describe the outcome and the constraints. Let the model handle the execution.
- 02 Structure your prompt like a pipeline Order matters: role, context, instructions, examples, then constraints last.
- 03 Give the model a way to check itself Give the model a test or checklist so it catches its own mistakes first.
- 04 Read first, plan second, act last Ask for analysis and a plan before the final output, especially on complex work.
- 05 Respect the context window More text is not better. Keep prompts lean and put key parts first and last.
- 06 Save your rules in a config file Put your standing rules in a persistent file instead of repeating them each time.
- 07 Force structured output when you need it For machine-readable output, use native schema modes; pre-fill helps in chat.
- 08 No single model wins everything Match the task to the model. The same prompt can behave differently across models.
- 09 Let a second pass review the first A separate review pass with fresh context catches what the first one missed.
- 10 Build a playbook that compounds Save what works as reusable prompts and rules so each task improves the next.
Copy-ready examples
01 Be the architect, not the coder
A clear brief
You are writing a short product announcement.
Goal: announce our new CSV export feature to existing users.
Audience: current customers who already use the dashboard.
Must include: what the feature does, how to find it, one line on why it helps.
Constraints: 120-150 words, warm and plain tone, no marketing buzzwords.
Output: the announcement text only, no preamble.02 Structure your prompt like a pipeline
Pipeline template
ROLE
You are a senior technical editor.
CONTEXT
<paste the article or data here>
TASK
1. Identify the three weakest paragraphs.
2. Rewrite each for clarity, keeping the meaning.
3. Keep the author's voice.
EXAMPLE OF GOOD OUTPUT
Before: "Utilize the functionality to..."
After: "Use it to..."
CONSTRAINTS
- Do not change technical facts.
- Return only the rewritten paragraphs, labeled.
- British English.03 Give the model a way to check itself
Built-in self-check
Task: write a function that converts a date string to ISO format.
Requirements (check each before answering):
1. Handles "DD/MM/YYYY" and "MM-DD-YYYY".
2. Returns null for invalid input instead of throwing.
3. Includes 3 test cases covering valid, invalid, and empty input.
Before giving the final code, list each requirement and confirm it is satisfied. If any is not, fix it first.04 Read first, plan second, act last
Phased request
I need to refactor a messy module. Work in three phases and stop after each:
Phase 1 - Read: summarize what this code does and its main problems.
Phase 2 - Plan: propose a refactor approach as a short numbered plan.
Phase 3 - Act: only after I approve the plan, implement it.
Start with Phase 1.05 Respect the context window
Lean over bloated
Instead of pasting an entire 40-page handbook and asking
"summarize the refund policy", paste only the refund section:
CONTEXT (refund policy only):
<paste the 2 relevant paragraphs>
TASK
Summarize the refund policy in 3 bullet points for a customer.06 Save your rules in a config file
A minimal AGENTS.md
# Project rules
Stack: TypeScript, React, Vitest.
Style: functional components, no class components.
Tests: every new function needs a test.
Never: commit secrets, edit files outside /src, add new dependencies without asking.
Done means: code compiles, tests pass, lint is clean.07 Force structured output when you need it
Chat: specify shape + example
Extract the order details as JSON with exactly these keys:
{ "item": string, "quantity": number, "ship_by": "YYYY-MM-DD" }
Rules:
- Return only the JSON object, no commentary.
- If a value is missing, use null.
Order text:
"Need 3 blue mugs shipped before March 2."08 No single model wins everything
A simple routing rule of thumb
Simple, repetitive, high-volume -> fast/cheap model
Hard reasoning, multi-step, code -> deep reasoning model
Long-form writing, tone control -> the model that follows
instructions best for you
Always: test the same task on 2 models before locking it in.09 Let a second pass review the first
A reviewer brief
You are a strict reviewer. You did not write the draft below.
Review it against these requirements:
1. Handles empty input.
2. No security issues (e.g. unvalidated input).
3. Has tests for the main paths.
For each requirement: say PASS or FAIL with one line of why.
Then list the top 3 fixes, most important first.
Draft:
<paste the first output here>10 Build a playbook that compounds
A tiny playbook entry
Task type: summarize a support thread for a manager
Best model: <the one that followed instructions best for you>
Prompt template:
ROLE: you summarize support threads for busy managers
TASK: 5 bullets max, lead with the customer's core issue,
end with the current status
CONSTRAINTS: no jargon, under 90 words
Why it works: tight format + clear audience = consistent outputLast verified: June 2026