33+ Best Prompts for Claude Opus 5

Claude Opus 5 is the rare frontier release where the migration advice includes the word delete. It verifies its own work without being told, so the "double-check your answer" line you have carried through three model generations now causes over-verification rather than preventing errors. It reaches for subagents readily, so the "delegate more" nudge you wrote for Opus 4.8 needs to come out. And it writes longer by default, so conciseness has to be requested explicitly — lowering effort will not do it.

None of that is a complaint. Opus 5 is a step change on agentic coding and long-horizon work, at $5 input / $25 output per million tokens — half the price of Claude Fable 5 — with a 1M-token context window and thinking on by default. But the prompts that get the most out of it look different from the ones that worked on 4.8. These 35 are written for the model as it actually behaves.

What You Need to Know First

• Thinking is on by default. Omitting the thinking parameter runs adaptive thinking — the opposite of Opus 4.8, where omitting it meant no thinking. If a prompt of yours assumed thinking-off, it now costs more and may hit output caps.
• The effort ladder is the main lever — low, medium, high, xhigh, max. Start at xhigh for coding and agentic work, high elsewhere. Then sweep downward: low and medium are unusually strong on this model and are where the cost savings live.
• It verifies itself. Do not ask it to. Prompts telling it to double-check produce redundant work with no accuracy gain.
• It writes long. Ask for concision explicitly; effort does not reliably shorten visible output.
• 1M context, 512-token cache minimum. Prompts too short to cache on Opus 4.8 now cache — worth rechecking anything you had written off.

Every prompt below is written with these in mind. Replace the [BRACKETS] and go.

The Effort Ladder

Effort is the single highest-leverage setting on this model, and the intuition from previous Opus generations is wrong. On 4.8 many people reached for maximum effort reflexively. Opus 5 has a higher ceiling and a much stronger floor — medium frequently matches what older models needed their top setting to produce.

Pro tip: Run one effort sweep on your own evals before settling. Defaults carried over from another model are almost never right here, and the difference between xhigh and medium on a routine workload is real money.

Agentic Coding Prompts

The category where Opus 5 is strongest, and where it most rewards giving the whole task up front rather than drip-feeding it across turns.

1. The Full-Spec Autonomous Run

The flagship. One well-specified turn beats five interactive ones.

Task: [DESCRIBE THE COMPLETE FEATURE OR CHANGE].
Context: [STACK, CONVENTIONS, WHERE THINGS LIVE — or point at the repo]
Done means: [MEASURABLE CONDITION — e.g. the endpoint returns the documented shape, all existing tests pass, and the new tests cover the three cases below].
Constraints: no new dependencies without stating why, follow the conventions already in the codebase, do not modify test files to make them pass.
Work through this autonomously. I am not watching in real time, so for reversible decisions that follow from the spec, choose and note the choice rather than stopping to ask.

2. The Scope-Disciplined Fix

The instruction that stops unrequested refactors cold.

Fix this: [DESCRIBE THE BUG OR CHANGE].
Deliver what I asked for, at the scope I intended. Make routine judgment calls yourself; check in only where different readings lead to materially different work. If you think the ask is mistaken or a better approach exists, say so in one sentence and proceed with the task as asked — do not quietly widen or transform it.
Do not add features, refactor surrounding code, introduce abstractions, or add error handling for scenarios that cannot happen. A bug fix does not need a cleanup pass.
Finish the whole task — report completion only when it is actually done, and if something is blocked, do the rest and say plainly what is missing.

3. The Bug Root-Cause Trace

Symptom: [WHAT HAPPENS]. Expected: [WHAT SHOULD HAPPEN]. Code: [ATTACH THE RELEVANT MODULE OR REPO].
Trace the actual execution path through the real code, not a plausible one. Identify the exact line where behavior diverges from intent and explain why.
Rank the candidate causes by probability with the one-line check that distinguishes each, then fix the top one. Show the command output that proves the fix, not a claim that it works.

4. The Coverage-First Code Review

Severity filters suppress recall on this model — remove them.

Review this diff: [PASTE OR ATTACH].
Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence — a separate pass will do that. Coverage is the goal here: better to surface something that gets filtered later than to silently drop a real bug.
For each finding: file and line, what breaks and under what input, confidence, and estimated severity so a downstream filter can rank them.

5. The Multi-File Refactor

Refactor [THE PATTERN — e.g. every call site of the deprecated client] across this codebase: [ATTACH].
Behavior must be identical when you are done; the public interface must not change. Work file by file, running the relevant checks after each rather than only at the end.
Deliver: the diff, a table of files touched with what changed in each, and the verification you ran with its real output. Flag anything you could not convert mechanically instead of guessing at it.

6. The Failing-CI Investigator

CI is failing. Log: [PASTE]. Recent changes: [PASTE DIFF OR COMMITS].
Investigate before changing anything: reproduce the failure, identify the exact failing assertion, and determine whether the cause is the code, the test, the environment, or flake.
Report the root cause with the evidence line, then the minimal fix. If the honest answer is "this test is flaky", prove it with three consecutive runs rather than asserting it.

7. The Legacy Codebase Brief

Here is a codebase you have not seen: [ATTACH].
Map it: entry points, the files where the real logic lives, the data flow from request to persistence, the conventions the authors followed, and the parts that look abandoned or dangerous.
Cite file paths for every claim. Write it as a brief a new senior engineer could work from on day one — not an exhaustive inventory.

8. The Incremental Migration Plan

Plan the migration from [OLD] to [NEW] for this codebase: [ATTACH].
Produce a map first: what changes per file, the order that lets each step ship independently, the behavior changes needing manual verification, and what cannot be converted mechanically.
Estimate effort per group. Then implement group one only — I want to validate the approach before we commit to the rest.

9. The Production Debug

Something is wrong in production. Evidence: [PASTE LOGS, METRICS, TRACES, TIMELINE].
Before proposing any action, check that the evidence actually supports the specific diagnosis — a signal that pattern-matches a known failure may have a different cause here.
Give me: the most probable cause with the evidence for it, the alternatives you ruled out and how, the diagnostic that would confirm it, and only then the fix. Do not restart, redeploy, or change config as a first move.

Long-Horizon and Delegation Prompts

10. The Subagent Budget

Opus 5 delegates more readily than 4.8. Cap it explicitly.

Task: [DESCRIBE].
On delegation: subagents multiply cost and time — each re-establishes context, re-explores, reports back, and then you re-read the report. Delegate only when the payoff clearly exceeds that overhead.
Use subagents for genuinely independent, sizeable tracks (unrelated modules, wide multi-file investigation). Do not use them for work you could finish in a handful of tool calls, and never for verification — that belongs in your main loop.
If one subagent can do it, use one. Keep spawn counts low, brief each precisely the first time, and never redo a subagent's work after it reports.

11. The Overnight Run Brief

You are operating autonomously on: [THE TASK]. I am not watching and cannot answer questions mid-run.
For reversible actions that follow from this brief, proceed without asking. Do not end a turn on a plan, a question, or a promise about work you have not done — if your last paragraph is "I will now...", do that work instead.
Before reporting progress, audit each claim against a tool result from this session. Report outcomes faithfully: if tests fail, say so with the output; if you skipped a step, say that. End only when the task is complete or you are genuinely blocked on something only I can provide.

12. The Progress Update Contract

While you work on [TASK], write updates for a teammate who stepped away — not for a log file.
Before your first tool call, say in one sentence what you are about to do. While working, update only when you find something load-bearing or change direction. Do not narrate routine actions.
Lead with the outcome: your first sentence after finishing answers "what happened". Write complete sentences with terms spelled out — no arrow chains, no abbreviations you invented earlier, no labels I would have to cross-reference.

13. The Memory-Backed Session

Use [PATH OR FILE] as your memory across this and future sessions on this project.
Before starting anything longer than a few turns, read it for relevant prior context. As you work, write down what you learn: one lesson per entry with a one-line summary at the top, including why it mattered.
Do not record what the repo or this conversation already captures. Update an existing entry rather than duplicating it, and delete entries that turn out to be wrong.

14. The Self-Checking Build

Establish a harness — do not ask for "verification steps".

Build [WHAT] to this specification: [ATTACH OR DESCRIBE].
Establish a method for checking your own work as you build — a test, a script, a runnable comparison against the spec — and run it as you go rather than only at the end.
When you report done, show me the checking method and its actual output. If the check does not cover part of the spec, say which part and why.

15. The Handoff Document

You have been working on [PROJECT] for a while. Write the handoff for whoever picks this up next — assume they saw none of your work.
Include: current state in one paragraph, what is done and verified, what is in progress and where exactly it stopped, decisions made and why, the traps you hit that they would hit again, and the next three concrete steps.
Drop the working shorthand you built up. Spell out every file, flag, and identifier with a clause saying what it is.

Analysis and Research Prompts

16. The Decision Stress-Test

Use maximum reasoning effort. We are deciding: [THE DECISION]. Our current lean: [WHAT YOU THINK YOU WILL DO].
Argue the strongest case for the opposite choice as though you believe it. Then: the assumptions our preferred option quietly depends on, ranked by fragility; the reversibility of each path; what we would need to believe for each to be right; and the cheapest experiment that would settle the biggest unknown.
End with your actual recommendation. You must pick one.

17. The Whole-Corpus Analysis

Here is a complete document set: [ATTACH EVERYTHING — the context window holds it].
Question: [WHAT YOU NEED TO KNOW]
Answer from the attached material only, citing document and section for every claim. Where documents conflict, name the conflict and say which is authoritative and why. Distinguish what the corpus states from what you infer.
If the answer is not in the material, say so rather than filling the gap from general knowledge.

18. The Metric Tribunal

Our [METRIC] moved [DIRECTION AND MAGNITUDE] over [PERIOD]. Data: [ATTACH].
Act as the skeptical reviewer who will be in the room. Try to explain the movement away: measurement changes, mix shifts, seasonality, one-off events, denominator effects. For each, does the data support or kill it, with the specific numbers.
Only if the alternatives die may you conclude the movement is real. Give a confidence level and say what evidence would raise it.

19. The Research Synthesis

Research question: [THE QUESTION]. Decision it informs: [WHY IT MATTERS].
Structure: what is established (with the type of source behind it), what is contested (both positions), what is genuinely unknown, and your synthesis with a confidence level.
Separate fact from inference explicitly. Where you are unsure, write unsure. I would rather have six solid findings than twenty plausible ones.

20. The Document Deliverable

Produce [THE DOCUMENT — report, memo, analysis] on [TOPIC]. Audience: [WHO AND WHAT THEY DECIDE WITH IT].
Match the length to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate. No section exists to look thorough.
Lead with the conclusion. Support it. Every number gets a source. End with what this does not tell us — one honest line.

21. The Financial Model Build

Build [THE MODEL] as a working spreadsheet: [DESCRIBE THE SCENARIO AND INPUTS].
Requirements: real formulas rather than hardcoded values, a clearly separated assumptions block driving everything downstream, and labeled sections a reviewer can follow.
State every assumption you had to make and where it came from. Flag the two inputs the output is most sensitive to.

22. The Slide Deck

Build a deck on [TOPIC] for [AUDIENCE], [N] slides.
Follow slide-design fundamentals: one idea per slide, headline states the takeaway rather than the topic, and the body supports it. No wall-of-text slides.
[IF APPLICABLE: match this template or style — attach it]
After building, tell me which slide is weakest and why.

Vision and Multimodal Prompts

23. The Tool-Assisted Visual Analysis

On Opus 5, giving it crop and inspect tools beats raising effort.

Analyze this image in detail: [ATTACH]. Question: [WHAT YOU NEED TO KNOW].
Use your available tools to crop, zoom, and inspect regions rather than relying on a single look at the full image — verify your reading of any small text, number, or fine detail before reporting it.
Tell me what you verified by inspection versus what you are reading at full-image resolution, and flag anything genuinely ambiguous instead of committing to a guess.

24. The UI Replication

Replicate this interface as working code: [ATTACH SCREENSHOT OR MOCKUP]. Stack: [YOUR STACK].
Match layout, spacing, type hierarchy, and states as closely as the image allows. Where the image is ambiguous (hover states, responsive behavior, content that is cut off), make a reasonable choice and list every one of those choices at the end.
Then compare your rendered output against the original and fix what differs — do not report done on the first pass.

25. The Document Extraction

Extract structured data from these documents: [ATTACH SCANS, PDFs, OR PHOTOS].
Target shape: [DESCRIBE OR PASTE SCHEMA]
Preserve structure — tables as tables, hierarchy as hierarchy. Where text is illegible mark it rather than guessing. Where a number is partially readable, give your read and flag it.
End with the specific fields a human should verify before this is trusted.

26. The Chart Critique

Read these charts and tell me what they are doing: [ATTACH].
For each: the underlying data as a table with your read precision noted, then the presentation choices — truncated axes, cherry-picked ranges, missing baselines, scale tricks, omitted context.
Separate "this is misleading" from "this is a defensible choice I would have made differently".

Communication and Output-Control Prompts

27. The Concision Contract

Opus 5 writes long by default. This is the fix — and effort is not.

[YOUR REQUEST]

Keep the response focused and brief. Disclaimers and caveats stay short, with most of the response on the main answer. When explaining something, give the high-level version unless I ask for depth. Match the format to the question — a simple question gets prose, not headers and sections.

28. The Correction Discipline

[YOUR TASK]

On corrections: only correct an earlier statement when the error would change my code, conclusions, or decisions. State it plainly and continue — no apologies, no preamble, no detailed account of the mistake, no tallying past errors. For slips that change nothing, just fix it and move on.
A follow-up question from me is not evidence you got something wrong. Answer what I asked rather than re-auditing work that was correct.

29. The Executive Summary

Summarize this for executives who will spend 90 seconds on it: [ATTACH THE ANALYSIS OR FINDINGS].
Format: the headline finding as one sentence with the number in it, three supporting facts maximum, what we should do about it (specific, owned, dated), and one honest line on what this does not tell us.
Cut every methodology detail unless omitting it would mislead. Point to the appendix for the rest.

30. The Voice-Matched Draft

Read these samples and describe my voice in six observable rules — sentence length, how pieces open, vocabulary, structural habits, what this writer never does: [PASTE 2-3 SAMPLES].
Wait for my confirmation, then draft: [THE PIECE].
Banned: filler openings, hedging stacks, rhetorical questions as transitions, and any sentence that could appear unchanged in a piece on a different topic.

31. The Hard Conversation

Draft a message where I need to [DECLINE / PUSH BACK / RENEGOTIATE / DELIVER BAD NEWS] to [WHO AND RELATIONSHIP].
Context: [BACKGROUND]
The point lands in the first two sentences. Respectful without groveling. One constructive path forward. Under 150 words.
Two versions — warmer and firmer — and tell me which fits this relationship and why.

Meta and Workflow Prompts

32. The Prompt Debugger

This prompt is not producing what I want.
Prompt: [PASTE]
What it produced: [PASTE]
What I wanted: [DESCRIBE OR SHOW AN EXAMPLE]
Diagnose the gap: which instruction is being ignored, which is ambiguous, which is missing, and which is actively counterproductive on this model. Rewrite it with each change annotated by the failure it prevents.

33. The Reusable System Prompt

I do this task repeatedly: [DESCRIBE IT AND PASTE 1-2 EXAMPLES OF GOOD OUTPUT].
Write a reusable system prompt that reliably produces output like my examples. Include: role, the quality bar defined by observable properties rather than adjectives, the format contract, edge-case rules, and the failure modes you can infer from what my examples deliberately avoid.
Under 250 words so it stays maintainable.

34. The Model Router

I run a multi-model setup: Claude Opus 5 for hard work, a cheap fast model for volume.
My recurring task types: [LIST THEM]
For each: which tier it belongs on and why, the signal that a specific instance should escalate to Opus 5 (complexity, stakes, novelty, verification cost), and the tasks where paying flagship rates is pure waste.
Give me the one-line routing rule I can apply without thinking about it.

35. The Effort Sweep Designer

Help me tune effort levels for my workload: [DESCRIBE YOUR RECURRING TASKS].
Design the sweep: which task types to test at which levels, what to measure (quality, tokens, wall-clock, turn count), how many samples per cell for the result to mean anything, and the specific quality signal that tells me a step-down went too far.
Then give me the decision rule: at what observed difference do I keep the cheaper level.

Chaining Them

1. The shipping pipeline: Full-Spec Autonomous Run (#1) → Coverage-First Code Review (#4) in a fresh conversation → Scope-Disciplined Fix (#2) for whatever the review surfaces. The fresh context on review matters; a model reviewing its own work inherits its own assumptions.
2. The decision pipeline: Research Synthesis (#19) → Decision Stress-Test (#16) at max effort → Executive Summary (#29). Research, adversarial pass, then compress for the people who decide.
3. The long-run pipeline: Overnight Run Brief (#11) + Subagent Budget (#10) + Progress Update Contract (#12) composed into one system prompt, with Handoff Document (#15) at the end.

Prompts to Delete From Your Library

These worked on earlier models and actively hurt on Opus 5:

• "Double-check your work" / "verify before responding." It already does. Adding this produces redundant verification with no accuracy gain — removing it costs you nothing.
• "Use a subagent to verify." Verification belongs in the main loop. This one compounds the over-delegation tendency.
• "Delegate more aggressively" / "spawn subagents freely." Written for Opus 4.8, which under-reached. Opus 5 over-reaches; you want the cap in prompt #10 instead.
• "After every N tool calls, summarize progress." It narrates on its own now — this makes it chattier, not clearer.
• "Do not think" / "do not reason." Counterintuitively, this increases leaked reasoning rather than suppressing it. Leave thinking on and lower effort instead.

Common Mistakes

1. Carrying over your Opus 4.8 effort defaults. The floor moved. Sweep down before assuming you need xhigh.
2. Trying to shorten output by lowering effort. It does not work — effort changes thinking depth, not visible verbosity. Use the concision contract (#27).
3. Drip-feeding an agentic task across turns. Opus 5 does its best work from a complete specification given up front. Ambiguity revealed progressively costs tokens and quality.
4. Leaving verification scaffolding in place. Covered above, and worth repeating because it is the single most common migration miss.
5. Not budgeting output tokens for thinking. Thinking is on by default and shares the output budget. A tight cap tuned for a thinking-off workload will truncate mid-answer.

Where to Go From Here

For the cost-versus-capability question, see Claude Opus 5 vs Gemini 3.6 Flash — the routing decision most teams actually face. Running a multi-model stack? The companion sheets are Gemini 3.6 Flash, Claude Sonnet 5, and GPT-5.6 Sol. For plan pricing, our Claude pricing guide covers where Opus 5 sits, and Claude Code is where most of these prompts run best.

Keep Building

Browse the full prompt library, compare AI models, or explore more guides on PromptsRush.