**Learning objective:** Use Markdown structure — headings, lists, code fences, and XML-style tags — to write prompts Claude parses reliably. ## Why structure matters in a prompt A prompt is not a search query. When you type a one-liner into Claude, you're leaving it to infer your intent, audience, format, constraints, and examples all at once. That works fine for simple requests. For anything complex — a multi-step task, a template, a prompt that will be reused — unstructured prose forces Claude to guess which parts are instructions, which are context, and which are the actual content it should work with. Guessing costs reliability. The good news is that Claude is trained on enormous amounts of structured text. Headings, lists, and code fences are not just cosmetic — they signal *semantic relationships*. A heading tells Claude "a new section starts here." A bullet list says "these items are parallel and enumerable." A code fence says "treat this verbatim, do not interpret it as instructions." Using these signals deliberately makes your intent legible without any extra explanation. ## Headings and lists: the backbone of a multi-part prompt For prompts with more than one distinct concern — role, task, constraints, output format — use `##` headings to separate them. Claude reads the whole prompt before responding, so the order of sections matters less than their clarity. That said, a conventional order that works well is: **role or context** first, **task** second, **constraints or rules** third, **output format** last. Bullet lists are your friend for constraints and format requirements. Compare these two versions: *Prose version:* "Please write a summary that is under 150 words, avoids jargon, uses present tense, and is aimed at a non-technical audience." *List version:* ``` ## Constraints - Under 150 words - No technical jargon - Present tense throughout - Audience: non-technical readers ``` Both contain the same information. The list version is harder to accidentally satisfy partially — each item is its own checkable condition. Claude is less likely to drop one of four constraints presented as a list than one of four constraints buried in a sentence. Numbered lists are appropriate when *order or sequence matters* — steps in a process, ranked priorities, a workflow Claude should follow. Use bullets when items are unordered; use numbers when sequence is part of the meaning. ## Code fences: keeping content out of the instruction layer One of the more practically important habits is wrapping any content you want Claude to *work on* (rather than *follow*) in a code fence. If you paste raw text into a prompt without delimiting it, Claude can conflate the content with the instructions — especially if the content itself contains instructional-sounding language. Suppose you want Claude to proofread a note that happens to contain the sentence "Always use formal language." Without a fence, Claude might treat that as a formatting directive for its response. With a fence: ```` ## Content to proofread ``` Always use formal language. This make the email sound more profesional. ``` Fix spelling and grammar errors only. Do not change the tone or content. ```` The fence creates an unambiguous boundary. Claude knows the fenced block is *subject matter*, not *instruction*. Use this any time you're feeding Claude a document, code snippet, template, or example text that should be treated as input rather than guidance. ## XML-style tags: when Markdown isn't enough For complex prompts — especially ones with multiple content blocks, nested structures, or content that itself contains Markdown — XML-style tags are a more robust delimiter than headings or fences. Anthropic explicitly recommends them for this purpose, and they work because they provide unambiguous open/close boundaries that can't be confused with anything else in the text. You don't need valid XML. Semantic intent is what matters. Common patterns: ``` You are a copyeditor. Review the draft below and suggest changes. The new policy effect all employees starting in Q3. Return a bulleted list of suggested edits, each with a brief rationale. ``` Tags like ``, ``, ``, ``, and `` are widely used and self-documenting. A prompt structured this way is also easier to maintain: you can swap out the `` block without touching the instructions, or copy the instruction block wholesale into a new prompt. The practical rule of thumb: use Markdown headings and lists for prompts you're typing in real time; reach for XML tags when you're building a reusable template, when the content itself contains Markdown that might confuse the heading hierarchy, or when you need absolutely clean boundaries between multiple content types. ## Controlling output format explicitly Claude will often infer a reasonable output format from context, but "often" is not "always," and inference breaks down when your needs are specific. If you want a table, say so. If you want plain prose without any bullet points, say that. If you want a JSON object, specify the exact keys. The most reliable pattern is a dedicated output format section at the end of your prompt: ``` ## Output format - Use a Markdown table with columns: Term | Definition | Example - No introductory sentence before the table - No closing summary ``` Prefilling the response — starting Claude's reply for it — is a related technique. If you begin the assistant turn with `| Term | Definition | Example |`, Claude will continue in that format rather than deciding for itself. This is especially useful when you need strict formatting and can't afford Claude to "helpfully" add a preamble. ## Practice Take a prompt you've used before that produced an imperfect or inconsistent result — ideally something with multiple requirements. Rewrite it using the following structure: 1. A `` tag establishing who Claude is and what situation it's in. 2. A `` tag with a numbered list of steps or a clear directive. 3. A `` tag with a bullet list of rules. 4. An `` tag specifying exactly what the response should look like. Run both versions (original and restructured) and compare the outputs. Note specifically whether the restructured version handles your constraints more completely and whether the format matches your specification more closely. Adjust the tag names and section order based on what you observe.

Markdown for Obsidian and Claude