Prompt Engineering General Techniques Cheatsheet - Role/Structure/Constraints/CoT
Few things in prompt engineering transfer cleanly across models and vendors, but the ones that do are simple: state the identity, pin the output structure, replace vague wording with countable quantities, expand the reasoning, and make the model check its own work. This sheet is organised into role anchoring, structured output, constraints and few-shot, chain of thought with verification, and pitfall avoidance; nothing here is vendor-specific and all of it survives a switch to Claude or Gemini. Reach for it when a long prompt still produces unstable output, which is almost always a missing decidable constraint rather than missing length - "write it professionally" cannot be checked, "under 200 words, no lists" can. A second signal is that the same prompt yields different results across runs, which points to unwritten boundary conditions rather than model randomness. The cheapest way to know whether a pattern works is to freeze it and reuse it: what reproduces reliably is a pattern, what occasionally succeeds is luck.
Role Anchoring 5
You are a senior {domain} expert (10+ yrs); answer professionally but clearly: {q}As a {role}, complete per {spec}: {task}Identity={role}; Goal={goal}; Constraints={c}. Start: {input}From a {role} view, give 3 differing opinions with reasoningAssume you are a {job} in {scene}; give full steps for {problem}Structured Output 5
Output JSON with fields name/desc/tags. JSON only, no prose. Text: {t}Compare A vs B in a Markdown table: perf/usability/ecosystem/costOutput as ## heading / ### sub / - bullets. Topic: {t}Strictly follow this JSON Schema, no prose: {schema}Break the req into a checklist: task/priority/effort. Req: {r}Constraints & Few-shot 5
Ex1: X→Y; Ex2: A→B. New: {input}Length ≤200 words; pro tone; no lists; in ChineseUse only the provided material; no outside knowledgeConclusion first, ≤3 reasons, then one counterexampleNo apologies/small talk unless needed; answer directlyCoT & Verification 5
Think step by step, then give the final answerList all assumptions, then derive, then flag uncertaintyAfter answering, self-check 3 possible errors and fixIf info is insufficient, say what is missing — do not guessArgue against your conclusion, then synthesizePitfalls 5
Swap vague for specific ("a few" → "3 points")Split long tasks, then ask step by stepAsk for cited rationale on important outputRun the same prompt a few times for stabilitySave winning prompts as reusable templatesTips
- The core of prompt engineering is translating vague intent into instructions the model executes reliably — role, structure, constraints, and CoT cover most scenarios.
- Few-shot sets format better than long descriptions; explicit constraints (length/tone/prohibitions) beat "be concise" — models respond more to concrete numbers and negations.
- Chain of Thought lifts reasoning quality but costs tokens; add a self-verification loop on important output to cut hallucination and misjudgment.
- Bank verified prompts as reusable templates — steadier and faster than writing ad hoc each time.
FAQ
Why is an instruction like "be concise" unreliable?
Concise has no verifiable criterion, so the model's interpretation drifts with context. Replace it with something checkable: "within 200 words", "at most 3 bullet points", "no summary, lead with the conclusion". Any requirement that reduces to a number or an explicit format beats an adjective. Likewise "be more professional" is weaker than naming the audience: "for backend engineers, skip explaining terminology".
How do I reduce fabricated citations?
Set a boundary rather than expressing hope: state "use only the material provided below, do not introduce outside knowledge", and add "if information is insufficient, say exactly what is missing rather than guessing". Together these cut hallucination sharply. Add "cite a source for important claims" so each conclusion traces back to your material. The key is giving it a legitimate way to say it does not know, instead of forcing an answer.
How do I deal with inconsistent results across runs?
That is sampling randomness and is normal. Three approaches when consistency matters: save prompts that worked as templates rather than rewriting each time; reduce the output's degrees of freedom by fixing the structure and listing required elements; and ask for self-checking, e.g. "after answering, check 3 possible errors and correct them". If it remains unstable, move the critical criteria out of the prompt and validate them in code.
Why should a prompt avoid cramming too much in?
When a large task arrives in one go the model spreads attention thin and output quality degrades. Split it: ask for a plan or outline first, confirm the direction, then execute step by step. Each step then has focused context, and problems surface mid-way when they are still cheap to fix — rather than after you have a fully derailed result.
How do I make prompt results more consistent?
Replace vague words with specific verifiable ones: "a few points" becomes "3 points", "brief" becomes "within 200 words", "professional" becomes "for backend engineers, skip explaining terminology". Save prompts that worked as templates instead of rewriting them. If variance remains, move the critical criteria out of the prompt into code so determinism comes from the program, not the model.
Official References
Each command links to its official documentation below, so you can verify the latest usage and read deeper.
Maintained by LaoHand
Publicly updated on Aug 23, 2026, continuously proofread against official docs.
Contact Us
Wrong command or description? Send us corrections, business inquiries or product feedback by email.
Contact Us