Claude examples: prompts and what they return

Concrete Claude prompts you can copy, grouped by job — analysis, coding, writing, research and automation — with notes on what each one is doing and which model to run it on.

These are Claude prompts you can copy, grouped by the job they do rather than by the feature they use: document analysis, research, coding, data work, writing, planning and automation. Each one comes with the technique it relies on, the model worth running it on, and what a good answer should look like when it comes back.

Nothing here is a transcript. Outputs vary between runs, so every example describes the shape of a good response and what to check, rather than inventing one. Model IDs and prices verified 21 August 2026.

#Document analysis: contracts, reports and long PDFs

This is the job Claude's 1M-token context was built for. The failure mode is not that Claude cannot read the document — it is that it will summarise things that are not in it. Every prompt below fights that.

#Extract obligations from a contract

You are reviewing the commercial agreement below.

Extract every clause that creates (a) a payment obligation, (b) a
termination right, or (c) an indemnity. For each, return:
  - clause number and heading
  - a one-sentence plain-English summary
  - the exact sentence it comes from, quoted
  - who it favours: us, the counterparty, or neither

If a category has no matching clause, write "none found" for that
category. Do not infer a clause that is not written down.
Output a markdown table, one row per clause.

<agreement>
[paste the full text]
</agreement>

Technique: bounded extraction with a “none found” escape hatch, plus XML-style tags separating instructions from source text. The mandatory quote is the load-bearing part — a fabricated clause has no sentence to quote.

Model: Sonnet 5 for a single agreement. Move to Opus 5 when you are cross-reading a stack of contracts and the reasoning matters more than the token bill.

What a good answer looks like: a table where every quoted sentence is findable with Ctrl-F in your source. Spot-check three rows; if one quote is not verbatim, discard the run and re-prompt with a smaller chunk.

#Interrogate a report you did not write

Read the attached report. Answer these three questions, and for each,
cite the page or section you took the answer from:

1. What is the central claim?
2. What evidence supports it, and how strong is that evidence?
3. What would have to be true for the central claim to be wrong?

If the report does not answer one of these, say "not addressed".

Technique: forced citation plus a “not addressed” option. Question 3 earns its keep — it turns a summariser into a reviewer.

#Research and synthesis

On paid plans, Research runs multiple chained searches and returns citations; it needs web search switched on first.

#Scan a market or a literature set

Research how [topic] has changed between January 2025 and today.

Structure the answer as:
  - what is settled and widely agreed
  - what is actively contested, with the competing positions named
  - what is asserted often but poorly evidenced

Cite a source for every factual claim. Where sources disagree, show
both rather than picking one. Flag anything you could only find on a
single source.

Technique: asking for a confidence gradient instead of a summary. “Poorly evidenced” as its own bucket is what stops confident-sounding filler.

Model: Opus 5, whose training data runs to May 2026 — newer than Sonnet 5 or Fable 5, both of which stop at January 2026. Search results still beat training data for anything recent.

#Turn interview notes into themes

Below are 12 customer interview transcripts, one per <interview> block.

Identify recurring themes. For each theme give:
  - a name
  - how many of the 12 interviews it appears in, and which numbers
  - two short verbatim quotes, with the interview number
  - the strongest piece of evidence against the theme

Do not merge two themes that point in different directions.

Technique: counts and interview numbers make the synthesis auditable. Demanding disconfirming evidence per theme is the cheapest guard against being told what your question implied.

#Coding

Serious coding work belongs in Claude Code rather than a chat window, because the model needs to read the repository and run the tests — setup routes are on Claude for developers. These prompts work in either place.

#Diagnose before you fix

The test suite fails intermittently on CI and passes locally.

Do not propose a fix yet. First:
  1. Read the failing test and everything it touches.
  2. List every hypothesis that could explain intermittent-only failure.
  3. For each, tell me the cheapest command or check that would
     confirm or eliminate it.

Then stop and wait. I will run them and report back.

Technique: an explicit stop point. Left alone, a coding agent guesses a cause and starts editing; splitting diagnosis from repair is the highest-value habit in agentic coding.

Model: Opus 5. Thinking is on by default on Opus 5, Sonnet 5 and Fable 5; depth is set by the effort parameter — low to max, default high — or the /effort command in Claude Code. See Claude’s thinking modes.

#Write SQL against a schema you supply

Dialect: PostgreSQL 16.
Schema:
  users(id, email, created_at timestamptz, plan text, deleted_at timestamptz)
  events(id, user_id, name text, occurred_at timestamptz)

Write one query returning users who signed up in the last 30 days and
have never fired an event named 'activated'. Exclude soft-deleted rows.

Then: state the assumption you made about time zones, and say which
index would make this query fast.

Technique: give the dialect and schema, and require the assumption to be stated. Almost every wrong SQL answer rests on an unstated assumption about nulls, time zones or soft deletes.

Model: Sonnet 5, or Haiku 4.5 if you are generating hundreds of queries programmatically.

#Review a diff like a reviewer, not a cheerleader

Review the diff below. Report only defects, ranked:

  BLOCKER — data loss, security, or breaks a documented contract
  MAJOR   — wrong under a plausible input
  MINOR   — maintainability

For each: file and line, what breaks, and a concrete input that
triggers it. Do not comment on style. Do not praise anything.
If you find nothing above MINOR, say exactly that.

Technique: severity buckets plus “a concrete input that triggers it”. Requiring a failing case forces the model to test its own claim, and quietly deletes most speculative findings.

#Data work

#Clean a messy export

The attached CSV is a sales export with inconsistent formatting.

Write and run Python that produces a cleaned file. Rules:
  - dates to ISO 8601; ambiguous formats go to a rejects file
  - currency as a decimal, with a separate currency-code column
  - de-duplicate on (customer_id, invoice_no), keeping the latest row
  - never silently drop a row: everything lands in cleaned or rejects

Print row counts for input, cleaned and rejected, and show me the
first ten rejects with the reason.

Technique: a conservation rule (“never silently drop a row”) plus a reconciliation count. If input does not equal cleaned plus rejected, you know immediately that something went wrong.

Model: Sonnet 5 with code execution. For spreadsheet-native work, Claude for Excel is on all paid plans.

#Classify at volume

Classify the support ticket below into exactly one category:
billing | bug | feature_request | account_access | other

Return only JSON: {"category": "...", "confidence": "high|low"}
Use "other" rather than guessing. Use confidence "low" whenever the
ticket could plausibly belong to two categories.

Ticket: <<<{{ticket_text}}>>>

Technique: a closed label set, a machine-readable output contract and an explicit dump category. The confidence flag is what lets you route the hard cases to a human.

Model: Haiku 4.5 — $1 in / $5 out per million tokens, the cheapest current model. Add the Batch API for a flat 50% discount if answers can wait. Cost mechanics are on the Claude API page.

#Writing and editing

Two starters; the full templates, including the draft-critique-revise loop, are on Claude as a writing assistant.

#Rewrite for a specific reader

Rewrite the text below for a hospital procurement officer who has no
technical background, is skeptical of vendor claims, and has 90
seconds.

Keep every factual claim intact. Cut jargon or define it inline on
first use. Lead with the decision they have to make. Maximum 200 words.
Then list, separately, anything you removed that they might have
needed.

Technique: naming the reader, their disposition and the time they have. “Make it simpler” produces mush; a named reader with 90 seconds produces edits.

#Critique before revising

Critique the draft below. Do not rewrite it.

Give me: the three weakest paragraphs and why; every claim that needs
a source; anything a hostile reader would attack first; and where the
argument actually turns.

Be specific and quote the text. If a section works, skip it.

Technique: separating critique from revision in different turns. Asked to do both at once, the model tends to produce a lightly reworded draft and call it an improvement.

#Planning and decisions

#A plan that names its own failure modes

Build a delivery plan for [project], to ship by [date], with [team].

Give me: phases with dependencies; the critical path; and for each
phase, the assumption that, if wrong, breaks the schedule.

Then, separately: the three most likely reasons this plan fails, and
the earliest observable signal for each. Be blunt about whether the
date is realistic given the constraints I gave you.

Technique: asking for early-warning signals rather than risks. A risk list is decoration; a signal is something you can put on a dashboard.

#Decision memo with a real recommendation

Write a one-page decision memo on [decision].

Structure: the decision to be made; three options; for each, cost,
what it commits us to, and what it forecloses; a recommendation with
the reasoning; and what evidence would change the recommendation.

Argue for one option. Do not hedge into "it depends".

Technique: a forcing function against fence-sitting, paired with a falsifier. The last line is what makes the memo usable a month later.

Model: Opus 5 with effort raised. This is the class of task where the extra reasoning is visible in the output.

#Automation and agents

Once Claude runs unattended, prompt quality stops being a matter of taste and becomes a matter of cost. These patterns are covered in depth on Claude automation and MCP and Claude agents.

#Brief a long agent run

Goal: [outcome, stated as a finished artifact, not an activity].

Done means: [the specific, checkable condition].
Never: modify production data; open a pull request; spend more than
[N] tool calls without reporting.
If blocked for the same reason twice, stop and report — do not retry
a third time.

Report format: what you did, what you changed, what you could not do,
and what you are unsure about.

Technique: a definition of done, hard prohibitions, and a loop-breaker. The two-strike rule is the single most useful line in an agent prompt — unattended agents burn budget by retrying the same failing approach.

Model: Fable 5, built for long-running agents with always-on adaptive thinking. It is also the slowest and most expensive current model at $10 / $50 per million tokens, with tighter rate limits than Opus 5 — use it where a failed run costs more than the tokens. Its refusals return HTTP 200 with stop_reason: "refusal", not an error, so handlers must expect that.

#Triage an inbound queue on a schedule

For each new item in the queue, decide one of:
  auto_reply | route_to_human | ignore

Rules: anything mentioning refunds, legal action, or a named
executive is always route_to_human. Anything you would route with
low confidence is route_to_human, not auto_reply.

Return JSON: {"action": "...", "reason": "...", "draft": "..."}
Leave "draft" empty unless action is auto_reply.

Technique: asymmetric defaults. When the cost of the two errors is unequal, say which way to fail.

#Which model for which job, and roughly what it costs

Costs below are arithmetic from Anthropic's published per-token rates — order-of-magnitude guides, not quotes. Thinking tokens bill as output, so reasoning-heavy runs cost more than the visible answer suggests.

#How to check a response before you rely on it

Four checks, roughly in order of how often they catch something. Verify a quote — search your source for one quoted sentence. Check the escape hatch fired: if you offered “none found” and it never appears across many runs, the model is filling gaps. Re-run once — a claim that changes between runs is one the model is not confident about. And check the arithmetic yourself; Claude is better at setting up a calculation than finishing one.

For the underlying techniques — role framing, few-shot examples, output contracts, chain prompting — see prompt engineering for Claude. To keep prompts and reference documents together instead of re-pasting them, use Projects in claude.ai.

#Frequently asked questions