Prompt design techniques for LLMs: structure, examples, reasoning patterns, and optimization. Invoke whenever task involves any interaction with AI instructions โ crafting, debugging, improving, or evaluating prompts for skills, agents, output styles, or system configurations.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
The command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
File Explorer
15 files
Showing SKILL.md
SKILL.md
Source instructions ยท Read-only preview
name
prompt-engineering
description
Prompt design techniques for LLMs: structure, examples, reasoning patterns, and optimization. Invoke whenever task involves any interaction with AI instructions โ crafting, debugging, improving, or evaluating prompts for skills, agents, output styles, or system configurations.
Prompt Engineering
Every prompt is an interface contract โ clarity of intent determines quality of output. Apply when crafting skills,
agents, output styles, system prompts, or any AI instructions.
Read first when
You are writing a prompt for another model (skill, subagent, system prompt, agent instruction, output style) โ
load [${CLAUDE_SKILL_DIR}/references/agent-authored-prompts.md] BEFORE drafting. Agent-authored prompts have
distinct failure modes (over-specification, context leakage, ambiguous output contracts, silent degradation across
pipeline stages) that the diagnostic table below does NOT cover. The summary in
Writing Prompts as an Agent is incomplete โ the reference holds the workflow.
What's Wrong With Your Prompt?
Wrong format โ add explicit format + example. See Output Format
Missing information โ be more specific about what to include. See Be Specific
Hallucination โ add context, request citations. See Provide Context
Ignores instructions โ place critical rules at top and end, use XML tags. See
Persistent Context
Complex reasoning fails โ use extended thinking or CoT. See Reasoning
Inconsistent results โ add 3-5 examples. See Examples
โ specify word/sentence limits. See
**Original prompt:**
```
You are a helpful assistant. Analyze this code and give me feedback.
Make sure to be thorough. Also format it nicely.
```
Persistent context โ [${CLAUDE_SKILL_DIR}/references/persistent-context.md] Technique transfer to skills/system
prompts, instruction degradation research, format sensitivity, declarative vs procedural, U-shaped attention,
minimalism principle
Structured data formats โ [${CLAUDE_SKILL_DIR}/references/structured-data-formats.md] Format benchmarks (KV vs
table vs YAML vs JSON), TOON verdict, output format restrictions, CFPO, format selection rules
Start with the simplest technique that fits the problem. Most issues are solved by the first three.
Be Clear and Direct
The golden rule: show your prompt to a colleague with minimal context. If they're confused, Claude will be too.
Provide Context
Tell Claude:
What the task results will be used for
Who the audience is
What success looks like
Be Specific
"Summarize this" โ "Summarize in 3 bullets, each under 20 words"
"Make it better" โ "Fix grammar errors, reduce word count by 30%"
"Analyze the data" โ "Calculate YoY growth, identify top 3 trends"
Output Format
Always specify format explicitly. Show an example if structure matters:
Extract the following as JSON:
- Product name
- Price (number only)
- In stock (boolean)
Example output:
{"name": "Widget Pro", "price": 29.99, "in_stock": true}
Use Examples (Few-Shot)
3-5 examples typically sufficient. Cover edge cases. Format consistency and input distribution matter more than perfect
label accuracy. Performance plateaus after 8-16 examples.
On current frontier models, examples constrain as much as they teach. Worked examples anchor the model to the
demonstrated paths and narrow its exploration space โ use them to pin format and style, not to demonstrate behavior the
model already handles. For tool and agentic behavior, prefer interface design over usage examples: expressive parameter
names, enums, and constraints in the tool definition (a status enum of pending | in_progress | completed plus "keep
exactly one item in_progress") define the behavior without spending example tokens.
Example selection rules:
Cover diversity โ represent different categories, edge cases, styles
Order simple to complex โ build understanding progressively
Balance output classes โ equal representation across categories
Put representative examples last โ recency bias makes later examples more influential
Prioritize format consistency over perfect labeling
Wrap in <examples> tags for clear separation
In system context, examples at the start outperform those placed later (primacy bias)
Choosing the right paradigm:
Simple, well-known task โ zero-shot (just ask)
Need specific output format โ one-shot (1 example)
Extended paradigm details and ICL theory: see [${CLAUDE_SKILL_DIR}/references/learning-paradigms.md].
Use XML Tags
Separate components for clarity and parseability:
<instructions>
Analyze the contract for risks.
</instructions><contract>
{{CONTRACT_TEXT}}
</contract><output_format>
List risks in <risks> tags, recommendations in <recommendations>.
</output_format>
Use consistent tag names throughout the prompt
Reference tags in instructions: "Using the contract in <contract>..."
Nest for hierarchy: <outer><inner>...</inner></outer>
Critical for multi-component prompts โ significantly improves instruction following
Reasoning
For complex reasoning, ask Claude to show its work:
Think through this in <thinking> tags.
Then provide your answer in <answer> tags.
Critical: Claude must output its thinking. Without outputting the thought process, no thinking actually occurs.
These models reason internally โ do NOT add "think step by step" (it's redundant and may degrade quality)
Prefer general instructions ("think thoroughly") over prescriptive step-by-step plans
Use <thinking> tags in few-shot examples to demonstrate desired reasoning style
Ask for self-verification: "Before finishing, verify your answer against [criteria]"
Use the effort parameter to control reasoning depth, not prompt-level CoT
Standard models (no native reasoning):
Use explicit CoT when the problem requires multi-step reasoning
Use extended thinking when the problem requires exploring multiple approaches
Use neither for simple factual tasks
CoT trade-off: helpful for structural formatting and complex logic; harmful for tasks with many mechanical
constraints (word limits, format rules).
Detailed techniques, ToT, self-consistency: see [${CLAUDE_SKILL_DIR}/references/reasoning-techniques.md].
Use Sequential Steps
For multi-step tasks, number the steps:
1. Replace customer names with "CUSTOMER_[ID]"
2. Replace emails with "EMAIL_[ID]@example.com"
3. Redact phone numbers as "PHONE_[ID]"
4. Leave product names intact
5. Output only processed messages, separated by "---"
Cap at ~10-15 steps per sequence; beyond that, decompose into sub-procedures (Hierarchical Task Networks).
Structured Data in Prompts
Format choice measurably affects LLM accuracy โ up to 16pp between best and worst formats on identical content.
Key-value lists for lookup/routing data where entries are independent โ +8.8pp accuracy over tables
Markdown tables only for genuinely 2D comparisons where cross-criteria scanning IS the point
YAML for deeply nested data (configs, hierarchies) โ best accuracy for nested structures
Avoid CSV, JSONL, XML for input data โ consistently underperform alternatives
Test: if removing a column would lose comparative meaning โ table. Otherwise โ KV list.
Output format restrictions degrade reasoning. Use structured output only when downstream consumers require it;
prefer post-processing free-form output for reasoning-heavy tasks.
Full benchmarks and selection rules: see [${CLAUDE_SKILL_DIR}/references/structured-data-formats.md].
Choosing a Technique
Simple task, clear format โ zero-shot with clear instructions
Consistent output format โ few-shot (3-5 examples)
Very complex / exploratory โ extended thinking with high effort
Multi-step workflow โ prompt chaining. See [${CLAUDE_SKILL_DIR}/references/workflow-patterns.md]
External information needed โ ReAct. See [${CLAUDE_SKILL_DIR}/references/agent-patterns.md]
Precise calculation โ PAL (generate code). See [${CLAUDE_SKILL_DIR}/references/agent-patterns.md]
Multi-attempt allowed โ Reflexion. See [${CLAUDE_SKILL_DIR}/references/agent-patterns.md]
Worked Example: Diagnosing and Fixing a Prompt
Diagnosis:
Wrong format โ no explicit format specified
Missing information โ "feedback" and "thorough" are vague
Ignores instructions โ "format it nicely" is ambiguous
Fixed prompt:
<instructions>
Review the provided code for three categories of issues:
1. Bugs โ logic errors, off-by-one, null handling
2. Security โ injection, auth bypass, data exposure
3. Performance โ unnecessary allocations, O(n^2) loops
</instructions><output_format>
For each issue found, return:
- **Location:** file:line
- **Category:** Bug | Security | Performance
- **Severity:** Critical | Major | Minor
- **Fix:** concrete code change (not just description)
If no issues found in a category, state "None found."
</output_format><code>
{{CODE}}
</code>
What changed: vague task โ specific categories. No format โ explicit structure. Persona removed (adds no value).
Single paragraph โ XML-separated components.
Prompting in Persistent Context
Techniques behave differently in persistent context (skills, system prompts, CLAUDE.md) vs. one-shot user messages.
Place critical rules at top and end of context. The U-shaped attention curve makes the middle the worst location.
Prefer declarative bullets over numbered procedures โ except when ordering matters; cap sequences at ~10-15 steps.
Prime the domain, don't assign a persona. "This is a security review task" beats "You are an expert auditor."
Format swings compliance up to 40%. XML tags and Markdown headers beat prose; JSON/YAML are for data, not
instructions.
Every instruction must earn its place. Apply the deletion test: if removing it doesn't change output, remove it.
Full research synthesis: see [${CLAUDE_SKILL_DIR}/references/persistent-context.md].
Claude-Specific Rules
Adaptive Thinking and Effort
Current Claude models (Opus 4.7+, Sonnet 5, Fable 5) use adaptive thinking โ the only thinking mode; Claude
dynamically determines when and how deeply to reason:
effort levels:low, medium, high (default), xhigh (best for hard coding/agentic work), max
Effort affects all tokens: text, tool calls, and thinking; raise effort rather than prompting around shallow reasoning
Defaults when thinking is omitted: Fable 5 always thinks (omit the param; disabled returns 400); Sonnet 5 runs
adaptive; Opus 4.7/4.8 run without thinking
budget_tokens returns 400 on current models โ use effort + adaptive thinking
Thinking display defaults to omitted โ set display: "summarized" if reasoning is surfaced to users
Prefilling (removed)
Prefilling a partial assistant message returns a 400 on Claude 4.6+ and Fable 5 (legacy models only). Migrate:
Place breakpoint on the last block that stays identical across requests
Cache invalidation hierarchy: tools โ system โ messages
Structured Outputs
Constrained decoding guaranteeing schema-compliant JSON. Use output_config.format for response format or
strict: true on tool definitions. Incompatible with citations and prefilling. Grammar applies only to final text
output โ thinking is unconstrained.
Model-Specific Behavior
Behavioral defaults (verbosity, tool eagerness, subagent use, design taste) shift per model release โ techniques
transfer, defaults don't. When tuning for a specific model, first remove prior-model scaffolding (it overtriggers on
newer models), then check the model's own prompting guide. Per-model profiles and steering patterns: see
[${CLAUDE_SKILL_DIR}/references/model-behavior.md].
Full API details and technique combinations: see [${CLAUDE_SKILL_DIR}/references/claude-specific.md].
Context Engineering
Context engineering is the 2026 evolution beyond prompt engineering โ designing dynamic systems that provide the right
information and tools, in the right format, at the right time.
Key distinction: prompt engineering crafts a single text string; context engineering manages all inputs to the model
โ system prompts, conversation history, retrieved documents, tool results, memory.
Core principles:
Most agent failures are context failures, not model failures
Find the smallest set of high-signal tokens that maximizes the desired outcome
Treat context as a finite resource with diminishing marginal returns
Organize context into explicit labeled sections for model parseability
Management patterns:
Compaction โ summarize nearing-limit context; preserve decisions and open questions, discard raw tool outputs
Structured note-taking โ agent writes selective notes to persistent storage for state continuity
Multi-agent isolation โ sub-agents handle deep dives in clean contexts; return condensed summaries
Just-in-time retrieval โ load identifiers upfront, fetch full content on demand via tools
Full depth: see [${CLAUDE_SKILL_DIR}/references/context-engineering.md].
Long Context Rules
When working with 20K+ token documents:
Documents at the top, query at the bottom โ exploits the U-shaped attention curve
Wrap each document in XML tags with identifying metadata (source, type, date)
Ground responses in quotes โ ask Claude to quote relevant passages before answering
Remove noise before including documents โ strip boilerplate, headers, navigation
Place instructions at the end after all documents
Document organization, chunking strategies: see [${CLAUDE_SKILL_DIR}/references/long-context.md].
Prompt Chaining Rules
When a single prompt produces error propagation, decompose into a chain of simpler prompts:
Single responsibility โ each prompt does one thing well
Clear interfaces โ define what each step receives and produces
Validation points โ check output before passing to next step
Chain when there's a natural validation boundary โ avoid over-chaining
Chain topologies, meta prompting, APE: see [${CLAUDE_SKILL_DIR}/references/workflow-patterns.md].
When Prompting Isn't Enough
Start with prompt engineering. If quality plateaus, consider:
RAG โ need current/accurate external data the model doesn't have
DSPy โ metric-driven automatic prompt optimization for complex pipelines with labeled eval data
Fine-tuning โ need deep domain expertise prompting can't achieve
These compose โ combine as needed. Treat prompts as software: version them, test them, monitor them in production.
Strategy comparison, DSPy details, production quality gates: see
[${CLAUDE_SKILL_DIR}/references/optimization-strategies.md].
Security Rules
When a prompt handles untrusted input (user-provided content, web scraping, external documents):
Mark trust boundaries โ separate trusted instructions from untrusted data with delimiters
Harden the system prompt โ explicit boundaries, sandwich defense (repeat critical instructions after user content)
Validate input โ flag instruction-override patterns, unusual length, encoding attempts
Filter output โ block responses containing sensitive data patterns
Apply least privilege โ give the LLM access only to data and tools it needs
Require human approval for sensitive or destructive actions
Prompt injection cannot be fully prevented โ defense is about reducing attack surface, limiting blast radius, and
detecting incidents.
OWASP Top 10, attack taxonomy, defense patterns: see [${CLAUDE_SKILL_DIR}/references/security.md].
Writing Prompts as an Agent
STOP โ load [${CLAUDE_SKILL_DIR}/references/agent-authored-prompts.md] before drafting. The summary below is
orientation only; the reference holds the decomposition workflow, failure-mode taxonomy, and pipeline rules required to
write a non-broken agent prompt.
When you (the AI) are authoring a prompt for another model to execute โ skills, system prompts, subagent instructions:
Treat prompts as programs โ define signature (inputs, outputs, success criteria) before writing text
Decompose into components, scaffold with XML, then draft
Every generated prompt must be self-contained โ the receiving agent has zero knowledge of your context
Include explicit output format with a concrete example, not just a description
Embed validation criteria the receiving agent can self-check against
Sanitize all user-supplied content before incorporating into generated prompts
