Claude prompts: how to write the structure Claude rewards

No sign-up, nothing sent anywhere — the conversion runs in your browser. Here is the thinking it is built on.

What Claude actually rewards

Every model has a personality that comes from how it was built and trained, and Claude’s is unusually consistent: it is careful, it is literal, and it is honest to a fault. Those three traits are the whole reason Claude prompts look different from prompts you write for other assistants. Once you understand what Claude is optimizing for, the “tricks” stop being tricks and start being obvious. There are three traits worth building around.

It rewards structure over eloquence

Claude reads a prompt the way a meticulous contractor reads a spec: it wants to know which lines are the job and which lines are the materials. When you write everything as one flowing paragraph — “here’s my situation and also do this and keep it short and here’s some background” — Claude has to guess where your instructions end and your data begins. When you instead hand it labeled sections, that ambiguity vanishes, and its output gets noticeably sharper. This is why XML-style tags, which we will get to in a moment, matter more for Claude than almost any clever phrasing. Structure is not decoration here; it is the interface. The practical consequence is liberating: you can stop hunting for the perfect wording and just make the parts explicit. A blunt, plainly-labeled prompt beats a beautifully-worded jumble every time, because Claude is spending its effort on your problem instead of on parsing your paragraph.

It rewards long, pasted context

Claude is built to hold a great deal of material at once, which changes the economics of prompting. With many tools you feel pressure to trim and summarize before you paste; with Claude, the better move is usually to paste the whole thing — the full report, the entire transcript, the messy meeting notes — and let it do the reading. A summary you write by hand throws away the exact details Claude could have used, and it quietly bakes in your own assumptions about what mattered. The skill shifts from “compress the input” to “point Claude at the right part of a big input,” and that is a far more powerful place to operate from. It also means Claude can hold your standing rules, a reference document, and the live task in view simultaneously — so the same prompt can both carry your context and act on it without losing the thread.

It rewards honesty, and gives it back

Claude is tuned to avoid confidently making things up, and you can lean on that. Tell it to say “I don’t know” when your context does not cover something, and it will — instead of smoothing over the gap with a plausible invention. The flip side is that a vague, purposeless prompt can read as riskier than you meant it, and Claude answers cautiously or over-hedges. The remedy is never to argue with it; it is to add context. State who you are, why you need the output, and what you will do with it, and the caution usually melts because the ambiguity that caused it is gone. Treat honesty as a feature you can dial up on purpose: ask Claude to flag its own assumptions, to separate what the source actually says from what it is inferring, and to rate its confidence. You will trust the output more precisely because it stops pretending to be certain.

Put those three together and a picture emerges. Claude is at its best when you treat it less like a search box and more like a brilliant, deliberate colleague who wants a clear brief, all the relevant material, and permission to tell you when something is missing. None of this requires learning a special vocabulary or memorizing magic phrases. It requires the opposite — slowing down for thirty seconds to say plainly what you actually want and what Claude has to work with. Everything that follows is just how to write that brief.

The anatomy of a Claude prompt

A great Claude prompt is not longer or fancier than a bad one. It is sectioned. You take the tangle of intent in your head and lay it out as labeled parts, so Claude never has to guess which sentence was an instruction and which was background. The converter above builds exactly this skeleton; here is what each part is doing and why it earns its place. You will not always need every tag — a quick question needs no <examples> block — but knowing what each one is for means you always know which one to reach for when an answer comes back thin.

Tags: the fence between instructions and data

The single most Claude-specific habit is wrapping each part of your prompt in XML-style tags — <role>, <context>, <task>, <constraints>, and <format>. The tags are not magic syntax; they are a fence. They tell Claude, unmistakably, “this block is the material to work on, and that block is the instruction to follow.” The payoff is largest exactly when a prompt is complex — a pasted document plus an audience plus a set of rules — because that is when a plain paragraph is most likely to get its wires crossed. As a bonus, tagged prompts are trivially editable: swap the contents of <context> next week and the rest of the prompt keeps working untouched.

Explicit instructions: number the steps

Claude follows an ordered list of steps far more faithfully than the same steps buried in prose. If you need it to do three things in sequence, do not write “summarize this and then critique it and give me a rewrite” as one breath. Put them in a numbered <instructions> block: “1. Summarize. 2. Critique the summary against the goal. 3. Rewrite, fixing the weaknesses.” Numbering does two things at once — it guarantees nothing is skipped, and it lets you point at “step 2” when you iterate, instead of rewriting the whole prompt. Explicitness is not hand-holding; it is how you get repeatable output. The same discipline applies to anything you would otherwise leave implied: if the order of operations matters, number it; if a step depends on the one before it, say so; if there is a rule Claude must never break, give it its own line instead of tucking it into a clause. Claude will honor a boundary it can see far more consistently than one it has to infer.

Examples: show the target, do not describe it

A single concrete example teaches Claude more than a paragraph of adjectives. If you want a particular voice, paste one or two samples inside an <examples> block and tell Claude to match the rhythm and diction, not the topic. If you want a specific output shape, show the shape once. Claude is a superb imitator, and imitation is far more reliable than instruction when it comes to tone and structure. “Write in a warm, confident voice” is a guess; one real sentence of that voice is a target it can hit.

Order the prompt the way Claude reads it

Structure is not only which tags you use; it is the order you put them in. Claude reads top to bottom and tends to weight the most recent instruction most heavily, so put the durable, unchanging material first and the specific ask last. In practice that means the role and standing rules go at the top, a long pasted document sits in the middle, and your actual question lands at the very bottom, immediately before you hand control back to Claude. This matters most for long inputs: when a big <document> comes before the question rather than after it, Claude answers far more reliably, because it has already read all the evidence by the time it meets the ask. Front-load the context; end on the instruction.

Hand Claude the opening of its answer

One more lever is almost unfair in how well it works: give Claude the first few characters of its own reply. If you need clean JSON, tell it to begin its answer with an opening brace and nothing else; if you need a specific section, tell it to open with <answer>. Starting the response for Claude removes the little runway of throat-clearing — the “Sure, here is what you asked for” preamble — and locks it onto the exact shape from the very first token. It is the difference between asking for a format and committing Claude to one. Pair it with a tight <format> block and the output arrives clean enough to paste straight into whatever has to consume it next.

Finally, an optional but potent addition: a line telling Claude to think before it answers. Asking it to reason inside <thinking> tags first and only then produce the final answer visibly improves anything with moving parts — analysis, math, multi-constraint writing — because it gives Claude room to work before it commits. The converter above adds this line for you; leave it on for hard tasks and off for simple ones.

Four Claude patterns you can steal today

Anatomy tells you why; patterns tell you what to type. These four cover most real Claude work — and each is just the tagged structure above, applied to a common job. Steal them, fill in the brackets, and keep the ones that earn a place in your library. Notice how little each one relies on clever wording: the power is in the layout, not the language. Once you can see the same skeleton under all four, you can build a fifth for any new task in under a minute.

<role>You are a rigorous business analyst.</role>
<context>
<data>[paste the numbers / report / notes]</data>
Audience: [who reads this]
</context>
<task>Find the three findings that change a decision.</task>
<instructions>
1. Read <data> in full before concluding.
2. Rank findings by impact, not by order of appearance.
3. Cite the figure behind each claim.
</instructions>
<format>Three bullets, each: finding, evidence, so-what.</format>

<role>You are a senior engineer who values clarity.</role>
<context>
<code>[paste the function / file]</code>
Stack: [language, framework, version].
</context>
<task>Explain the bug, then fix it.</task>
<constraints>Match the existing style. Do not add dependencies. Add one test that fails before the fix.</constraints>
<format>Short diagnosis, then the corrected code block, then the test.</format>

<role>You are a careful research assistant.</role>
<document>
[paste the entire report / transcript — do not summarize it first]
</document>
<task>Answer: [your question] using only <document>.</task>
<constraints>If <document> does not answer it, say so. Quote the section you used.</constraints>
<format>Answer first, then the supporting quote.</format>

<role>You are a copywriter with a chameleon ear.</role>
<examples>
[paste 1–2 samples of the exact voice you want]
</examples>
<task>Write [the new thing] in the same voice.</task>
<constraints>Match rhythm and diction, not the topic. No clichés, no hype.</constraints>
<format>[e.g. a 120-word post]</format>

When Claude’s answer is still wrong: debug the prompt

Here is the mindset that separates people who get great output from people who give up: when the answer disappoints, they do not conclude the model is dumb. They read the failure like a bug report. Claude’s mistakes are rarely random — each one points straight back to a missing piece of structure, and with Claude specifically the tell is usually obvious once you know the pattern. Change one thing, run it again, and watch what moves. That is the difference between debugging and flailing. The instinct to fix everything at once is the real trap: rewrite the whole prompt and the output changes in five directions, and you learn nothing about which change did what. Move one tag, one rule, one line — and the next answer tells you exactly whether you found the leak.

Notice that every fix is a single, named move, because every symptom is a single, named gap. That is the quiet superpower of building on structure: it turns “this feels off” into “the format is unpinned” or “the source is not fenced,” which you can actually do something about. Paste your revised prompt back into the converter, or tweak the tag whose contents were thin, and re-run. Two or three passes is almost always enough to move a Claude prompt from erratic to dependable — and once it is dependable, you never have to solve that particular prompt again, because you can save it.

From one Claude prompt to a system

Here is the part nobody tells you: writing one great Claude prompt is a skill, but never having to write it twice is a superpower. The people who get the most out of Claude are not retyping tags every morning. They keep a library — a personal collection of prompts that already work — and they start every task by reaching for the closest one and tuning it. That is the entire idea behind PromptFork, and it maps onto three moves.

And when the closest prompt still is not close enough — a brand-new task, a strange edge case — that is what Studio is for. You describe your goal in plain language and it runs the same structural thinking you just read about through a two-stage pipeline, handing back a precision prompt you can use, refine, and publish back to the library. It is the “Supercharge with AI” button on the converter above: your rough idea in, a forged prompt out, five free every day. The converter teaches you the moves; Studio does them at speed; the library means you only ever solve each problem once.

And it compounds. In week one your Claude library is a handful of forked prompts. A month in, it is the scaffolding for most of what you do — the analysis that actually cites its evidence, the code review that catches real bugs, the draft that sounds like you. You stop starting from zero and start from the best version you have found so far, then improve it. That, in the end, is the whole difference between people who “use Claude” and people who quietly get twice as much out of it: not a secret model setting, but a better starting line. And because every forked prompt already carries its tags, its instructions, and its guardrails, your library keeps getting smarter without any extra effort from you — each fix you make to one prompt is a fix you never have to make again.

Claude prompts worth forking right now

Theory is cheap. Here are real, community-tested Claude prompts you can copy or fork this minute — each one is the tagged structure in the wild.

Questions people ask about Claude prompts