Below are 14 Claude prompts for long documents, analysis and thinking, writing and critique, and code. Each one is ready to copy and follows Anthropic's prompting best practices guide.
How to use these prompts
Every prompt below is ready to copy. Replace the blanks in double braces with your own text, or keep the default after the colon: {{audience:a busy executive}} means "a busy executive" unless you change it.
These prompts lean on what Claude does well: reading long material closely, holding a careful argument, writing in a specific voice, and giving honest critique. Many of them wrap your material in tags like <document> and ask the question at the end. That is not decoration. It follows Anthropic's own prompting advice, covered in the last section, and it keeps Claude from confusing your instructions with the text you pasted.
Long documents
1. Summarize a long document with evidence
Use it on reports, papers, transcripts or contracts when you need the gist and want to trust it. Asking for quotes first keeps the summary tied to what the document actually says.
<document>
{{document}}
</document>
You are summarizing the document above for {{audience:a busy executive}}.
First, pull out the 5 to 10 passages that matter most and put them in
<quotes> tags, word for word. Then, using only those quotes, write:
1. A one-sentence summary.
2. The key points as short bullets, most important first.
3. Anything the document leaves unclear or unsupported.
Do not add facts that are not in the document.
2. Answer questions from a document only
When you need answers you can check, such as from a policy, manual or spec. The rule about saying "not in the document" is the important part.
<document>
{{document}}
</document>
Answer the questions below using only the document above. For each answer,
quote the sentence that supports it. If the document does not answer a
question, write "Not in the document" and say what information is missing.
Do not guess.
<questions>
{{questions}}
</questions>
3. Compare two versions of a document
For contract redlines, policy updates or a spec that changed between drafts. Claude is good at spotting changes in meaning, not just in wording.
<old_version>
{{old_version}}
</old_version>
<new_version>
{{new_version}}
</new_version>
Compare the two versions above. List every change that affects meaning:
obligations, numbers, dates, scope, who is responsible, and anything removed.
Ignore pure wording or formatting changes.
For each change give: the section, what it said before, what it says now, and
why it matters to {{reader:someone signing this}}. End with the three changes
most worth pushing back on.
Analysis and thinking
4. Stress-test a decision
Use it before you commit to something expensive or hard to undo. It asks Claude to argue against you, which is where it is most useful.
I am about to make this decision:
<decision>
{{decision}}
</decision>
<context>
{{context}}
</context>
Act as a thoughtful skeptic. Give me:
1. The strongest case against this decision, in one paragraph.
2. The three assumptions it depends on most, and how I could test each one
cheaply within {{timeframe:two weeks}}.
3. What would have to be true for this to be a mistake in a year.
4. Your honest overall view, in two sentences.
5. Find what matters in a dataset
Paste a CSV or a table. Asking for checks on the data first stops Claude from building conclusions on broken numbers.
<data>
{{data}}
</data>
I want to understand {{question:what changed in the last quarter and why}}.
Before analyzing, list any problems with the data: missing values, odd
outliers, columns that look mislabeled. Then give the three to five findings
that best answer my question. For each finding, show the numbers behind it
and say how confident you are. Finish with one chart you would make to show
the main finding, described in a sentence.
6. Research brief on an unfamiliar topic
For getting up to speed before a meeting or a decision. The request to separate settled facts from open questions keeps it honest.
I need to understand {{topic}} well enough to
{{goal:hold my own in a meeting with specialists}}.
Write a brief with these sections:
- The basics, in plain language (under 150 words)
- Key terms I will hear, each defined in one line
- What experts broadly agree on
- What is still debated or uncertain
- Five smart questions I could ask
Tell me where your knowledge may be out of date or thin.
Writing and critique
7. Honest editor
Use it on any draft you care about. Claude tends to be polite; this prompt gives it permission to be useful instead.
<draft>
{{draft}}
</draft>
You are a demanding editor. The draft above is for
{{audience:readers who don't know the topic}} and its goal is {{goal}}.
Tell me, in order of importance:
1. Whether the main point is clear, and what you think it is.
2. Where a reader would get lost or stop reading.
3. Claims that need evidence or should be cut.
4. Sentences that are vague, padded or repetitive, with tighter rewrites.
Do not rewrite the whole draft. Be direct; I can take it.
8. Write in my voice
When you want a draft that sounds like you. Anthropic's guide says examples are one of the most reliable ways to steer tone, so give two or three real samples.
<examples>
<example>
{{sample_1}}
</example>
<example>
{{sample_2}}
</example>
</examples>
The examples above are things I wrote. Study the sentence length, word
choice, level of formality and how I open and close.
Now write {{piece:a LinkedIn post}} about {{topic}} in the same voice. Keep it
under {{length:200 words}}. Do not copy phrases from the examples.
9. A difficult email
For saying no, delivering bad news or asking for something awkward. Clear, kind and short beats long and apologetic.
Write an email to {{recipient}} that {{purpose:declines their request}}.
Background:
{{background}}
Keep it under 150 words. Be clear about the outcome in the first two
sentences, warm but not apologetic, and offer {{alternative:one concrete next step}}.
Give me two versions: one more formal, one more casual.
10. Interview me, then write the spec
Use it when the idea is in your head and not on paper yet. Claude asks the questions a good colleague would, one at a time.
I want to write a {{document_type:product spec}} for {{idea}}.
Interview me first. Ask one question at a time, wait for my answer, and ask
follow-ups where my answer is vague. Cover the problem, who it is for, what
success looks like, scope and what is out of scope, and risks. Stop after at
most {{max_questions:10}} questions.
Then write the document with clear headings, using my answers and nothing I
didn't say. Mark any gaps as "Open question".
Code
11. Explain an unfamiliar codebase
Paste the key files, or run it in Claude Code from the repo root. It gives you a map before you start changing things.
<code>
{{code}}
</code>
I am new to this codebase and need to {{task:fix a bug in checkout}}.
Explain:
1. What this code does overall, in three sentences.
2. The main pieces and how data flows between them.
3. The files and functions most relevant to my task.
4. Anything surprising or risky I should know before changing it.
Refer to real file and function names. Do not suggest changes yet.
12. Plan a change before writing code
The best way to get good code from Claude is to agree on the plan first. Review the plan, then say "go".
I want to {{change}} in this {{language:TypeScript}} project.
<relevant_code>
{{code}}
</relevant_code>
Do not write code yet. Give me a plan:
- The files you would change and why
- The approach, and one alternative you rejected
- Edge cases and what could break
- How we will test it
Keep the plan under 300 words. Wait for my approval before implementing.
13. Debug with a hypothesis list
For bugs where the cause is not obvious. Ranking hypotheses keeps Claude from fixing the first thing it sees.
<bug>
Expected: {{expected}}
Actual: {{actual}}
Error or logs: {{error}}
</bug>
<code>
{{code}}
</code>
List the three most likely causes, ranked, with the evidence for each. For
the top cause, show the smallest fix and a test that would have caught it.
If you need more information to be sure, say exactly what to check.
14. Teach me with checks
For learning anything: a library, a statistics idea, a legal concept. The quiz at the end tells you whether it stuck.
Teach me {{topic}}. I already know {{background:the basics of programming}}.
Explain it in short sections, building from simple to advanced, with one
concrete example each. After each section, ask me one question to check my
understanding and wait for my answer before moving on. If I get it wrong,
explain it a different way.
How do you prompt Claude well?
To prompt Claude well, be clear and direct, explain why, show examples, use XML tags for structure, put long documents first, say what to do rather than what not to do, and give it a role. Anthropic publishes a prompting best practices guide for its current models. The prompts above follow it. These are the parts that matter most in everyday use:
- Be clear and direct. The guide suggests treating Claude like a brilliant new employee who doesn't know your norms. Its test: if a colleague with little context would be confused by your prompt, Claude will be too. Say what output you want, and use numbered steps when order matters.
- Explain why. Give the reason behind an instruction, not just the rule. "This will be read aloud, so avoid symbols" works better than "no symbols", because Claude can generalize from the reason.
- Show examples. A few examples steer format and tone reliably. The guide recommends three to five, varied enough to cover edge cases, wrapped in
<example>tags so Claude can tell them apart from your instructions. - Use XML tags for structure. When a prompt mixes instructions, context and pasted material, put each in its own tag, like
<instructions>,<context>or<document>. Pick descriptive names and keep them consistent. - Long documents go first. Put long material at the top and your question at the end. For long documents, ask Claude to quote the relevant parts before it answers.
- Say what to do, not what not to do. "Write in flowing paragraphs" works better than "don't use bullet points". Matching your own prompt's style to the output you want also helps.
- Give it a role. One sentence, such as "You are a demanding editor", focuses the tone and depth.
If you find yourself writing the same structure again and again, the prompt templates page has reusable versions with blanks.
Make your favorite one a skill
If you use a prompt every week, stop pasting it. Turn it into a skill, and Claude Code will use it on its own whenever a task matches. Paste prompt 7 or prompt 12 into the SKILL.md generator and it becomes a valid SKILL.md, with each blank turned into an instruction like "If the audience isn't given, use 'readers who don't know the topic'." The Claude skills guide explains how skills load and where they live.
To keep prompts like these one keystroke away, save them in Kipt: paste to save, press ⌘K to find one, and Enter copies it. Blanks open a small fill-in form, and Kipt remembers what you typed last time. Your library lives in your own private GitHub repo, and the prompts you promote to skills install with one command.