Claude Prompts, and What Makes Them Different

Search claude prompts and you land in one of two places. Official documentation, which is thorough and written for developers shipping applications, or a copy-paste collection. The GitHub one sitting on page one has about 5.4k stars as I write this. Both are fine and neither is written for the person who's just typing into the chat box trying to get work out the other side.

Short answer if you're skimming. The structure that makes Claude prompts different is XML tags. Wrap your instructions, your context, your pasted material, and your examples in their own labelled tags and the model stops confusing one for another, which is the single biggest quality jump available. Second biggest is examples, and Anthropic's docs recommend three to five. Third is a rule that runs against instinct, where long pasted documents go at the top of your prompt and your actual question goes at the bottom.

Everything else is roughly the same advice you'd give for any model. I'll go through the parts that aren't.

Why Tags Instead Of Just Writing Clearly

Because a prompt with several kinds of content in it is genuinely ambiguous, and being a good writer doesn't fix that.

Picture a prompt where you've got some instructions, a client's email pasted in, an example of the output you want, and a question. In plain prose, all four of those are just text in a row, separated by nothing but a blank line and your hopeful assumption that the model can tell your voice from the quoted voice, which it usually can, right up until the moment the pasted email happens to contain a sentence that reads like an instruction. Then it does what the email said.

Anthropic's documentation recommends wrapping each type of content in its own tag, using names like instructions, context and input, and says consistent descriptive tag names across your prompts help. Their advice on nesting is worth stealing too, so multiple documents go inside a documents wrapper with each one in its own document tag.

It costs nothing. That's the part I'd emphasise. There's no cleverness required, you just put angle brackets around things you were already going to type.

The Same Task, Written Two Ways

Here's a job I do often, which is turning a pile of rough notes into a structured brief.

The way most people write it:

Here are my notes about the video project I'm planning, can you turn them into a proper brief with sections. Keep it under 500 words and don't add anything I didn't say. Notes are below. [notes pasted]

The way I write it now:

<instructions>
Turn the notes into a production brief. Do not add facts that are not in the notes.
If something important is missing, list it under a "Gaps" heading rather than inventing it.
</instructions>

<format>
Under 500 words. Sections: Premise, Look, Shots, Gaps.
</format>

<notes>
[notes pasted]
</notes>

What changes in the output, consistently enough that I stopped testing it, is the invention. The first version fills gaps. It's being helpful, and helpfulness looks like a complete brief, so what comes back is a complete brief with two or three specifics I never actually said, sitting there in the same confident register as the parts I did say, which is a nastier failure than an obviously wrong answer because you have to reread your own notes to catch it. The second version puts them under Gaps, because I gave the instruction its own space where a pasted note can't dilute it.

The other thing I'd point at is that the tagged version is easier to edit next week. You can see the seams, so you change one block without rereading the whole thing. Prose prompts turn into a paragraph you're scared to touch.

The Long Document Rule Is Backwards From Instinct

Most people paste the document at the bottom. You write your question, then you go "here's the file", then you paste.

Anthropic's docs say to do the opposite when you're working with large inputs, roughly 20k tokens and up. Longform data at the top, above your query and your instructions and your examples. Their note claims queries at the end can improve response quality by up to 30 percent in their testing, particularly with complex multi-document inputs.

I can't verify their number and I'd treat any single vendor figure carefully. What I can say is the ordering costs nothing, so there's no reason not to adopt it, and the effect I do notice on long inputs is less about accuracy and more about the model not losing the thread of what I asked for by the time it's finished reading.

There's a companion trick in the same section that I use more than the ordering one. For long documents, ask it to pull the relevant quotes out first, into their own tag, and then do the task based on those quotes. It slows the response down and it makes the reasoning inspectable, which matters when the task is something you'll be held to.

Their List, Ranked By What I Actually Notice

Anthropic publishes a fairly long list of techniques, split into model-specific guidance and general principles, and updated per model generation. All of it is defensible. Not all of it moves the needle equally for chat-window work, so here's my own ordering.

That "ask for above and beyond explicitly" one deserves a sentence. Their documented example contrasts "create an analytics dashboard" against the same request plus a line asking for as many relevant features and interactions as possible, going beyond the basics. It reads like it shouldn't work. It does though, and once I'd noticed that I started bolting an equivalent line onto anything where the minimum viable answer would annoy me, which turns out to be most requests I make, since the default behaviour of any assistant is to give you a defensible small answer rather than risk overshooting.

Using Claude To Write My Image Prompts

This is the workflow the SERP doesn't cover at all, and it's the one I use most.

Image prompts want photographic vocabulary, and most people don't have it. I didn't. What I do have is a clear picture in my head and the ability to describe it badly. So the job I hand Claude is translation, not creativity.

The shape of it:

<task>
Write three image prompts for a text-to-image model, based on the scene I describe.
</task>

<rules>
Caption style, not instructions. No words like professional, stunning, high quality.
Order each prompt: subject, lighting, shot and lens, setting, style and medium, exclusions.
Six to nine clauses. Vary only the lighting between the three.
</rules>

<scene>
[my bad description]
</scene>

Three prompts, differing on one axis, which is exactly what you want for testing since it isolates a variable. The rules block is the important part and it took a few rounds to settle. Without it I got the adjective soup that every model produces by default, all "breathtaking" and "ultra detailed", which is precisely the vocabulary that drags an image toward stock photography.

I run the outputs locally, so testing three variants costs me time and not much else, and that changes the whole economics of learning this. When each generation costs credits people guess. I'd rather render all three, keep the one that works, and paste the winning lighting phrase back into the rules block so the next batch starts smarter.

Same approach works for motion. Ask for the still first, then ask for the same scene rewritten as a video prompt with camera movement and a single action, keeping the visual description identical. Splitting it in two steps produces better clips than asking for a video prompt cold, in my experience, though I'll admit video is the area where I'm least confident about anything. More on that side in ai video prompts, and the underlying image vocabulary is in ai image prompt.

Where This Falls Down

Two places, and I'd rather say them than pretend.

Long conversations drift. Constraints you set at the top get quietly softer somewhere around the twentieth exchange, never dramatically and never in a way you can point at in any single message, just a slow loosening until you look up and realise the tone has moved half a step from where you set it and you've been accepting that for a while. Restating the constraints fixes it. So does starting fresh and pasting the good output back in as an example, which is what I do when the thread has gone long enough that I'd rather not scroll it.

And the tagged style is genuinely worse for quick throwaway questions. If I want a word or a date, typing angle brackets is silly. The structure earns its keep when there's pasted material, when the output format matters, or when I'll want to reuse the prompt. Otherwise it's ceremony.

Questions

Do ChatGPT prompts work on Claude? Mostly, at the level of what you're asking for. The formatting is where they diverge, since Anthropic recommends XML and OpenAI's developer documentation mentions Markdown and XML for marking boundaries. Converting is usually a matter of adding tags rather than rewriting, and the general framework is the same six slots I laid out in chatgpt prompts.

Is there an official Claude prompt library? Yes, and there's one specifically for the coding tool, published as copy-paste prompts tagged by task with variable slots written in. Worth browsing for the pattern even if you never write code, because seeing how the people who make the model write templates is instructive.

Does the model know which version of itself it is? Not reliably, and Anthropic's docs actually include a suggested line you can put in a system prompt to tell it. Which tells you something about how often that comes up.

Should I pay for a prompt pack? No. Between the official library, the community GitHub collections, and the documentation itself, everything you'd pay for is already sitting in public. Money is better spent on generation credits, or on nothing.

What about images and video, does Claude make those? No, it writes about them. It's a text model that reads images well, and Anthropic's docs note you can analyse video by breaking it into frames. For actually generating pictures you're going to a different tool, which is why the translation workflow above exists.

Is prompt engineering worth learning as a skill? The phrasing tricks aren't. The specification habit is, and it transfers to every model and probably to briefing humans too. I've written about the general version in ai prompts and the deeper technique side in chatgpt prompt engineering.

The Bit I'd Keep

If you take one thing, take the tags. It's a five second change to how you type and it removes an entire category of problem, which is the model mistaking your pasted material for your instructions.

If you take two, add three examples of the output you want.

Everything after that is refinement, and honestly a fair amount of it is refinement you'll only need if you're building something rather than working in a chat window. I spent a while reading the full documentation as though it were all equally relevant to me. It isn't, and I'd have got further faster by adopting two things properly instead of eight things badly.