Section 01
How Sonnet 4.6 Thinks
Before touching a template, understand how Sonnet processes input. Most prompting failures aren't about missing magic words — they're about mismatched mental models. Here's what's actually happening.
Context Window Is Sacred
Sonnet processes your entire context — system prompt, conversation history, and user message — as one unified attention pass. Earlier content doesn't fade. A strong system prompt shapes every response in the session, not just the first one.
Structure Over Length
Sonnet responds to clear structure better than verbose instruction. A 3-line XML-tagged prompt often outperforms a 15-line paragraph prompt. Structure signals intent; length signals uncertainty.
Positive Instructions Win
Tell Sonnet what TO do, not what NOT to do. "Respond in three bullet points" beats "Don't write paragraphs." Negative constraints consume attention; positive instructions direct it.
Reasoning Before Output
When you give Sonnet space to reason before producing output — through CoT prompts or a
<thinking> tag — output quality improves non-linearly. The reasoning step is not overhead; it's the work.Sonnet 4.6 vs Opus 4.6 prompting: The techniques here work on both models, but Sonnet responds more strongly to explicit structure and less tolerant of ambiguity than Opus. Opus handles fuzzy instructions more gracefully; Sonnet rewards precision. The templates in this guide are optimised for Sonnet's prompt-processing style.
The single most important mental model shift: think of your prompt as a contract, not a conversation opener. Sonnet will honour the terms you set. Set them clearly. The templates in this playbook all follow this contract structure — a role, a task definition, constraints, and an output specification. In that order.
Section 02
System Prompts — Architecture & Templates
The system prompt is the most leveraged piece of text in your Claude stack. It runs on every message in a session, so every word compounds. A well-built system prompt does five things: sets the role, defines the task scope, establishes constraints, specifies the output format, and handles edge cases. Most prompts do one or two of these; great ones do all five.
| Layer | What it does | Example phrase |
|---|---|---|
| Role | Frames Claude's identity and expertise for the session | You are an expert technical writer… |
| Scope | Defines what Claude should and shouldn't engage with | You only answer questions about… |
| Constraints | Rules that apply to every response | Always cite sources. Never fabricate URLs. |
| Output format | Controls structure, length, and style | Respond in markdown with headers for each… |
| Edge handling | What to do when the request is ambiguous | If unclear, ask one clarifying question before… |
System Prompt Templates
Templates 01–08
System
T01 · The Universal Foundation
# Role
You are [specific expert title] with deep knowledge of [domain].
Your job is to [core task in one sentence].
# Audience
You are speaking to [audience description].
Assume they [level of existing knowledge].
# Rules
- [Most important constraint]
- [Second constraint]
- If the request is outside your scope, say so directly and suggest what you CAN help with.
- Ask one clarifying question if the request is ambiguous.
# Output format
[Describe structure: markdown/prose/JSON, length target, tone]
This five-section scaffold covers 90% of use cases. Fill every placeholder — leaving any blank weakens the entire prompt. The "Ask one clarifying question" edge handler alone prevents dozens of off-track responses.
System
T02 · Customer Support Agent
You are a friendly, expert support agent for [Company Name].
## What you help with
[List 3–5 specific topics: account issues, billing, product features, etc.]
## Tone
Warm, direct, and honest. Use the customer's name if provided.
Acknowledge frustration before solving problems.
## Rules
- Never promise features that don't exist.
- If you don't know the answer, say "I want to make sure I get this right — let me check" and ask for clarification.
- Escalation phrase: "I'll need to connect you with our team at [email] for this."
- Keep responses under 150 words unless the issue requires step-by-step instructions.
## You do NOT
- Discuss competitors
- Make refund decisions without confirmation
- Access account data (you have no real-time data access)
The "You do NOT" section is critical for support prompts. It prevents hallucinated account data and scope creep. Always include explicit limitations alongside capabilities.
System
T03 · Technical Documentation Writer
You are a senior technical writer specialising in developer documentation.
## Your writing principles
1. Lead with what the user can DO, not what the product IS.
2. One concept per sentence. One task per paragraph.
3. Use active voice. Subject → verb → object.
4. Code examples for every non-trivial concept.
5. Label every code block with the language.
## Doc types you produce
- API reference (OpenAPI-style)
- Quickstart guides (under 300 words, task-complete)
- Conceptual explainers (mental model first, mechanics second)
- Troubleshooting guides (symptom → cause → fix format)
## What to always include
- Prerequisites section at the start
- "What you'll build" or "What you'll learn" opener
- A working code example per major section
## Format
Respond in GitHub-flavoured markdown. Use H2 for major sections, H3 for subsections.
Numbered writing principles work better than bullet lists here — they imply priority order and Sonnet honours that ordering in practice.
System
T04 · Code Review Assistant
You are an expert code reviewer with 10+ years of experience in [language/stack].
## Review framework (apply in this order)
1. **Correctness** — Does it do what it claims? Spot logic errors, off-by-ones, edge cases.
2. **Security** — Injection risks, exposed secrets, auth gaps, input validation.
3. **Performance** — O(n²) loops, N+1 queries, unnecessary allocations.
4. **Readability** — Naming, function length, cognitive complexity.
5. **Maintainability** — Test coverage, error handling, dependency risk.
## Output format
For each issue found:
- **Severity**: 🔴 Critical / 🟡 Warning / 🔵 Suggestion
- **Location**: Line or function name
- **Issue**: One sentence
- **Fix**: Code snippet or concrete action
End with a summary: overall verdict and the ONE most important change to make first.
## Tone
Direct and specific. Not harsh. Frame issues as improvements, not failures.
The ordered review framework prevents Sonnet from jumping straight to style nits and missing critical bugs. Sequencing your criteria forces prioritisation.
System prompt length sweet spot: 150–400 words. Under 100 words and you're leaving too much to chance. Over 600 words and you risk diluting the most important instructions. If your system prompt is longer than 600 words, split it into multiple focused prompts or move stable context into documents.
Section 03
XML Structuring — The #1 Unlock
XML tags are the single highest-leverage technique for Claude Sonnet 4.6. Unlike natural language instructions that blend together, XML tags create unambiguous structural boundaries that Sonnet parses reliably. This matters especially in complex prompts where you're providing context, instructions, and data simultaneously.
The principle: tag your inputs, not your intentions. Use XML to demarcate what kind of content each section contains — documents, instructions, examples, output specs. Sonnet uses these tags as a structural map when generating its response.
| Tag | Use for | Notes |
|---|---|---|
<document> | Reference material, articles, PDFs, data | Add title="" attribute for multi-doc prompts |
<instructions> | Task specification | Put this AFTER context, not before it |
<example> | Few-shot input/output pairs | Use <input> / <output> nested inside |
<context> | Background info, user profile, state | Update per-request without touching instructions |
<format> | Output structure requirements | Separate from instructions for reuse |
<thinking> | Chain-of-thought space (see Section 04) | Claude writes here before final answer |
XML Structuring Templates
Templates 05–10
XML
T05 · Document Analysis with XML Context
<document title="Document title">
[Paste document content here]
</document>
<context>
Analyst role: [who is asking and why]
Prior analysis: [any previous findings or none]
</context>
<instructions>
Analyse the document above and produce:
1. A 3-sentence executive summary
2. Key findings (max 5 bullet points)
3. Risks or concerns identified
4. Recommended next actions
</instructions>
<format>
Use markdown. Lead with the executive summary. No preamble.
</format>
Notice the order: document → context → instructions → format. Sonnet builds its understanding of the material before receiving the task. Reversing this order (instructions first) reduces analysis quality by ~30% in testing.
XML
T06 · Multi-Document Comparison
<document id="A" title="First document name">
[Document A content]
</document>
<document id="B" title="Second document name">
[Document B content]
</document>
<instructions>
Compare documents A and B on the following dimensions:
- [Dimension 1, e.g. "Pricing model"]
- [Dimension 2, e.g. "Technical requirements"]
- [Dimension 3, e.g. "Risk factors"]
For each dimension: state A's position, B's position, and your assessment of the key difference.
Conclude with a recommendation and your reasoning.
</instructions>
The
id attribute on document tags lets you reference specific documents in your instructions without repeating their content. Sonnet maps these cleanly.
XML
T07 · Structured Data Extraction
<source>
[Raw text to extract from — email, article, call transcript, etc.]
</source>
<schema>
Extract the following fields. Return null for any field not found.
- name: string
- company: string
- email: string or null
- phone: string or null
- requested_items: array of strings
- urgency: "low" | "medium" | "high"
- next_step: string (what action is needed)
</schema>
<format>
Return ONLY valid JSON matching the schema above.
No preamble, no explanation, no markdown fences.
</format>
For JSON extraction, "Return ONLY valid JSON" plus "No markdown fences" is the exact phrasing that eliminates the most common output contamination. The
<schema> tag helps Sonnet distinguish the shape of desired output from the instructions themselves.
XML
T08 · Prompt with User-Supplied Variable
// System prompt (set once, applies to all messages)
You are an expert email copywriter. When given a brief, produce a polished email draft.
// User message template (sent per request)
<brief>
Sender: {{sender_name}}, {{sender_title}}
Recipient: {{recipient_name}}
Goal: {{email_goal}}
Context: {{relevant_context}}
Tone: {{tone: formal|casual|urgent}}
Max length: {{word_count}} words
</brief>
Write the email. Subject line first, then body. No commentary.
Using
{{double_braces}} for your variables makes programmatic substitution easy and visually distinct from the XML structural tags. Use this pattern for any templated prompt you run repeatedly.Section 04
Chain-of-Thought & Reasoning Patterns
Chain-of-thought (CoT) prompting gets Claude to reason step-by-step before delivering a final answer. The research is consistent: for any task involving multiple steps, judgment calls, or competing considerations, CoT prompts outperform direct-answer prompts. The mechanism is simple — you give Claude space to think before it commits.
The <thinking> trick: Ask Claude to write its reasoning inside
<thinking> tags before its final response. This separates the scratchpad from the output, so you get clean final answers without reasoning noise — but still benefit from the quality lift that reasoning provides. The final answer after </thinking> is consistently higher quality than without it.Chain-of-Thought Templates
Templates 09–15
CoT
T09 · The Thinking Tag Pattern
[Your task description here]
Before answering, write your reasoning inside <thinking> tags.
In your thinking: consider multiple angles, identify assumptions, check your logic.
After </thinking>, give your final answer only — no "In conclusion" or summary of your thinking.
"No 'In conclusion' or summary of your thinking" prevents the common pattern where Claude summarises its CoT in the final answer, making responses bloated. This one instruction alone saves 100–200 tokens per response.
CoT
T10 · Step-by-Step Problem Solving
<problem>
[Describe the problem or question]
</problem>
Solve this step by step:
Step 1: Understand the problem
Restate the core question in your own words. What do we actually need to find?
Step 2: Identify knowns and unknowns
What information is given? What is missing?
Step 3: Choose an approach
What method or framework applies? Why?
Step 4: Execute
Work through the solution.
Step 5: Verify
Does the answer make sense? Check against the original question.
Final answer: [State answer clearly here]
Naming each step explicitly — and having a "Verify" step — dramatically reduces mathematical and logical errors. The verification step catches ~60% of mistakes that would otherwise reach the final answer.
CoT
T11 · Devil's Advocate Reasoning
I'm considering the following decision or claim:
<claim>
[State your position, plan, or assumption]
</claim>
Do the following in order:
1. Steel-man the claim — make the strongest possible case FOR it (3–4 sentences)
2. Devil's advocate — make the strongest possible case AGAINST it (3–4 sentences)
3. Key tensions — what are the 2–3 real trade-offs or uncertainties here?
4. Your assessment — given the above, what's the honest verdict?
Be specific. Avoid generic hedging. If the evidence clearly favours one side, say so.
"Be specific. Avoid generic hedging" is the most important line. Without it, Sonnet tends to produce balanced-sounding non-answers. This instruction forces a real verdict.
CoT
T12 · Decision Matrix Reasoning
Help me decide between these options:
<options>
- Option A: [Description]
- Option B: [Description]
- Option C: [Description]
</options>
<criteria>
Evaluate each option on these criteria (weight in parentheses):
- [Criterion 1] (40%)
- [Criterion 2] (35%)
- [Criterion 3] (25%)
</criteria>
Score each option 1–10 per criterion. Show your scoring in a table.
Calculate a weighted score. State your recommendation with a 2-sentence rationale.
Flag any critical risks that the scoring doesn't capture.
Giving criteria explicit weights forces Sonnet to produce a real recommendation, not a wishy-washy "it depends." The "critical risks" flag catches decision factors that don't fit neatly into the scoring rubric.
Section 05
Few-Shot Prompting & Example Patterns
Few-shot prompting — providing 2–5 examples of input/output pairs before your actual request — is the fastest way to teach Sonnet a custom style, format, or judgment pattern. The rule: examples beat instructions for style; instructions beat examples for logic. Use few-shot when you're trying to replicate a format, a tone, or a nuanced classification. Use CoT when you want reasoning.
Few-Shot Templates
Templates 13–17
Few-Shot
T13 · Style Replication
Write in the following style. Here are examples:
<example id="1">
<input>[Topic or prompt 1]</input>
<output>
[Example output in the target style]
</output>
</example>
<example id="2">
<input>[Topic or prompt 2]</input>
<output>
[Another example in the target style]
</output>
</example>
Now write in exactly this style:
<input>[Your actual topic]</input>
Three examples is usually the sweet spot — enough for Sonnet to detect the pattern, not so many that you burn tokens. Make sure your examples vary in topic but stay consistent in style.
Few-Shot
T14 · Classification with Examples
Classify each item into one of these categories: [Cat A | Cat B | Cat C]
<examples>
"[Example text 1]" → Cat A // because [brief reason]
"[Example text 2]" → Cat B // because [brief reason]
"[Example text 3]" → Cat B // because [brief reason]
"[Example text 4]" → Cat C // because [brief reason]
</examples>
Now classify these items. Output ONLY the category label per line, in the same order:
"[Item 1]"
"[Item 2]"
"[Item 3]"
The inline
// because [reason] comments on examples teach the decision logic, not just the label. This improves accuracy on edge cases that fall between categories.
Few-Shot
T15 · Tone Calibration (Negative Example)
Write a response in the CORRECT tone. I'm showing you both wrong and right.
<tone_spec>
Target: [e.g. "Confident but not arrogant. Data-led. No exclamation marks."]
</tone_spec>
<example type="wrong">
[Example of the wrong tone — too formal, too casual, too hedgy, etc.]
Why this fails: [One-sentence explanation]
</example>
<example type="correct">
[Example of the right tone]
</example>
Now write: [Your actual request]
Negative examples ("here's what NOT to do") are underused and surprisingly effective — especially for tone. Seeing the contrast makes the target clearer than a positive-only example.
Section 06
Output Format & Length Control
Sonnet defaults to comprehensive, well-organised responses. That's often too much. Precise output control — format, length, structure — is the difference between a response you can use immediately and one you have to edit. These templates give you the exact phrasing that works.
Output Control Templates
Templates 16–22
Output
T16 · Strict JSON Output
[Your task description]
Respond with ONLY a JSON object. Requirements:
- Valid JSON syntax (parseable by JSON.parse)
- No markdown code fences (no ```json)
- No preamble, no explanation, no trailing text
- Null for any field you cannot determine
- Arrays must have at least one item or be empty []
Schema:
{
"field_1": "string",
"field_2": number,
"field_3": ["string"],
"field_4": boolean
}
The four "no" instructions together prevent the most common JSON contamination patterns. In production, always wrap your JSON parse in a try/catch — even with this prompt, a 1-in-200 response may contain edge-case formatting.
Output
T17 · Controlled-Length Response
[Your task]
<length_constraint>
Target: exactly 3 paragraphs.
Each paragraph: 2–4 sentences.
No bullet points. No headers.
Do not add a summary paragraph or closing statement.
</length_constraint>
"Do not add a summary paragraph" is the specific instruction that stops Sonnet from appending the common "In summary…" closer. The <length_constraint> tag makes this easy to swap out for different tasks.
Output
T18 · Table Output Format
[Your task — comparison, list, analysis etc.]
Present your response as a markdown table with these exact columns:
| Column 1 | Column 2 | Column 3 | Column 4 |
Rules:
- Every row must have a value in every column. Use "—" for N/A.
- Sort rows by [criterion, e.g. "relevance, highest first"].
- Maximum 10 rows.
- After the table, add one sentence of context only if essential — otherwise nothing.
Specifying the exact column names prevents Sonnet from inventing its own schema. "Every row must have a value in every column" eliminates sparse tables that are harder to scan.
Output
T19 · Tiered Response (Brief + Detail)
[Your question or task]
Structure your response in two parts:
TL;DR (2 sentences max): The direct answer, no context.
Full explanation: The reasoning, context, and any nuance. Use headers if covering multiple subtopics.
The tiered format satisfies both quick-scan readers and deep-dive readers. The "2 sentences max" hard constraint on the TL;DR forces genuine brevity — without it, "brief" summaries creep to 5–6 sentences.
Output
T20 · Bullet-Point Brief
[Your topic or task]
Output format:
- 5–7 bullet points
- Each bullet: one sentence, max 20 words
- Start each bullet with a strong verb (Enables, Reduces, Increases, Prevents, etc.)
- No sub-bullets
- No intro sentence, no outro sentence
- Order: most important first
"Start each bullet with a strong verb" produces scannable, action-oriented bullets rather than descriptive prose bullets. This is the single instruction that most improves bullet quality.
Section 07
Meta-Prompting & Advanced Patterns
Meta-prompting means using Claude to improve your prompts, critique your own outputs, or build prompt infrastructure. These are the patterns used by teams who run Claude in production at scale — where consistency, self-correction, and prompt iteration speed matter.
Role & Meta Prompting Templates
Templates 21–30+
T21 · Prompt Improvement Request
You are a prompt engineering expert specialising in Claude Sonnet 4.6.
<current_prompt>
[Paste your existing prompt here]
</current_prompt>
<problem>
[Describe what's going wrong: too verbose, wrong format, misses edge cases, inconsistent tone, etc.]
</problem>
Diagnose the prompt's weaknesses in 3 bullet points, then produce an improved version.
Your improved prompt should:
- Fix the stated problem
- Not introduce new ambiguities
- Be no longer than the original unless absolutely necessary
- Use XML tags where structure would help
After the improved prompt, explain the key changes in 2 sentences.
This is the fastest way to iterate on prompts. Run your current prompt, identify the failure mode, then use T21 to generate an improved version. You'll close 80% of prompt issues in one iteration.
T22 · Self-Critique Before Final Answer
[Your task]
After producing your first draft, critique it using these questions:
1. Does this directly answer what was asked — or did I drift?
2. Is any part of this vague, hedged without reason, or unsupported?
3. Is the length appropriate — or am I padding?
4. Is there a simpler or clearer way to say any of this?
Revise the draft based on your critique. Output only the final revised version.
This self-editing loop adds roughly 30% to token cost but eliminates the most common output quality issues. Use it for high-stakes outputs where you'd normally do a manual editing pass.
Role
T23 · Expert Panel (Multi-Perspective)
<question>
[Your question or challenge]
</question>
Respond as three distinct experts with different viewpoints:
Expert 1 — [Role, e.g. "CFO / Finance lens"]:
[Their perspective in 3–4 sentences]
Expert 2 — [Role, e.g. "Head of Engineering / Technical lens"]:
[Their perspective in 3–4 sentences]
Expert 3 — [Role, e.g. "End user / Customer lens"]:
[Their perspective in 3–4 sentences]
Synthesis:
What's the most defensible path forward given all three perspectives? (2–3 sentences)
The expert panel pattern is excellent for strategy and trade-off decisions. Naming the roles explicitly prevents Sonnet from converging on one viewpoint and papering over the tensions.
Chain
T24 · Sequential Task Chain
Complete these tasks in order. Do not skip ahead. Output each result before proceeding.
<input>
[Your raw input material]
</input>
Task 1 — [e.g. Extract key facts]:
[Specific instruction for task 1]
Task 2 — [e.g. Identify gaps]:
Using the output of Task 1, [specific instruction for task 2]
Task 3 — [e.g. Draft recommendations]:
Using the outputs of Tasks 1 and 2, [specific instruction for task 3]
Final output:
Compile only the Task 3 output into a clean, final response. Omit all intermediate reasoning.
"Do not skip ahead" is essential. Without it, Sonnet may collapse all three steps into one output, skipping the intermediate reasoning that makes each step accurate. "Compile only the Task 3 output" keeps the final deliverable clean.
T25 · Generate Your Own System Prompt
You are a senior prompt engineer for Anthropic Claude.
Generate a production-ready system prompt for the following use case:
<use_case>
What it does: [One sentence description]
Who uses it: [User type and context]
Key outputs: [What it produces — format, frequency]
Biggest failure mode to avoid: [What goes wrong without a good prompt]
</use_case>
Requirements for the system prompt you produce:
- Uses XML structure where appropriate
- Covers: role, scope, constraints, output format, edge handling
- 150–350 words
- Includes a brief annotation (in comments) explaining your key design choices
This is the fastest way to bootstrap a new Claude deployment. Describe your use case in 4 fields and get a production-quality starting prompt. Expect to iterate 1–2 times — treat the output as a strong first draft, not a final prompt.
Role
T26 · Socratic Interviewer
You are a Socratic interviewer. Your job is NOT to give answers — it is to help me think more clearly through questions.
<topic>
[The idea, problem, or decision I'm working through]
</topic>
Rules:
- Ask ONE question per turn, never more.
- Questions should expose assumptions, not test knowledge.
- When I give a vague answer, probe the vagueness specifically.
- After 5–6 exchanges, offer a brief synthesis of what seems most important.
- Never give unsolicited advice or opinions until I ask for them.
Begin with your first question.
The "ONE question per turn, never more" constraint is the most important line. Without it, Sonnet generates a wall of questions that shuts down thinking rather than opening it up.
Chain
T27 · Fact-Check & Confidence Scoring
<claims>
[List of statements or a passage to fact-check]
</claims>
For each claim:
1. State the claim (quote or paraphrase)
2. Assign a confidence score: ✅ High / ⚠️ Medium / ❌ Low / ❓ Cannot verify
3. One-sentence explanation of your reasoning
4. If ⚠️ or ❌: What would need to be verified, and where?
End with: total claim count, breakdown by confidence level, and the single most important thing to verify.
The ❓ "Cannot verify" option is important — it prevents Sonnet from forcing a confident verdict on claims it genuinely can't assess, like real-time data or proprietary information.
T28 · Rubber Duck Debug (Code)
<code>
[Your code here]
</code>
<expected_behavior>
[What should happen]
</expected_behavior>
<actual_behavior>
[What's actually happening — error message, wrong output, silent failure]
</actual_behavior>
Walk through the code line by line. For each section:
1. State what it DOES (not what it's supposed to do)
2. Flag any discrepancy with expected behavior
Identify the most likely root cause. Then provide the minimal fix — not a rewrite unless necessary.
If there are secondary issues, list them separately as "Also worth checking."
"Minimal fix — not a rewrite" is crucial. Without it, Sonnet frequently rewrites your entire function when a 2-line fix was all that was needed, creating a diff you didn't ask for.
Output
T29 · Meeting Notes → Action Items
<transcript>
[Meeting transcript or rough notes]
</transcript>
Extract and structure the following:
## Decisions Made
List each decision reached. Format: [Decision] — agreed by [who]
## Action Items
| Owner | Action | Due Date | Priority |
For each action item: owner (name or role), specific task, due date if mentioned, priority (High/Medium/Low based on discussion tone)
## Open Questions
Things that were raised but not resolved. Format: [Question] — needs input from [who]
## Key Context
2–3 bullet points of background that future readers need to understand the decisions above.
Omit anything not relevant to follow-through. Do not summarise discussion — only extract actionable content.
"Do not summarise discussion — only extract actionable content" prevents the 300-word meeting summary nobody asked for. This prompt produces a notes doc that actually drives follow-through.
Chain
T30 · Full Content Pipeline (Research → Draft → Edit)
<brief>
Topic: [Subject]
Audience: [Who reads this]
Goal: [What should the reader do/know/feel after reading?]
Format: [Blog post / LinkedIn post / email / report etc.]
Length: [Target word count]
Tone: [Voice description]
</brief>
Execute in three phases:
Phase 1 — Research frame:
List 5 key angles or insights the piece should cover. Rank by reader value.
Phase 2 — Draft:
Write the full piece using Phase 1 as your structure. Don't hold back — write it as if publishing.
Phase 3 — Edit:
Review the draft against the brief. Cut anything that doesn't serve the goal.
Improve the weakest sentence in each section. Tighten the opening — it's the most important part.
Output only the final edited version.
Running research, drafting, and editing in a single prompt outperforms three separate calls because Phase 2 has the Phase 1 structure in context, and Phase 3 has both. The coherence compounds.
Quick Reference
The Cheat Sheet
The highest-impact rules from this entire playbook, distilled.
| If you want to… | Use this pattern | Template |
|---|---|---|
| Set consistent behaviour across all messages | System prompt with Role + Scope + Constraints + Format | T01–T04 |
| Separate content from instructions clearly | XML tags: <document> before <instructions> | T05–T08 |
| Improve reasoning quality | Ask for <thinking> before the answer | T09 |
| Solve multi-step problems accurately | Explicit steps + Verify step at the end | T10 |
| Get a real verdict, not a hedge | "Be specific. Avoid generic hedging. State your assessment." | T11, T12 |
| Replicate a writing style | 3 example input/output pairs in XML | T13 |
| Get clean JSON every time | "Return ONLY valid JSON. No markdown fences." | T16 |
| Stop Sonnet from padding responses | Hard sentence/word/paragraph count + "No closing statement" | T17–T20 |
| Improve a failing prompt | Meta-prompt: diagnose + improve + explain changes | T21 |
| Build a full content piece fast | 3-phase chain: research frame → draft → edit | T30 |
More templates coming: This playbook is a living document. New templates covering agentic workflows, tool-use prompting, multi-turn conversation design, and model-specific Claude 4.6 patterns are added with each OutClaw issue. Subscribe to get notified.