The Perfect Prompt: Structured Prompting with XML Tags and Markdown
Master the art of structured prompting using XML tags, markdown, and delimiters. Based on official guidelines from Anthropic, OpenAI, and Google for Claude 4.5, GPT-5.2, and Gemini 3—with copy-paste templates and real examples.
Table of Contents
Why Structure Matters
The difference between a mediocre prompt and an expert one can mean 18% vs 79% accuracy on complex tasks. The secret? Structure.
Modern LLMs—Claude 4.5, GPT-5.2, Gemini 3—are trained to parse structured inputs. When you organize your prompts with clear delimiters, the model can accurately distinguish instructions from data, examples from constraints, and context from tasks.
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ WHY STRUCTURED PROMPTS WIN │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ UNSTRUCTURED (Blob Prompt): │
│ ─────────────────────────────── │
│ │
│ "You're a financial analyst at AcmeCorp. Generate a Q2 financial │
│ report for our investors. Include sections on Revenue Growth, │
│ Profit Margins, and Cash Flow, like with this example from last │
│ year: [Q1_REPORT]. Use data points from this spreadsheet: │
│ [SPREADSHEET_DATA]. The report should be extremely concise..." │
│ │
│ Problems: │
│ • Where does the example end and instructions begin? │
│ • Which part is context vs requirements? │
│ • Model may mix up data with instructions │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ STRUCTURED (Clear Boundaries): │
│ ─────────────────────────────── │
│ │
│ <context> │
│ You're a financial analyst at AcmeCorp (B2B SaaS). │
│ </context> │
│ │
│ <data> │
│ [SPREADSHEET_DATA] │
│ </data> │
│ │
│ <instructions> │
│ 1. Include sections: Revenue Growth, Profit Margins, Cash Flow │
│ 2. Highlight strengths and areas for improvement │
│ </instructions> │
│ │
│ <formatting_example> │
│ [Q1_REPORT] │
│ </formatting_example> │
│ │
│ Benefits: │
│ • Clear boundaries between components │
│ • Model knows exactly what's data vs instructions │
│ • Easy to modify individual sections │
│ • Parseable output with matching tags │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Industry convergence: XML tags are now the only format that Anthropic, OpenAI, AND Google all officially recommend for structured prompts.
Part I: XML Tags - The Universal Standard
Why XML Works
XML tags provide what other formats cannot: explicit boundaries. Unlike markdown (where sections end implicitly) or whitespace (which tokenizers can mangle), XML has unambiguous start and end markers.
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ XML vs OTHER FORMATS │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ MARKDOWN: │
│ ───────────── │
│ ### Instructions │
│ Do this thing │
│ │
│ ### Data ← Where does "Instructions" end? │
│ Some data here │
│ │
│ Problem: No explicit end marker. Relies on convention. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ WHITESPACE/INDENTATION: │
│ ──────────────────────── │
│ Instructions: │
│ Do this thing │
│ │
│ Data: │
│ Some data here │
│ │
│ Problem: Tokenization can break whitespace. Fragile. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ XML TAGS: │
│ ────────── │
│ <instructions> │
│ Do this thing │
│ </instructions> ← Explicit end marker │
│ │
│ <data> │
│ Some data here │
│ </data> ← Explicit end marker │
│ │
│ Benefits: Multi-line certainty. Clear boundaries. Parseable. │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Core XML Patterns
The following patterns represent battle-tested approaches that work consistently across all major LLMs. Each pattern solves a specific problem in prompt engineering. Master these four patterns, and you'll handle 90% of structured prompting scenarios.
Pattern 1: Separate Data from Instructions
This is the single most important use of XML tags. When you mix user-provided data with your instructions, the model can become confused about what's a directive versus what's content to process. This confusion leads to inconsistent outputs and can even create security vulnerabilities (prompt injection attacks exploit this exact ambiguity).
By wrapping data in distinct tags, you create an unambiguous boundary. The model knows everything inside <contract> tags is content to analyze, not instructions to follow. This separation is especially critical when processing untrusted user input—you don't want user content accidentally being interpreted as commands.
Code
You are a legal contract analyzer.
<contract>
{{CONTRACT_TEXT}}
</contract>
<instructions>
1. Identify potential risks in the indemnification clause
2. Flag any unusual termination conditions
3. Compare liability limits to industry standards
</instructions>
Provide your analysis in <analysis> tags.
Pattern 2: Provide Examples with Clear Boundaries
Few-shot prompting dramatically improves output quality, but only if the model can clearly identify where each example begins and ends. Without clear boundaries, the model might confuse your example input with real input, or blend example outputs into its response.
The nested structure below—<examples> containing multiple <example> blocks, each with <input> and <output> tags—creates a crystal-clear pattern. The model learns the exact format you want and applies it to the <new_input>. This structure also makes it trivial to add, remove, or modify examples without restructuring your entire prompt.
Code
You are a customer support classifier.
<examples>
<example>
<input>My order never arrived and it's been 2 weeks!</input>
<category>shipping_issue</category>
<priority>high</priority>
</example>
<example>
<input>How do I change my password?</input>
<category>account_help</category>
<priority>low</priority>
</example>
</examples>
<new_input>
{{USER_MESSAGE}}
</new_input>
Classify this message using the same format as the examples.
Pattern 3: Structure Chain-of-Thought
Chain-of-thought prompting improves reasoning quality by forcing the model to "show its work" before providing an answer. However, without structure, the thinking and the answer can blur together, making it hard to parse programmatically or validate the reasoning.
By specifying distinct tags for <thinking> and <answer>, you get two benefits. First, you can programmatically extract just the answer when needed. Second, you can inspect the reasoning to catch errors or understand how the model approached the problem. This pattern is especially valuable for debugging complex prompts—if the answer is wrong, you can see exactly where the reasoning went astray.
Code
<instructions>
Solve this problem step by step.
Show your reasoning in <thinking> tags.
Provide your final answer in <answer> tags.
</instructions>
<problem>
{{PROBLEM_TEXT}}
</problem>
Pattern 4: Hierarchical Nesting
Complex prompts often have multiple levels of organization—context within tasks, criteria within review sections, steps within instructions. Flat structures become unreadable and ambiguous as complexity grows. XML's ability to nest tags mirrors how we naturally organize hierarchical information.
In the example below, <task> contains <context> which itself contains <codebase_info>. The <review_criteria> section groups related sub-criteria. This hierarchy makes the prompt both human-readable and machine-parseable. When you need to modify just the security criteria, you know exactly where to look. The model also benefits—it can reason about the structure at multiple levels of abstraction.
Code
<task>
<context>
You are reviewing code for a fintech startup.
<codebase_info>
- Language: Python 3.11
- Framework: FastAPI
- Database: PostgreSQL
</codebase_info>
</context>
<code_to_review>
{{CODE}}
</code_to_review>
<review_criteria>
<security>Check for SQL injection, auth bypass, data exposure</security>
<performance>Identify N+1 queries, missing indexes, blocking calls</performance>
<style>Verify PEP 8 compliance, type hints, docstrings</style>
</review_criteria>
</task>
XML Best Practices
| Practice | Good | Bad |
|---|---|---|
| Meaningful names | <user_query>, <contract> | <input1>, <data> |
| Consistent naming | Always use <example> | Mix <example>, <sample>, <instance> |
| Reference tags in text | "Using the contract in <contract> tags..." | "Using the contract above..." |
| Nest for hierarchy | <outer><inner></inner></outer> | Flat structure for complex data |
| Request tagged output | "Respond in <analysis> tags" | No output structure |
XML Attributes for Metadata
XML attributes let you add metadata without extra nesting:
Code
<example type="positive" difficulty="easy">
<input>What's 2+2?</input>
<output>4</output>
</example>
<example type="negative" difficulty="hard">
<input>Explain quantum physics</input>
<output>This is too complex for a brief answer. Please be more specific.</output>
</example>
<document source="internal" date="2024-01-15" confidential="true">
{{DOCUMENT_CONTENT}}
</document>
Use attributes for:
- Classification:
type="positive",category="urgent" - Source tracking:
source="user",author="system" - Metadata:
date="...",version="2.0" - Flags:
required="true",optional="true"
Other Delimiter Options
While XML is preferred, other delimiters work for simpler cases:
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ DELIMITER COMPARISON │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ TRIPLE BACKTICKS (Code/Data): │
│ ────────────────────────────── │
│ ```python │
│ def example(): │
│ pass │
│ ``` │
│ │
│ Best for: Code blocks, preserving formatting │
│ Limitation: No semantic meaning, just "code" │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ TRIPLE QUOTES (Long text): │
│ ─────────────────────────── │
│ """ │
│ This is a long document │
│ that spans multiple lines │
│ """ │
│ │
│ Best for: Multi-line strings, documents │
│ Limitation: No nesting, no semantic type │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ DASHES/SEPARATORS: │
│ ─────────────────── │
│ --- │
│ Section content here │
│ --- │
│ │
│ Best for: Visual separation │
│ Limitation: Ambiguous boundaries, no labels │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ BRACKETED LABELS: │
│ ────────────────── │
│ [INSTRUCTIONS] │
│ Do the thing │
│ [END INSTRUCTIONS] │
│ │
│ [DATA] │
│ The data here │
│ [END DATA] │
│ │
│ Best for: Clear sections without XML syntax │
│ Limitation: Not as universally recognized as XML │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Recommendation: Use XML for complex prompts, triple backticks for code, markdown headers for simple structure.
JSON as Structured Input
For data-heavy prompts, JSON provides type clarity:
Code
<task>
Process this customer data and generate personalized recommendations.
</task>
<customer_data>
```json
{
"customer_id": "C-12345",
"name": "Jane Smith",
"segment": "premium",
"purchase_history": [
{"product": "Widget A", "date": "2024-01-15", "amount": 99.99},
{"product": "Widget B", "date": "2024-02-20", "amount": 149.99}
],
"preferences": {
"communication": "email",
"categories": ["electronics", "home"]
}
}
</customer_data>
<output_format> Return recommendations as JSON:
JSON
{
"recommendations": [
{"product": "string", "reason": "string", "confidence": 0.0-1.0}
]
}
</output_format>
Code
**When to use JSON**:
- Structured data with clear types
- When you want JSON output (models mirror input format)
- API integrations where JSON is the interface
- Complex nested data structures
---
## Part II: Model-Specific Guidelines
### Claude 4.5 (Anthropic)
Claude 4.5 models are trained for **precise instruction following**. They take you literally and do exactly what you ask—nothing more, nothing less.
**Key Principles:**
1. **Be Explicit**: Claude won't add features you didn't ask for
2. **Add Context**: Explain WHY, not just what
3. **Use XML**: Claude was trained with XML tags in training data
```xml
<!-- CLAUDE 4.5 OPTIMIZED PROMPT -->
<context>
You're building an analytics dashboard for a SaaS company.
This will be presented to executives who need quick insights.
</context>
<instructions>
Create an analytics dashboard with the following:
1. Revenue metrics with month-over-month comparison
2. User engagement charts (DAU, session duration)
3. Churn prediction indicators
Include as many relevant features as possible.
Go beyond the basics to create a fully-featured implementation.
</instructions>
<formatting>
- Use Tailwind CSS for styling
- Include thoughtful animations for data transitions
- Create visual hierarchy that guides the eye
</formatting>
<output_format>
Return complete, working code. No placeholders.
</output_format>
Claude 4.5 Specific Tips:
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ CLAUDE 4.5 BEST PRACTICES │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. EXPLAIN THE "WHY" │
│ ───────────────────── │
│ │
│ Less effective: │
│ "NEVER use ellipses" │
│ │
│ More effective: │
│ "Your response will be read aloud by a text-to-speech engine, │
│ so never use ellipses since TTS won't know how to pronounce them." │
│ │
│ Claude generalizes from explanations. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 2. REQUEST ACTION EXPLICITLY │
│ ───────────────────────────── │
│ │
│ Less effective (Claude will only suggest): │
│ "Can you suggest some changes to improve this function?" │
│ │
│ More effective (Claude will make changes): │
│ "Change this function to improve its performance." │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 3. CONTROL MARKDOWN OUTPUT │
│ ──────────────────────────── │
│ │
│ <avoid_excessive_markdown> │
│ Write in clear, flowing prose using complete paragraphs. │
│ Reserve markdown for `inline code` and ```code blocks``` only. │
│ Avoid **bold**, *italics*, and bullet lists unless explicitly needed. │
│ </avoid_excessive_markdown> │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 4. PARALLEL TOOL CALLING │
│ ────────────────────────── │
│ │
│ <use_parallel_tool_calls> │
│ If you intend to call multiple tools and there are no dependencies, │
│ make all independent calls in parallel. For example, when reading │
│ 3 files, run 3 tool calls in parallel to read all at once. │
│ </use_parallel_tool_calls> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Proactive Action Prompt for Claude:
Code
<default_to_action>
By default, implement changes rather than only suggesting them.
If the user's intent is unclear, infer the most useful likely action and proceed.
Use tools to discover missing details instead of guessing.
Try to infer whether a tool call (e.g., file edit) is intended, and act accordingly.
</default_to_action>
GPT-5.2 (OpenAI)
GPT-5.2 is designed for enterprise and agentic workloads with stronger instruction adherence and more disciplined execution.
Key Principles:
- Structured XML formatting for semantic organization
- Explicit verbosity constraints (it defaults to concise)
- Scope control to prevent feature creep
- Long-context handling with re-grounding
Code
<!-- GPT-5.2 OPTIMIZED PROMPT -->
<context_gathering>
- Goal: Build a user authentication system
- Method: JWT-based auth with refresh tokens
- Constraints: Must integrate with existing PostgreSQL database
</context_gathering>
<instructions>
Implement EXACTLY and ONLY what is requested below.
No extra features, no added components, no "nice to haves".
1. Create login endpoint with email/password
2. Generate JWT access token (15min expiry)
3. Generate refresh token (7 day expiry)
4. Create refresh endpoint to rotate tokens
</instructions>
<output_format>
- Provide complete, working code
- Default verbosity: 3-6 sentences for explanations
- Use bullet points for lists, not prose
</output_format>
<verification>
After completing, briefly re-scan your answer for:
- Unstated assumptions
- Features not explicitly requested
- Missing error handling for specified cases
</verification>
GPT-5.2 Specific Tips:
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ GPT-5.2 BEST PRACTICES │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. CONTROL VERBOSITY EXPLICITLY │
│ ───────────────────────────────── │
│ │
│ "Default: 3-6 sentences or ≤5 bullets for typical answers. │
│ For simple yes/no questions: ≤2 sentences." │
│ │
│ GPT-5.2 is less verbose by default—specify when you want more. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 2. PREVENT SCOPE DRIFT │
│ ──────────────────────── │
│ │
│ "Implement EXACTLY and ONLY what the user requests. │
│ No extra features, no added components." │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 3. HANDLE AMBIGUITY EXPLICITLY │
│ ─────────────────────────────── │
│ │
│ "When questions are underspecified, either: │
│ - Ask 1-3 precise clarifying questions, OR │
│ - Present 2-3 plausible interpretations with labeled assumptions" │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 4. LONG CONTEXT RE-GROUNDING │
│ ────────────────────────────── │
│ │
│ For inputs >10k tokens: │
│ "First, produce a short outline of relevant sections. │
│ Restate user constraints before answering. │
│ Anchor claims to specific sections, not generic statements." │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 5. TOOL PREAMBLES │
│ ────────────────── │
│ │
│ "Before calling tools: │
│ 1. Restate the user's goal │
│ 2. Outline your execution plan │
│ 3. Provide progress updates during execution │
│ 4. Summarize completed work after" │
│ │
└─────────────────────────────────────────────────────────────────────────┘
GPT-5.2 Hallucination Mitigation:
Code
<self_check>
Briefly re-scan your answer for:
- Unstated assumptions
- Ungrounded specific numbers or statistics
- Overly strong language without evidence
- Claims not anchored to provided context
</self_check>
Gemini 3 (Google)
Gemini 3 favors directness over persuasion and logic over verbosity. It has smarter defaults, making elaborate prompts unnecessary.
Key Principles:
- Be precise and direct - avoid persuasive language
- Use consistent delimiters - XML or Markdown, not both
- Place instructions at the end for long contexts
- Keep temperature at 1.0 - optimized for default
Code
<!-- GEMINI 3 OPTIMIZED PROMPT -->
<context>
{{LONG_DOCUMENT_OR_CODEBASE}}
</context>
<task>
Based on the entire document above, extract all mentioned deadlines
and deliverables into a structured format.
</task>
<output_schema>
{
"deliverables": [
{
"name": "string",
"deadline": "YYYY-MM-DD",
"owner": "string",
"status": "not_started | in_progress | complete"
}
]
}
</output_schema>
<constraints>
- Extract ONLY explicitly mentioned items
- Set null for any missing fields
- Do not infer or assume dates not stated
</constraints>
Gemini 3 Specific Tips:
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ GEMINI 3 BEST PRACTICES │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. DIRECTNESS OVER PERSUASION │
│ ─────────────────────────────── │
│ │
│ Less effective: │
│ "It would be really helpful if you could please analyze this and │
│ provide your valuable insights..." │
│ │
│ More effective: │
│ "Analyze this document. List the top 3 risks." │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 2. INSTRUCTIONS AT THE END │
│ ──────────────────────────── │
│ │
│ For long contexts, place data first, instructions last: │
│ │
│ <document> │
│ [50,000 tokens of content] │
│ </document> │
│ │
│ Based on the document above, summarize the key findings. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 3. NEGATIVE CONSTRAINTS AT THE END │
│ ──────────────────────────────────── │
│ │
│ Gemini may drop negative constraints if they appear early. │
│ Place "DO NOT..." and format constraints as the final line: │
│ │
│ "Summarize the key points. │
│ Use 3-5 bullet points. │
│ DO NOT include any dates or statistics." ← Last line │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ 4. SINGLE FORMAT TYPE │
│ ────────────────────── │
│ │
│ Use XML OR Markdown, never both in the same prompt: │
│ │
│ ✓ Consistent: <instructions>...</instructions> │
│ ✓ Consistent: ### Instructions ... │
│ ✗ Mixed: ### Instructions <task>...</task> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Part III: The Anatomy of a Perfect Prompt
Universal Template
This template works across Claude, GPT, and Gemini:
Code
<!-- UNIVERSAL STRUCTURED PROMPT TEMPLATE -->
<role>
[WHO the model should be - expertise, perspective, constraints]
</role>
<context>
[BACKGROUND information the model needs]
[Domain knowledge, project details, relevant history]
</context>
<input_data>
[The ACTUAL DATA to process - documents, code, user content]
[Keep separate from instructions to prevent confusion]
</input_data>
<task>
[WHAT to do - the core action requested]
[Be specific and explicit about expected actions]
</task>
<instructions>
[HOW to do it - step by step guidance]
1. First step
2. Second step
3. Third step
</instructions>
<constraints>
[BOUNDARIES - what NOT to do, limits, restrictions]
- Do not include X
- Limit to Y
- Avoid Z
</constraints>
<output_format>
[STRUCTURE of the response]
- Format (JSON, prose, bullets)
- Length expectations
- Required sections
</output_format>
<examples>
[DEMONSTRATIONS of desired behavior - optional but powerful]
<example>
<input>Example input</input>
<output>Example output</output>
</example>
</examples>
Real-World Examples
Example 1: Code Review Prompt
Code
<role>
You are a senior software engineer conducting a security-focused code review.
You have 15 years of experience and have seen every vulnerability pattern.
</role>
<context>
This code is for a financial services API handling customer transactions.
Security and correctness are paramount. The codebase uses:
- Python 3.11 with FastAPI
- PostgreSQL with SQLAlchemy ORM
- JWT authentication
</context>
<code_to_review>
```python
{{CODE}}
</code_to_review>
Prioritize by severity: CRITICAL > HIGH > MEDIUM > LOW
<output_format>
<high_issues> [List high-severity issues] </high_issues>
Example 2: Data Extraction Prompt
Code
<role>
You are a precise data extraction system.
Extract only what is explicitly stated. Never infer or assume.
</role>
<document>
{{DOCUMENT_TEXT}}
</document>
<task>
Extract all person entities mentioned in the document with their attributes.
</task>
<output_schema>
{
"persons": [
{
"name": "string (required)",
"title": "string or null",
"organization": "string or null",
"email": "string or null",
"phone": "string or null",
"mentioned_context": "string (quote from document)"
}
],
"extraction_confidence": "high | medium | low",
"ambiguous_mentions": ["list of unclear references"]
}
</output_schema>
<constraints>
- Set null for any field not explicitly stated
- Do not guess email formats or phone numbers
- Include direct quote showing where each person was mentioned
- Flag any ambiguous references (e.g., "the CEO" without a name)
</constraints>
<examples>
<example>
<input>"John Smith, CTO of Acme Corp, can be reached at john@acme.com"</input>
<output>
{
"persons": [{
"name": "John Smith",
"title": "CTO",
"organization": "Acme Corp",
"email": "john@acme.com",
"phone": null,
"mentioned_context": "John Smith, CTO of Acme Corp, can be reached at john@acme.com"
}],
"extraction_confidence": "high",
"ambiguous_mentions": []
}
</output>
</example>
</examples>
Example 3: Multi-Step Analysis Prompt
Code
<role>
You are a strategic analyst helping a startup evaluate market opportunities.
</role>
<context>
<company_info>
{{COMPANY_DESCRIPTION}}
</company_info>
<market_data>
{{MARKET_RESEARCH}}
</market_data>
<competitor_analysis>
{{COMPETITOR_DATA}}
</competitor_analysis>
</context>
<task>
Analyze the market opportunity and provide strategic recommendations.
</task>
<instructions>
Follow this analytical framework:
<step_1>
Market Size Assessment
- Calculate TAM, SAM, SOM
- Identify growth trends
</step_1>
<step_2>
Competitive Positioning
- Map competitors on value/price matrix
- Identify white space opportunities
</step_2>
<step_3>
Strategic Options
- Generate 3 distinct go-to-market strategies
- Evaluate pros/cons of each
</step_3>
<step_4>
Recommendation
- Select optimal strategy with rationale
- Define success metrics
- Outline 90-day action plan
</step_4>
</instructions>
<output_format>
Use the following structure:
<analysis>
<market_assessment>
[Step 1 output]
</market_assessment>
<competitive_position>
[Step 2 output]
</competitive_position>
<strategic_options>
[Step 3 output]
</strategic_options>
<recommendation>
[Step 4 output]
</recommendation>
</analysis>
</output_format>
Part IV: Markdown Integration
While XML excels at structure, markdown shines for formatting within sections.
When to Use Markdown
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ XML + MARKDOWN COMBINATION │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ XML FOR: MARKDOWN FOR: │
│ ───────── ───────────── │
│ • Section boundaries • Headers within sections │
│ • Data/instruction separation • Bullet lists │
│ • Nested hierarchies • Code blocks │
│ • Input/output tagging • Emphasis (bold/italic) │
│ • Parseable structure • Tables │
│ │
│ EXAMPLE COMBINATION: │
│ ───────────────────── │
│ │
│ <instructions> │
│ ## Primary Task │
│ Analyze the provided data and create a report. │
│ │
│ ## Requirements │
│ - Include **executive summary** │
│ - Use `code formatting` for technical terms │
│ - Present metrics in tables │
│ │
│ ## Output Structure │
│ ``` │
│ 1. Summary │
│ 2. Analysis │
│ 3. Recommendations │
│ ``` │
│ </instructions> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Markdown Elements Reference
Each markdown element serves a specific purpose:
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ MARKDOWN ELEMENTS FOR PROMPTS │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ HEADERS (Section Organization): │
│ ───────────────────────────────── │
│ # H1 - Main title (rarely used in prompts) │
│ ## H2 - Major sections │
│ ### H3 - Subsections │
│ #### H4 - Minor divisions │
│ │
│ Example: │
│ ### Task │
│ Analyze the document. │
│ ### Constraints │
│ - Maximum 500 words │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ CODE FENCES (Code/Data Blocks): │
│ ───────────────────────────────── │
│ ```python │
│ code here │
│ ``` │
│ │
│ ```json │
│ {"key": "value"} │
│ ``` │
│ │
│ Language hint helps model understand content type. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ INLINE CODE (`backticks`): │
│ ─────────────────────────── │
│ Reference the `user_id` field. │
│ Call the `processData()` function. │
│ │
│ Use for: variable names, function names, short code snippets, │
│ file names, technical terms │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ BULLET LISTS (Unordered Items): │
│ ───────────────────────────────── │
│ - First item │
│ - Second item │
│ - Nested item │
│ │
│ Use for: requirements, features, options (order doesn't matter) │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ NUMBERED LISTS (Ordered Steps): │
│ ───────────────────────────────── │
│ 1. First step │
│ 2. Second step │
│ 3. Third step │
│ │
│ Use for: sequential instructions, prioritized items, procedures │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ BOLD & ITALIC (Emphasis): │
│ ─────────────────────────── │
│ **Important**: This is critical. │
│ *Note*: This is a side point. │
│ ***Very important***: Combination. │
│ │
│ Use sparingly—over-emphasis reduces impact. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ TABLES (Structured Comparisons): │
│ ────────────────────────────────── │
│ | Column 1 | Column 2 | │
│ |----------|----------| │
│ | Data 1 | Data 2 | │
│ │
│ Use for: option comparisons, field definitions, mapping data │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ BLOCKQUOTES (Quoted Content): │
│ ─────────────────────────────── │
│ > This is quoted text │
│ > from another source. │
│ │
│ Use for: example outputs, user messages, quoted requirements │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Markdown-Only Approach (Simpler Tasks)
For straightforward prompts, markdown alone works well:
Markdown
### Role
You are a helpful coding assistant specializing in Python.
### Task
Refactor the following function to improve readability and performance.
### Code
```python
def process(data):
result = []
for item in data:
if item['status'] == 'active':
if item['value'] > 100:
result.append(item['name'].upper())
return result
Requirements
- Use list comprehensions where appropriate
- Add type hints
- Include a docstring
- Maintain the same functionality
Output
Provide the refactored code with brief comments explaining changes.
Code
### Model-Specific Markdown Tips
**Claude**: Responds well to XML-style tags even in markdown contexts
```markdown
### Instructions
Analyze this code. Put your reasoning in <thinking> tags.
GPT: Follows ### headers and numbered constraints effectively
Markdown
### Constraints
1. Maximum 200 words
2. No bullet points
3. Professional tone
Gemini: Prefers clean structure, place important constraints last
Markdown
### Task
Summarize the article.
### Format
3 paragraphs, no headers.
DO NOT include quotes from the text.
Part V: Advanced Patterns
These patterns go beyond basic structure to unlock sophisticated behaviors. Each addresses a common failure mode in LLM outputs—inconsistent reasoning, unchecked errors, narrow perspectives, poor first drafts, or malformed structured data. Use these when basic prompting isn't producing reliable results.
Pattern 1: Thinking and Answer Separation
The Problem: When models jump straight to answers, they often miss edge cases, make logical errors, or provide oversimplified responses. Worse, when they do reason internally, you can't see or debug the reasoning.
The Solution: Force the model to externalize its reasoning in <thinking> tags before providing a final answer. This creates a "paper trail" that you can inspect, and often improves answer quality simply by making the model slow down.
When to Use: Complex reasoning tasks, math problems, multi-step analysis, any situation where you need to audit the model's logic, or when accuracy matters more than speed.
Code
<instructions>
Solve this problem step by step.
First, work through your reasoning inside <thinking> tags.
Consider multiple approaches before selecting one.
Then provide your final answer inside <answer> tags.
The answer should be concise and directly actionable.
</instructions>
<problem>
{{PROBLEM}}
</problem>
Expected response format:
<thinking>
[Detailed reasoning process]
[Consider edge cases]
[Evaluate approaches]
</thinking>
<answer>
[Concise final answer]
</answer>
Pattern 2: Self-Verification
The Problem: LLMs can confidently produce incorrect outputs—SQL queries with bugs, code with security holes, calculations with errors. A single-pass generation provides no opportunity for the model to catch its own mistakes.
The Solution: Build explicit verification steps into the prompt. Ask the model to generate, then check its own work against specific criteria, and then correct any issues found. This mimics how careful humans work—draft, review, revise.
When to Use: SQL generation (check for injection, NULL handling, performance), code generation (security review, edge cases), calculations (verify with alternative method), any output where errors have significant consequences.
Code
<task>
Generate a SQL query for the following request.
</task>
<request>
{{USER_REQUEST}}
</request>
<schema>
{{DATABASE_SCHEMA}}
</schema>
<instructions>
1. Generate the SQL query in <query> tags
2. Verify your query in <verification> tags:
- Does it handle NULL values correctly?
- Are there potential injection risks?
- Will it perform well on large tables?
3. If issues found, provide corrected query in <final_query> tags
</instructions>
Pattern 3: Multi-Agent Simulation
The Problem: LLMs tend to give balanced, consensus-style answers that try to please everyone. This can miss critical perspectives or fail to surface legitimate concerns that different stakeholders would raise.
The Solution: Explicitly prompt the model to adopt distinct personas and analyze from each perspective separately. By forcing it to "wear different hats," you get more thorough analysis that surfaces trade-offs and conflicts that a single-perspective answer would gloss over.
When to Use: Business decisions affecting multiple stakeholders, product design reviews, risk assessment, strategic planning, any analysis where different perspectives lead to genuinely different conclusions.
Code
<task>
Evaluate this business proposal from multiple stakeholder perspectives.
</task>
<proposal>
{{PROPOSAL}}
</proposal>
<instructions>
Analyze as three different stakeholders:
<cfo_perspective>
Focus on: ROI, cash flow impact, financial risks
</cfo_perspective>
<cto_perspective>
Focus on: Technical feasibility, integration complexity, scalability
</cto_perspective>
<customer_perspective>
Focus on: Value proposition, usability, pain points addressed
</customer_perspective>
<synthesis>
Combine perspectives into unified recommendation
</synthesis>
</instructions>
Pattern 4: Iterative Refinement
The Problem: First drafts are rarely optimal. A single-pass generation often produces technically correct but uninspiring output—marketing copy that's generic, code that's functional but not elegant, explanations that are accurate but confusing.
The Solution: Structure the prompt as multiple draft-critique-revise cycles. Each iteration builds on the previous, addressing specific weaknesses identified in the critique phase. This mimics the writing process of skilled humans and consistently produces higher-quality output.
When to Use: Creative writing (marketing copy, blog posts, emails), any output where subjective quality matters, situations where you know the first draft won't be good enough, content that will be seen by many people.
Code
<task>
Write marketing copy for this product.
</task>
<product>
{{PRODUCT_INFO}}
</product>
<instructions>
<draft_1>
Write initial copy focusing on features.
</draft_1>
<critique_1>
Evaluate draft_1: Is it compelling? Does it address customer pain points?
</critique_1>
<draft_2>
Revise based on critique, focusing on benefits and emotional appeal.
</draft_2>
<critique_2>
Evaluate draft_2: Is it concise? Does it have a clear CTA?
</critique_2>
<final>
Produce polished final version incorporating all improvements.
</final>
</instructions>
Pattern 5: Constrained Generation with Validation
The Problem: When generating structured output like JSON or XML, models frequently produce valid-looking but actually malformed data—missing required fields, wrong data types, extra properties that break your parser. These errors can be subtle and cause downstream failures.
The Solution: Provide an explicit schema and require the model to validate its output against that schema before returning it. If validation fails, require correction. This catches errors at generation time rather than in your production system.
When to Use: Any structured data generation (JSON configs, API responses, database records), integration with strict schemas, anywhere malformed output would cause system failures.
Code
<task>
Generate a JSON configuration file.
</task>
<requirements>
{{REQUIREMENTS}}
</requirements>
<schema>
{{JSON_SCHEMA}}
</schema>
<instructions>
1. Generate configuration in <config> tags
2. Validate against schema in <validation> tags
3. List any schema violations in <errors> tags
4. If errors exist, provide corrected version in <corrected_config> tags
</instructions>
<constraints>
- All required fields must be present
- No additional properties beyond schema
- Values must match specified types exactly
</constraints>
Part VI: System Prompt vs User Prompt
Where you place structured content matters for production applications.
What Goes Where
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ SYSTEM PROMPT vs USER PROMPT PLACEMENT │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ SYSTEM PROMPT (Persistent Context): │
│ ───────────────────────────────────── │
│ • Role definition │
│ • Global constraints and rules │
│ • Output format specifications │
│ • Behavioral guidelines │
│ • Tool descriptions and usage rules │
│ • Safety and compliance requirements │
│ │
│ Stays constant across the conversation. │
│ Set once, applies to all interactions. │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ USER PROMPT (Per-Request Content): │
│ ──────────────────────────────────── │
│ • Specific task or question │
│ • Input data to process │
│ • Task-specific examples │
│ • Context unique to this request │
│ • Variables and parameters │
│ │
│ Changes with each user interaction. │
│ Contains the actual work to be done. │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Production System Prompt Template
Code
<!-- SYSTEM PROMPT -->
<identity>
You are [ROLE] at [COMPANY/CONTEXT].
Your expertise includes [RELEVANT SKILLS].
</identity>
<core_rules>
1. Always [CRITICAL BEHAVIOR]
2. Never [PROHIBITED ACTION]
3. When uncertain, [FALLBACK BEHAVIOR]
</core_rules>
<output_standards>
<format>
- Response format: [FORMAT TYPE]
- Maximum length: [LENGTH]
- Required sections: [SECTIONS]
</format>
<style>
- Tone: [TONE]
- Technical level: [LEVEL]
- Language: [LANGUAGE]
</style>
</output_standards>
<tool_usage>
You have access to the following tools:
<tool name="search">
Use when: User needs information not in your training data
Format: {"query": "search terms"}
</tool>
<tool name="calculate">
Use when: Mathematical operations required
Format: {"expression": "math expression"}
</tool>
</tool_usage>
<safety>
- Do not [PROHIBITED CONTENT]
- If asked to [RISKY ACTION], respond with [SAFE RESPONSE]
- Always verify [VERIFICATION REQUIREMENT]
</safety>
Production User Prompt Template
Code
<!-- USER PROMPT (sent with each request) -->
<context>
[Any context specific to this request]
</context>
<input_data>
[The data to process]
</input_data>
<task>
[The specific task for this request]
</task>
<additional_requirements>
[Any request-specific requirements not covered by system prompt]
</additional_requirements>
Example: Customer Service Bot
System Prompt (set once):
Code
<identity>
You are a customer service representative for TechCorp.
You help customers with product questions, orders, and technical support.
</identity>
<core_rules>
1. Always be helpful, professional, and empathetic
2. Never share customer data or make promises you can't keep
3. Escalate to human agent if: customer requests it, legal issues arise, or you're uncertain
</core_rules>
<output_standards>
<format>Keep responses under 150 words unless detail is requested</format>
<style>Warm and professional, use customer's name when known</style>
</output_standards>
<knowledge_boundaries>
- You can discuss: Products, pricing, shipping, returns, basic troubleshooting
- You cannot: Process refunds, access payment details, modify orders
- When asked about things you can't do, explain and offer alternatives
</knowledge_boundaries>
User Prompt (changes per request):
Code
<customer_context>
Customer: Jane Smith
Account type: Premium
Previous issue: Shipping delay last month (resolved)
</customer_context>
<conversation_history>
User: My new laptop arrived but won't turn on
Agent: I'm sorry to hear that, Jane. Let's troubleshoot together...
User: I tried holding the power button but nothing happens
</conversation_history>
<current_message>
The charging light isn't on either when I plug it in.
</current_message>
Key Principles
- System prompt = Personality, Rules, Capabilities
- User prompt = Task, Data, Context
- Don't repeat system prompt content in user prompts
- Keep system prompts stable for consistent behavior
- Test system prompt changes across many scenarios before deploying
Understanding Message Roles
Modern LLM APIs use a conversation format with distinct message roles. Understanding these is crucial for production applications.
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ MESSAGE ROLES EXPLAINED │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ SYSTEM MESSAGE (role: "system") │
│ ───────────────────────────────── │
│ │
│ Purpose: Define the AI's identity, behavior, and constraints │
│ │
│ Characteristics: │
│ • Typically appears first in the conversation │
│ • Sets the "personality" and rules for the entire session │
│ • Not visible to end users in most applications │
│ • Highest priority—other messages shouldn't override it │
│ • Can be updated between conversations but not mid-conversation │
│ │
│ When to update: When changing the AI's core behavior or capabilities │
│ │
│ Example: │
│ { │
│ "role": "system", │
│ "content": "<identity>You are a helpful coding assistant...</identity>"
│ } │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ USER MESSAGE (role: "user") │
│ ──────────────────────────── │
│ │
│ Purpose: Represent input from the human user │
│ │
│ Characteristics: │
│ • Contains questions, requests, and data from the user │
│ • May include context, examples, and specific instructions │
│ • Typically what triggers a response from the assistant │
│ • Can be multi-turn (conversation history) │
│ │
│ What belongs here: │
│ • The actual task or question │
│ • Data to be processed │
│ • Request-specific context │
│ • Follow-up questions and clarifications │
│ │
│ Example: │
│ { │
│ "role": "user", │
│ "content": "<task>Review this code for bugs</task>\n<code>..." │
│ } │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ ASSISTANT MESSAGE (role: "assistant") │
│ ────────────────────────────────────── │
│ │
│ Purpose: Represent the AI's previous responses │
│ │
│ Characteristics: │
│ • Contains the AI's prior outputs in the conversation │
│ • Used to maintain conversation context │
│ • Can be "pre-filled" to guide the model's response format │
│ • Essential for multi-turn conversations │
│ │
│ Advanced use—Assistant Prefilling: │
│ Start the assistant's response to guide format: │
│ │
│ { │
│ "role": "assistant", │
│ "content": "<analysis>\n" // Model continues from here │
│ } │
│ │
│ This forces the model to continue in your desired format. │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Multi-Turn Conversation Structure
Here's how a complete conversation looks with proper role usage:
Python
# Complete API call structure
messages = [
# SYSTEM: Set identity and rules (sent once)
{
"role": "system",
"content": """<identity>
You are a senior Python developer conducting code reviews.
You have 15 years of experience with Python and deep expertise in
security, performance, and clean code principles.
</identity>
<review_standards>
For each issue found:
1. Identify the specific line number
2. Explain WHY it's a problem (not just what)
3. Show the correct implementation
4. Rate severity: CRITICAL / HIGH / MEDIUM / LOW
</review_standards>
<output_format>
Structure your review as:
<review>
<issues>[List of issues with severity]</issues>
<positive>[Good patterns worth noting]</positive>
<summary>[One paragraph assessment]</summary>
</review>
</output_format>"""
},
# USER: First request with code to review
{
"role": "user",
"content": """<code_context>
File: auth.py
Purpose: User authentication module
Framework: FastAPI
</code_context>
<code>
```python
def login(username, password):
query = f"SELECT * FROM users WHERE username = '{username}'"
user = db.execute(query).fetchone()
if user and user.password == password:
return create_token(user.id)
return None
<specific_concerns> We're about to deploy this to production. Are there any security issues? </specific_concerns>""" },
Code
# ASSISTANT: AI's response (from previous turn)
{
"role": "assistant",
"content": """<review>
Fix:
Python
query = "SELECT * FROM users WHERE username = ?"
user = db.execute(query, (username,)).fetchone()
-
CRITICAL - Plain Text Password Comparison (Line 4) Comparing passwords directly suggests plain text storage. Use bcrypt or argon2 for password hashing.
Fix:
Pythonif user and bcrypt.checkpw(password.encode(), user.password_hash):
Code
# USER: Follow-up question
{
"role": "user",
"content": """Thanks! Can you also show me how to add rate limiting
to prevent brute force attacks?""" }
Code
# Model generates next assistant response...
]
Code
### Assistant Prefilling Technique
A powerful but often overlooked technique: **prefill the assistant's response** to force specific output formats.
```python
# WITHOUT prefilling - model might not follow format
messages = [
{"role": "system", "content": "You analyze sentiment. Respond with JSON."},
{"role": "user", "content": "Analyze: 'I love this product!'"}
]
# Model might respond: "The sentiment is positive. Here's the JSON: {...}"
# WITH prefilling - model MUST continue in JSON format
messages = [
{"role": "system", "content": "You analyze sentiment."},
{"role": "user", "content": "Analyze: 'I love this product!'"},
{"role": "assistant", "content": "{"} # Force JSON start
]
# Model continues: {"sentiment": "positive", "confidence": 0.95}
More prefilling examples:
Python
# Force XML output
{"role": "assistant", "content": "<analysis>\n"}
# Force specific section
{"role": "assistant", "content": "## Summary\n"}
# Force thinking before answer (Claude)
{"role": "assistant", "content": "<thinking>\nLet me analyze this step by step.\n"}
# Force code block
{"role": "assistant", "content": "```python\n"}
When to use prefilling:
- Ensuring consistent output format
- Forcing the model to "think" before answering
- Starting responses with specific structure
- Preventing preamble ("Sure, I'd be happy to help...")
Part VII: Common Mistakes and Fixes
Mistake 1: Mixing Instruction and Data
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ ❌ BAD: Instructions mixed with data │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Analyze this contract and identify risks. The contract is: │
│ "This Agreement is entered into... [CONTRACT TEXT]... The parties │
│ agree to binding arbitration." Focus especially on liability clauses. │
│ │
│ Problem: Where does contract end? "Focus especially" could be │
│ interpreted as part of the contract text. │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ ✅ GOOD: Clear separation │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ <instructions> │
│ Analyze this contract and identify risks. │
│ Focus especially on liability clauses. │
│ </instructions> │
│ │
│ <contract> │
│ This Agreement is entered into... [CONTRACT TEXT]... The parties │
│ agree to binding arbitration. │
│ </contract> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Mistake 2: Inconsistent Examples
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ ❌ BAD: Format varies between examples │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Example 1: Input: "hello" -> Output: HELLO │
│ Example 2: │
│ Input: "world" │
│ Output: WORLD │
│ Example 3: hello -> HELLO │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ ✅ GOOD: Consistent structure │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ <examples> │
│ <example> │
│ <input>hello</input> │
│ <output>HELLO</output> │
│ </example> │
│ <example> │
│ <input>world</input> │
│ <output>WORLD</output> │
│ </example> │
│ </examples> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Mistake 3: Conflicting Instructions
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ ❌ BAD: Contradictory requirements │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ "Be extremely concise. Provide comprehensive details. │
│ Keep it under 50 words. Include all relevant context." │
│ │
│ The model wastes reasoning tokens trying to reconcile contradictions. │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ ✅ GOOD: Clear, non-contradictory │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ <output_requirements> │
│ - Length: 50-100 words │
│ - Include: key findings and one recommendation │
│ - Exclude: background context, methodology details │
│ </output_requirements> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Mistake 4: Vague Output Expectations
Code
┌─────────────────────────────────────────────────────────────────────────┐
│ ❌ BAD: Unclear format │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ "Analyze this data and give me insights." │
│ │
│ Model doesn't know: How many insights? What format? How detailed? │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ ✅ GOOD: Explicit structure │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ <output_format> │
│ Provide exactly 3 insights, structured as: │
│ │
│ <insight> │
│ <title>Brief title (5 words max)</title> │
│ <finding>The data pattern observed (1-2 sentences)</finding> │
│ <implication>Business impact (1 sentence)</implication> │
│ <action>Recommended next step (1 sentence)</action> │
│ </insight> │
│ </output_format> │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Part VII: Quick Reference
Tag Library
| Purpose | Recommended Tags |
|---|---|
| Data containers | <document>, <code>, <data>, <input>, <context> |
| Instructions | <instructions>, <task>, <requirements>, <constraints> |
| Examples | <examples>, <example>, <input>, <output> |
| Output structure | <response>, <answer>, <analysis>, <result> |
| Reasoning | <thinking>, <reasoning>, <verification>, <critique> |
| Formatting | <format>, <output_format>, <schema> |
| Metadata | <context>, <background>, <role> |
Model-Specific Cheat Sheet
| Feature | Claude 4.5 | GPT-5.2 | Gemini 3 |
|---|---|---|---|
| Preferred format | XML tags | XML tags | XML or Markdown |
| Verbosity default | Moderate | Concise | Concise |
| Best for | Coding, analysis | Agentic tasks | Long context |
| Watch out for | Too literal | Scope creep | Dropped constraints |
| Key tip | Explain the "why" | Control scope | Instructions at end |
Prompt Checklist
Before sending a complex prompt:
- Data separated from instructions?
- Tags consistently named?
- Examples in consistent format?
- No contradictory instructions?
- Output format specified?
- Constraints clearly stated?
- Model-specific adjustments made?
Frequently Asked Questions
Related Articles
PromptingPersonalization
Prompt-Based Personalization: Tone, Persona, and Dynamic Style Control
A practical guide to controlling LLM behavior through prompting alone. Master persona assignment, tone spectrums, dynamic style shifting, and prompt routing—with copy-paste examples for every use case.
4 min read
PromptingLLMs
Advanced Prompt Engineering: From Basic to Production-Grade
Master the techniques that separate amateur prompts from production systems—chain-of-thought, structured outputs, model-specific optimization, and prompt architecture.
10 min read
PersonalizationLLMs
LLM Personalization: Building AI That Adapts to Individual Users
Clear walkthrough of personalizing Large Language Models. From memory architectures to preference learning, understand how to build AI systems that truly adapt to individual users—and the challenges that remain.
12 min read