Claude Prompt Templates (What Changes vs ChatGPT)

TL;DR: Most ChatGPT prompts run on Claude unchanged. Four things genuinely differ: long documents go near the top and the question at the end, sampling parameters return a 400 error, prefilling the assistant turn is dead, and there is no developer role. Twenty Claude prompt templates below.

What actually changes when you move a prompt from ChatGPT to Claude?

Less than the comparison posts suggest, and the parts that do change are documented rather than vibes. Both vendors publish prompting guidance, and where they disagree they disagree in writing, with URLs you can check. Here is the whole delta, as of August 27, 2026.

Everything not in that table ports. Role framing, few-shot examples, explicit output formats, numbered constraints, evaluation criteria, tone instructions: paste them across and they behave. If you want the broader head-to-head on output quality rather than syntax, ChatGPT vs Claude on prompt writing covers that ground.

Do temperature and top_p still work in a Claude prompt?

No, and this is the single most common piece of dead advice in circulation. Anthropic's Messages API reference now marks all three sampling parameters deprecated. The wording is specific and worth reading in full, because the three fields fail in three different ways.

On temperature: "Models released after Claude Opus 4.6 do not support setting temperature", with 1.0 accepted for backwards compatibility and "all other values will be rejected with a 400 error". On top_p: same shape, except the tolerated value is anything at or above 0.99. On top_k there is no tolerated value at all. The reference says models after Opus 4.6 "do not accept top_k; any value will be rejected with a 400 error". (Messages API reference, accessed Aug 27, 2026)

For template purposes the consequence is simple. Any instruction that used to live in a parameter now lives in the prompt. Instead of dropping temperature to 0.2 for an extraction job, you write the determinism requirement into the text.

Return only values that appear verbatim in the source. Do not paraphrase,
infer, round, or fill gaps. If a field is absent, return null for that field.

The Claude app never exposed sampling controls anyway, so this only bites people porting API code.

Should the document go at the top of the prompt or the bottom?

Top, on Claude. This is the one placement rule where the two vendors give you opposite instructions in their current documentation, and it is the difference most worth acting on.

Anthropic's prompting best practices page, under long context prompting, says to "Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples", and adds that "Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs". (Prompting best practices, accessed Aug 27, 2026)

OpenAI's current prompt engineering guide sets out a developer-message order of Identity, Instructions, Examples, Context, and says of that last section: "This content is usually best positioned near the end of your prompt, as you may include different context for different generation requests." (OpenAI prompt engineering guide, accessed Aug 27, 2026) OpenAI's older GPT-4.1 guide adds a long-context caveat of its own: "If you have long context in your prompt, ideally place your instructions at both the beginning and end of the provided context".

Separate the two questions and the apparent conflict dissolves. Data placement differs by vendor. Instruction placement is a repetition question, and repeating the instruction at both ends costs you nothing on either model.

So a ChatGPT prompt shaped like this:

You are a contracts analyst. Read the agreement below and list every
obligation that falls on the vendor.

[12,000 words of contract]

becomes this on Claude:

<contract>
[12,000 words of contract]
</contract>

You are a contracts analyst. List every obligation that falls on the vendor.
Quote the clause number for each one.

Is prefilling Claude's reply still a valid template trick?

No. Prefill is probably the most widely taught Claude-specific trick on the internet, and on current models it returns an error.

Anthropic's best practices page states that "prefilled responses (providing a partial assistant message for Claude to continue from) on the last assistant turn are no longer supported" starting with Claude 4.6 models, and that "Requests with prefilled assistant messages to these models return a 400 error". Earlier models still accept them, and assistant messages elsewhere in the conversation are unaffected.

Anthropic's own consistency guide has not caught up cleanly. It still carries a section headed "Prefill Claude's response" whose body says "Prefill the Assistant turn with your desired format." A note added above that body now reads "Prefilling is not supported on Claude 4.6 and later models", pointing readers at structured outputs instead. (Increase output consistency, accessed Aug 27, 2026) So the page warns and then teaches, which is how the technique keeps propagating.

The documented migration path is structured outputs, and it is no longer a beta feature. Anthropic's page states that "The output_format parameter has moved to output_config.format, and beta headers are no longer required." One incompatibility survives the move: the same page lists Message Prefilling as "Incompatible with JSON outputs", so the two were never going to coexist anyway.

The ChatGPT-shaped version of this pattern, which does not error but does not guarantee anything either:

Respond only with JSON. Do not include any commentary.
Begin your response with {

The Claude-shaped version, where the constraint is enforced by the request rather than by hope:

"output_config": {
  "format": {
    "type": "json_schema",
    "schema": {
      "type": "object",
      "properties": {
        "sentiment": {"type": "string", "enum": ["positive", "neutral", "negative"]},
        "confidence": {"type": "number"},
        "evidence": {"type": "string"}
      },
      "required": ["sentiment", "confidence", "evidence"],
      "additionalProperties": false
    }
  }
}

Where does the system prompt live in a Claude template?

In a top-level system field on the request, not in a message. That is the structural difference, and both vendors have made it messier than it needs to be.

Anthropic's Messages API prose is explicit that "there is no "system" role for input messages in the Messages API", and directs you to the top-level parameter. The same reference document lists the message role enum as "user" or "assistant" or "system". Both were live on August 27, 2026. Read them together and the safe reading is the one Anthropic's own examples use: put the system prompt in the system parameter and treat a system-role message as an edge case, not a default.

OpenAI has drifted the other way. Its text generation guide now shows a role table containing only developer, user and assistant, with no system row, describing developer messages as "instructions provided by the application developer, prioritized ahead of user messages". Its OpenAPI specification states the reason directly: "With o1 models and newer, developer messages replace the previous system messages." Yet the Responses API reference still accepts system and says "Instructions given with the developer or system role take precedence over instructions given with the user role."

Practically: write system on Claude, write developer on OpenAI, and expect system to keep working there for a while. If the whole system-versus-user question is new to you, system prompts versus user prompts is the primer.

Do Claude templates need XML tags, or is Markdown fine?

Both work. XML is the house style Anthropic documents, and it earns its place once a prompt contains more than one kind of content.

The best practices page puts it plainly: "XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs." For examples specifically it asks you to "Wrap examples in <example> tags (multiple examples in <examples> tags) so Claude can distinguish them from instructions." For multi-document inputs it publishes a nested shape: a <documents> wrapper, one <document index="n"> per file, each carrying <source> and <document_content>.

One thing Anthropic does not say, despite the internet saying it constantly, is that Claude was specially trained on XML. That claim appears nowhere in the current documentation. Tags help because they remove ambiguity, which is a boring and sufficient explanation.

OpenAI's position is close but not identical. Its prompt engineering guide recommends Markdown and XML together, and its GPT-4.1 guide ranks Markdown first while noting that "XML performed well in our long context testing" and that, for stuffing many documents into context, "JSON performed particularly poorly". So the honest summary is that XML is safe everywhere, Markdown is safe everywhere, and JSON is the one to avoid as a container even though it is fine as an output format. There is a fuller treatment in using XML tags in Claude prompts, and a cross-vendor view in the model-specific formatting cheat sheet.

Should a Claude template still say "think step by step"?

Usually not, and the reason is that reasoning is now a request setting rather than a prompt trick. Anthropic's current models use adaptive thinking, where the model decides how much to think based on the effort setting and the complexity of the query.

What remains promptable is the shape of that thinking. Anthropic's own sample instruction steers reflection after tool use rather than demanding a visible chain of thought:

After receiving tool results, carefully reflect on their quality and determine optimal
next steps before proceeding. Use your thinking to plan and iterate based on this new
information, and then take the best next action.

The related trap is reaching for effort as a brevity control. Anthropic's effort documentation says outright that "Effort controls thinking volume, not visible response length", and its Opus 5 prompting page adds "To control response length, prompt for it explicitly." If you want a shorter answer, ask for one in the prompt. Chain-of-thought phrasing still helps on models without thinking enabled, so keep it in templates you run on older or cheaper models.

Why do negative instructions behave differently on Claude?

Because Anthropic asks you not to write them. Under output formatting, the first documented rule is "Tell Claude what to do instead of what not to do", with a worked pair: instead of "Do not use markdown in your response", try "Your response should be composed of smoothly flowing prose paragraphs."

This is not a claim that Claude ignores negations. It is a claim that positive instructions are more reliable, and it is the one place where a mechanical pass over your existing templates pays off immediately. Find every "don't" and ask what the positive version of that sentence would be.

How much can you paste into a Claude prompt?

More than you think, and the number depends on which surface you are using. This trips people up because the API and the chat app publish different figures for the same model on the same day.

Anthropic's API documentation states that "Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, and Claude Sonnet 4.6 have a 1M-token context window on the Claude API", with other models including Claude Sonnet 4.5 at 200K. (Context windows, accessed Aug 27, 2026)

Anthropic's help centre, describing the chat product rather than the API, says Opus 5 and Sonnet 5 get 1M on all paid plans, while "Claude Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6 support a 500K token context window on all paid plans when chatting with Claude", with everything else at 200K. (How large is the context window on paid Claude plans, accessed Aug 27, 2026)

Both pages are current, and they are not in conflict: they describe different products. The rule is that a template built for the API may not fit in the app on the same model, so size your input against the surface you actually use.

20 Claude prompt templates you can copy

Every template below follows the documented conventions: input near the top, question at the end, XML tags for anything with more than one content type, positive instructions, no sampling parameters. Square brackets are the parts you replace. The system block, where shown, goes in the top-level system field rather than in a message.

Writing

1. Draft in a captured voice

<voice_samples>
[3 to 5 paragraphs you have already written and like]
</voice_samples>

<brief>
Audience: [who]
Purpose: [what should change in their head]
Length: [word count]
Must include: [facts, links, names]
</brief>

Write a [format] following the brief. Match the vocabulary, sentence
length and rhythm of the voice samples. Where the brief and the samples
conflict, follow the brief.

2. Rewrite without losing the argument

<original>
[the text]
</original>

Rewrite the text above so that a [audience] can follow it. Preserve every
claim and every number. Keep the same order of argument. Return only the
rewritten text.

3. Headline set with stated angles

<context>
Product: [what it is]
Reader problem: [the pain in their words]
Proof we can use: [numbers, names, dates]
</context>

Write 12 headlines. Group them under three labelled angles, four per angle.
After each headline, add one line naming which reader belief it depends on.

4. Tone pass, positively phrased

<draft>
[the text]
</draft>

Edit the draft so it reads as [target tone]. Use concrete nouns and active
verbs. Keep paragraphs under four sentences. Preserve all factual content.
Return the edited draft, then a short list of the changes you made and why.

Analysis

5. Long-document interrogation

<document>
[the whole document]
</document>

You are a [role]. Answer the following question using only the document above.
Quote the sentence you relied on for each part of your answer. If the document
does not answer a part, say which part and stop there.

Question: [the question]

6. Multi-document comparison

<documents>
  <document index="1">
    <source>[filename or title]</source>
    <document_content>[text]</document_content>
  </document>
  <document index="2">
    <source>[filename or title]</source>
    <document_content>[text]</document_content>
  </document>
</documents>

Identify every point where these two documents disagree. For each disagreement,
quote both sides and name which document is more recent. Report the
disagreements before any summary.

7. Decision memo from raw notes

<notes>
[meeting notes, transcripts, threads]
</notes>

Produce a decision memo with four sections: the decision to be made, the
options on the table, what each option costs us, and what we would need to
know to choose. Attribute each option to whoever proposed it. Mark anything
you inferred rather than read with the word INFERRED.

8. Red-team a plan

<plan>
[the plan]
</plan>

<constraints>
Budget: [number]
Deadline: [date]
Team: [size and skills]
</constraints>

List the five ways this plan most plausibly fails, most likely first. For each
one, give the earliest observable signal that it is happening. Argue against
the plan as written rather than proposing a different plan.

Code

9. Review with a stated standard

<diff>
[the diff]
</diff>

<standards>
[link or paste your house rules, or say: none, use common practice]
</standards>

Review this diff against the standards. Report findings in three groups:
correctness, security, maintainability. Give each finding a file and line
reference. Say explicitly if a group has no findings.

10. Explain unfamiliar code

<code>
[the file or function]
</code>

Explain what this code does, in the order a reader would need to understand it.
Name every external thing it depends on. Then list what would break if it were
deleted. Write in prose paragraphs rather than bullet points.

11. Refactor with a preserved contract

<code>
[the code]
</code>

<contract>
Public functions that must keep their names and signatures: [list]
Behaviour that must not change: [list]
</contract>

Refactor the code for [readability / performance / testability]. Everything in
the contract stays identical. Return the refactored code, then a short list of
what changed and why each change is safe.

12. Reproduce and fix a bug

<code>
[relevant files]
</code>

<observed>
Expected: [what should happen]
Actual: [what happens]
Environment: [versions, OS, runtime]
</observed>

Work out the smallest change that fixes this. Before proposing it, state the
mechanism you believe causes the bug and what evidence in the code supports it.
If the evidence is not in what you were given, say what you would need to see.

Research

13. Source-grounded question answering

<sources>
  <source id="1" title="[title]" date="[date]">[text]</source>
  <source id="2" title="[title]" date="[date]">[text]</source>
</sources>

Answer the question using only these sources. Cite the source id after every
claim. Where sources disagree, present both positions and say which is more
recent. If none of them answer the question, say so.

Question: [the question]

14. Literature synthesis with a stated method

<papers>
[abstracts or full texts, each in its own tag]
</papers>

Synthesise these papers around [theme]. Organise by finding rather than by
paper. For each finding, name which papers support it and which contradict it.
End with the questions this set of papers leaves open.

15. Extract a claim ledger

<article>
[the text]
</article>

List every factual claim in this article that could be checked against an
outside source. For each one give the claim as written, the sentence it appears
in, and what kind of source would settle it. Ignore opinions and predictions.

16. Brief a specialist

<background>
[what you already know]
</background>

<gap>
[what you are trying to find out]
</gap>

You are a [specialist]. Before answering, ask me up to five questions that would
most change your answer. Wait for my replies. Then answer.

Extraction and structured output

17. Field extraction with a null rule

<document>
[invoice, contract, CV, email]
</document>

Extract the following fields: [list]. Return values exactly as they appear in
the document. If a field is absent, return null for it. Do not infer, round or
normalise anything.

18. Schema-enforced extraction

Send the document as the user message and enforce the shape on the request rather than in the text:

"output_config": {
  "format": {
    "type": "json_schema",
    "schema": {
      "type": "object",
      "properties": {
        "vendor": {"type": "string"},
        "invoice_number": {"type": "string"},
        "total": {"type": "number"},
        "currency": {"type": "string"},
        "due_date": {"type": "string"}
      },
      "required": ["vendor", "invoice_number", "total", "currency", "due_date"],
      "additionalProperties": false
    }
  }
}

19. Classification against a closed list

<item>
[the text to classify]
</item>

<labels>
[label]: [one-line definition]
[label]: [one-line definition]
[label]: [one-line definition]
</labels>

Assign exactly one label from the list. Then give the single sentence from the
item that most supports your choice. If the item fits none of the labels,
return the label "unclassified".

20. Table from unstructured text

<records>
[emails, tickets, notes, one per line or block]
</records>

Turn these into a table with the columns: [list]. One row per record, in the
order they appear. Leave a cell empty rather than guessing. After the table,
list any record you could not parse and say why.

What ports from ChatGPT with no changes at all?

Almost everything, and manufacturing differences would make this page worse. Role framing works identically. Few-shot examples work identically, and both vendors recommend three to five. Explicit output formats, numbered constraints, evaluation rubrics, personas and step-by-step task decomposition all behave the same way on both models.

Anthropic's own framing of the core skill is vendor-neutral enough to be a good test for any prompt: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too." That rule catches more real defects than any amount of XML.

So the migration order is: paste the prompt across unchanged, judge the output, and only then apply the four changes in the table at the top of this page. Rewriting first and evaluating second is how people conclude Claude is worse at something it is fine at.

How do you keep 20 templates without re-pasting them?

The templates above are only useful if they survive a working week, and a scratch document does not. A prompt you cannot find is a prompt you rewrite from memory, badly.

What we build at Prompt Architects is the layer underneath, and it is worth saying what that does not mean. We do not run the model for you or replace Claude. We store, structure and improve the prompt. The template library keeps these twenty as saved items with variables, so [audience] and [target tone] become fields you fill rather than strings you retype. Contexts let a brand voice or a codebase description ride along with every prompt. And because our MCP server connects to Claude Desktop, Claude.ai and Claude Code, the library is reachable from inside Claude rather than sitting in another tab.

On plans, plainly: the Free plan includes "5 prompt enhancements per day, forever" according to our /faq page, and /pricing lists Pro at $4.99/month for 200 prompts, Advanced at $9.99/month for unlimited, and Team at $10/month plus $3.50 per member. Both checked August 27, 2026, at launch-promotion prices. For the persistent-instruction side of the same problem, see Claude project instruction templates.

A short migration checklist

1. Is the long input above the question rather than below it?
2. Is every distinct content type inside its own XML tag?
3. Have you deleted every temperature, top_p and top_k argument?
4. Have you removed any prefilled assistant message?
5. Is the system prompt in the top-level system field, not a message?
6. Has every "do not" been rewritten as a "do"?
7. If the output must parse, is the schema on the request rather than in the prose?
8. Does the prompt still make sense to a colleague who has not seen the task?

Eight checks, roughly a minute per template. Seven of them are deletions, which is the honest summary of what changes when a prompt moves from ChatGPT to Claude: you take things out more often than you put things in.