AI Prompt Formatting Guide: When to Use Markdown, XML, Delimiters, and Examples

Overview

Prompt formatting is part of prompt engineering because structure affects how clearly an instruction is presented. A short conversational request may need only a sentence or two. A production prompt for an AI workflow may contain a role, task definition, business rules, reference material, exceptions, variables, and a structured output contract.

Formatting does not guarantee correct answers, and Markdown headings or XML-style tags are not programming controls. They are signals that organize information. Their value comes from consistency, clear wording, and testing against representative inputs.

A practical prompt usually separates five components:

• Context: background information the model needs.
• Task: the action the model should perform.
• Constraints: limits involving tone, scope, length, evidence, or safety.
• Inputs: user-provided text, documents, variables, or retrieved content.
• Output contract: the required format, fields, ordering, and fallback behavior.

For a simple task, headings and bullets are often enough. For long documents, retrieved content, or multi-stage AI development workflows, explicit boundaries become more important. For extraction and automation, a schema or precisely defined field list is usually more useful than elaborate prose. See the Prompt Engineering Framework for a broader method of turning these components into reliable AI prompts.

Checklist by scenario

For general questions and everyday ChatGPT prompts

Use plain language with a short Markdown structure. State the goal, audience, constraints, and desired format. Avoid adding XML tags or a long list of rules merely to make a prompt look technical.

## Task
Explain the difference between a primary and secondary keyword.

## Audience
A content creator who understands basic SEO but is new to keyword planning.

## Requirements
- Use plain language.
- Give one short example.
- Keep the answer under 250 words.
- Mention one common mistake.

This format is readable in a prompt library and simple to adapt. If the answer will be used in a repeatable workflow, convert changing details into explicit variables such as {{audience}}, {{topic}}, and {{word_limit}}.

For long documents and large context windows

Use clear sections and strong delimiters to distinguish instructions from source material. Put the instruction before or after the material in a consistent way, then tell the model exactly how to treat the content. Do not assume that a document enclosed in markers is automatically trustworthy or relevant.

<task>
Summarize the supplied document for an editorial review.
</task>

<requirements>
- Identify the central claim.
- List supporting evidence and unresolved questions.
- Do not add facts that are absent from the document.
</requirements>

<source_document>
---BEGIN DOCUMENT---
{{document_text}}
---END DOCUMENT---
</source_document>

For more detailed guidance on ordering, chunking, and reviewing long inputs, see How to Write Prompts for Long Documents and Large Context Windows.

For RAG and source-grounded answers

Separate the user question, retrieved passages, and answer rules. Use delimiters that make each passage identifiable, and require the model to distinguish supported claims from uncertainty. A RAG prompt template might look like this:

<question>{{user_question}}</question>

<retrieved_context>
<passage id="1">{{passage_1}}</passage>
<passage id="2">{{passage_2}}</passage>
</retrieved_context>

<instructions>
Answer using only the retrieved context. Cite passage IDs for material claims.
If the context is insufficient, say what is missing instead of guessing.
</instructions>

Use this structure alongside retrieval and citation logic; formatting alone cannot verify sources. The guide to research prompts for source-grounded answers covers evidence handling in greater depth.

For extraction and structured output

Define fields explicitly and state what to do when a value is absent. If the API or model supports a response schema, enforce the format there as well as describing it in the prompt. A JSON schema prompt should not rely on an example alone.

Extract the following fields from <document>:
- invoice_number: string or null
- invoice_date: ISO date or null
- total_amount: number or null
- currency: three-letter code or null

Return one JSON object only. Do not include commentary. Use null when a field is not present.

For schema design, validation, and failure handling, consult Structured Output Prompts: A Complete Guide to Reliable JSON and JSON Schema Responses.

For classification, style matching, and repeated transformations

Use few-shot examples when the desired distinction or output style is difficult to explain in rules. Each example should show a representative input and an ideal output. Include positive and borderline cases when those distinctions matter.

Classify each support message as billing, technical, account, or other.
Return only the label.

Example 1
Input: I was charged twice for the same order.
Output: billing

Example 2
Input: The password reset email never arrived.
Output: account

Message to classify:
{{message}}

Examples should match the production task. Do not include irrelevant details, contradictory labels, or examples that expose private data.

What to double-check

Before publishing a prompt template or deploying it in an AI application, run this review:

1. Can a new editor identify the task quickly? Use a heading or opening sentence that states the intended action.
2. Are instructions separated from inputs? Wrap user text, retrieved passages, code, or documents in consistent delimiters or tags.
3. Are variables explicit? Name each variable, define its expected type, and decide what happens if it is empty.
4. Are requirements ranked? If brevity, completeness, evidence, and tone conflict, explain which priority wins.
5. Is the output testable? Define fields, labels, headings, length limits, or a schema that can be checked automatically.
6. Do examples represent edge cases? Test ambiguous, incomplete, unusually long, and adversarial inputs where relevant.
7. Does the syntax survive the target interface? Check escaping, newline handling, token limits, templating rules, and schema support in the actual model or API.
8. Has the prompt been evaluated? Keep a small test set and compare outputs after edits, model changes, or retrieval changes. The Prompt Testing Framework provides a reusable evaluation approach.

For most prompts, readability is a feature. A structure that a human can audit is easier to test, migrate, and debug than a dense block of instructions. At the same time, do not mistake visual polish for reliability: a well-formatted prompt still needs representative test cases and clear success criteria.

Common mistakes

Using every format at once

Markdown, XML-style tags, tables, code fences, and multiple delimiter styles can create visual noise. Start with headings and bullets, then add boundaries only where the task needs them.

Assuming tags create security boundaries

Tags help organize content, but they do not make untrusted text safe or override higher-priority instructions. Treat retrieved content and user-provided text as data, and define how the model should handle embedded instructions.

Writing vague output requirements

“Give a useful answer” is difficult to evaluate. Specify the audience, required sections, allowed sources, length range, and fallback response. For automation, define a schema and validate the returned object.

Adding examples that conflict with the rules

Models may follow the demonstrated pattern even when a written instruction says something different. Audit examples whenever the task definition changes.

Overusing tables for prose

Tables work well for short comparisons and field definitions. Long paragraphs inside cells are harder to read and may be less reliable than labeled sections.

Ignoring model and tool differences

Markdown and plain text are broadly portable, but support for structured outputs, tool calls, context limits, and template syntax varies by model and integration. Treat claims about model-specific behavior as implementation details to verify in the current documentation and your own tests.

When to revisit

Review a production prompt whenever its inputs, tools, model, or success criteria change. A model migration is an obvious trigger, but so are changes to the retrieval pipeline, document format, API wrapper, output parser, moderation layer, or editorial policy. Revisit prompt templates before seasonal planning cycles when topics, audiences, or content rules may shift.

A practical maintenance routine is:

1. Save the current prompt and a version identifier.
2. Run a fixed test set containing normal, borderline, and failure cases.
3. Compare task accuracy, format compliance, unsupported claims, tone, latency, and cost where those measures matter to your workflow.
4. Inspect any regressions manually rather than relying on one successful example.
5. Update the prompt, examples, schema, or surrounding code separately when possible.
6. Record why the change was made and when the next review is due.

Use this article as a design checklist: choose the simplest format that clearly separates the task from its inputs, add examples when patterns are hard to describe, and use schemas when software depends on the result. Then test the complete workflow in the model and interface where the prompt will actually run.