Direct Answer
Claude Opus 5 responds best when a prompt gives it the complete job, a clear stopping point, calibrated output limits, and concrete acceptance criteria. It is more capable of planning and completing long tasks on its own, but it can also widen scope, write too much, spawn unnecessary subagents, and repeat verification work that it already performs internally.
Paul J Lipsky turns Anthropic's dense prompting guide into five approachable rules: give the full job up front; define where the task ends; control the response length; control the deliverable size; and remove generic "double-check everything" instructions. That is a strong beginner framework, with two qualifications: old Opus 4.8 prompts do not suddenly fail, and effort should be selected by testing the task, not merely by the subscription plan.
Watch the Walkthrough
Video credit: Paul J Lipsky. Paul translates the official guide into a non-technical website example using a fictional Northline Coffee brand. The reusable templates below are original JQ AI SYSTEMS adaptations rather than copies of Paul's complete prompt.
Source and Correction Note
The supplied transcript is the source for Paul's model-routing advice, five-rule framework, Northline Coffee prompt, and Claude Design demonstration. Anthropic's official Opus 5 prompting guide, effort guide, model overview, general prompting guidance, and platform release notes were checked on 28 July 2026.
Anthropic's wording is more measured than the video's opening. The company says Opus 5 performs well out of the box on existing Opus 4.8 prompts. The model does not require a completely new prompting language. The practical migration work is removing obsolete scaffolding and tuning the behaviors most likely to waste time: verbosity, scope expansion, excessive delegation, and repeated verification.
Effort also deserves a correction. Paul recommends low for Pro and medium for Max as simple defaults. Anthropic instead recommends starting at the default high effort, then running an effort sweep on representative tasks. Low and medium are often strong and cheaper, but the correct setting follows measured quality, latency, and cost, not the name of the subscription.
Useful Links
| Resource | What it covers | Use it for |
|---|---|---|
| Paul's full walkthrough | The five-rule explanation and one Claude Design build. | A fast, beginner-friendly introduction. |
| Paul J Lipsky on YouTube and official website | Creator credit, courses, and follow-up tutorials. | Check later tests and corrections as Claude changes. |
| Prompting Claude Opus 5 | Anthropic's model-specific guide for verbosity, scope, delegation, self-correction, and thinking-disabled artifacts. | The primary source for production prompt migration. |
| Effort guide | How effort changes thinking volume, latency, tokens, and model behavior. | Build a task-specific effort-routing policy. |
| Prompting best practices | General instructions, examples, formatting, tools, thinking, and migration patterns. | Combine durable prompting principles with Opus-specific tuning. |
| Claude model overview | Current model capabilities, context, output limits, and migration links. | Verify the model before hard-coding a workflow. |
| Claude Platform release notes | Launch details and API behavior changes. | Track changes that can invalidate old prompt assumptions. |
The Five Rules, Source-Checked
| Rule | Weak prompt pattern | Opus 5 pattern |
|---|---|---|
| 1. Give the full job | Feed isolated steps without explaining the final outcome. | State the complete result, context, assets, constraints, and destination up front. |
| 2. Define the stopping point | "Improve the website" with no scope boundary. | Name what is in scope, what must remain unchanged, when to ask, and where the task ends. |
| 3. Control the response | Assume lower effort will make the final explanation shorter. | Specify the completion format: one sentence, three bullets, or a short decision table. |
| 4. Control the deliverable | Limit the chat response but leave the report, deck, or website unbounded. | Set section count, word limit, reading time, page count, or screen count separately. |
| 5. Remove generic re-checks | "Double-check every file twice and ask a second agent to verify everything." | State measurable acceptance criteria and let the harness run the relevant tests once. |
Rule 1: Give the complete outcome up front
Anthropic says Opus 5 is strongest on difficult multi-file and end-to-end work when it receives the complete task specification and is left to run. This reduces the chance that the model optimizes an early subtask without understanding the final product.
Build a one-page product website for [brand].
Outcome:
Help [audience] understand [offer], choose [product], and complete [conversion].
Use:
- assets in [folder];
- the existing design tokens;
- product facts from [source].
Deliver:
A finished implementation in [destination], with the existing shop flow preserved.
"Complete" does not mean enormous. A simple task can still use a one-line prompt. The rule matters most when the model must coordinate several dependent steps.
Rule 2: Define scope and the end condition
Opus 5 can improve more than the user intended. Give it room for routine judgment while naming the boundaries that matter.
Scope:
- build only the homepage;
- preserve the current logo, colors, product names, routes, and checkout;
- do not add a CMS, authentication, new dependencies, or new products;
- make routine visual decisions yourself;
- ask one question only if different answers would materially change the outcome.
Stop when:
- the homepage is implemented;
- all existing tests pass;
- the specified viewport checks pass;
- no out-of-scope file has changed.
This is better than telling the model exactly how to perform every implementation step. Opus 5 can choose the route; the person defines the destination and guardrails.
Rule 3: Specify the completion response
Anthropic says effort controls thinking volume, not visible response length. If you want a concise answer, request one directly.
When finished, respond with:
1. the outcome in one sentence;
2. up to three bullets covering the main changes;
3. the verification result;
4. any blocker or decision still required.
Do not narrate routine steps or repeat the brief.
Rule 4: Limit the artifact separately
The answer can be concise while the file it creates is bloated. Calibrate the actual deliverable.
| Deliverable | Useful size constraint |
|---|---|
| Website | Six sections, one primary CTA, headline under nine words, body copy scannable in 90 seconds. |
| Report | Maximum 1,500 words, five sections, one executive summary, no repeated conclusion. |
| Slide deck | Ten slides, one message per slide, maximum three supporting points, source note on evidence slides. |
| Research brief | Two-page synthesis plus source table; distinguish confirmed, reported, inferred, and unknown. |
| Code change | Smallest implementation that meets the acceptance tests; no unrelated refactor or abstraction. |
Rule 5: Remove redundant verification prompts
Anthropic says Opus 5 self-corrects and verifies its own work without being told. Legacy instructions that demand another full verification pass or a verifier subagent can add latency and tokens without improving quality.
The wrong conclusion is "verification no longer matters." The correct conclusion is do not duplicate vague internal checking. Keep external evidence: tests, screenshots, source links, calculations, lint, review, and acceptance checks.
Choose Effort by Task, Not Plan
Anthropic documents five Opus 5 effort levels: low, medium, high, xhigh, and max. The official starting point is high, followed by an effort sweep on your own evaluations. Low and medium are important because they can retain strong quality with lower token use and latency.
| Effort | Good candidate | Decision rule |
|---|---|---|
| Low | Simple edits, extraction, first-pass review, routine transformations. | Use when repeatable evals show no meaningful quality loss. |
| Medium | Normal knowledge work, bounded builds, structured research, routine agent tasks. | A strong cost-aware candidate after testing against high. |
| High | New task baselines and work requiring substantial reasoning. | Anthropic's documented default starting point. |
| xhigh | Difficult coding, long agentic work, complex debugging, demanding planning. | Escalate only when accepted-result quality improves enough to justify the cost. |
| Max | Capability-critical work where quality matters more than latency and token spend. | Reserve for tasks that demonstrate a measurable benefit. |
Run the same representative prompt at high, medium, and low. Compare accepted result, corrections, latency, and tokens. Then route the task to the lowest effort that consistently clears the acceptance threshold.
The Anatomy of a Strong Opus 5 Prompt
- Outcome: the finished result and why it exists.
- Context: audience, current state, approved facts, assets, and existing system.
- Scope: what to change and what must remain untouched.
- Judgment: decisions the model can make without asking.
- Escalation: questions or consequences that require the person.
- Artifact limits: size, sections, pages, screens, duration, or complexity.
- Acceptance criteria: observable checks that establish completion.
- Completion response: the short summary needed for review.
This structure is more durable than phrases such as "think harder," "act as a genius," or "make it world-class." It gives the model operational information rather than emotional intensity.
Reusable Opus 5 Prompt Template
OUTCOME
Create [DELIVERABLE] that enables [AUDIENCE] to [RESULT].
The finished artifact must exist at [DESTINATION].
CONTEXT
- Current state: [WHAT ALREADY EXISTS]
- Source material: [FILES / LINKS / DATA]
- Approved style or examples: [REFERENCES]
- Important facts: [FACTS THAT MUST REMAIN ACCURATE]
SCOPE
Do:
- [REQUIRED WORK]
Do not:
- [OUT-OF-SCOPE WORK]
- change [PROTECTED ELEMENTS]
- add [UNWANTED DEPENDENCIES / FEATURES / SECTIONS]
JUDGMENT AND QUESTIONS
Make routine, reversible decisions yourself.
Ask only when different answers would materially change the result, cost,
permissions, or external impact.
ARTIFACT LIMITS
- [SECTION / PAGE / WORD / SCREEN / DURATION LIMIT]
- Keep the result no larger than necessary to achieve the outcome.
ACCEPTANCE CRITERIA
- [CHECK 1]
- [CHECK 2]
- [CHECK 3]
Run the relevant deterministic checks once. Do not add redundant verifier
agents or repeat the same verification unless a check fails.
COMPLETION RESPONSE
Lead with the outcome in one sentence.
Then provide no more than three bullets:
- what changed;
- verification result;
- blocker or decision still required.
Verification Without Token-Wasting Theater
| Keep | Remove or rewrite | Reason |
|---|---|---|
| Run the named test suite and report failures. | "Double-check all work carefully." | One is observable; the other invites an undefined extra pass. |
| Confirm all six requested sections exist. | "Review the design several times." | A count is measurable; repeated aesthetic review is unbounded. |
| Cite the source beside each consequential claim. | "Make sure every fact is true." | Traceability supports review; confidence language does not prove accuracy. |
| Check desktop and mobile for overflow. | "Use a second agent to check the first." | A deterministic viewport check is cheaper and stronger than role-playing. |
| Require human approval before publish, send, spend, or delete. | "Use your best judgment for everything." | Consequential boundaries belong to the operator. |
Control Subagents Explicitly
Paul focuses on the five most accessible rules, but Anthropic's guide adds an important sixth operational concern: Opus 5 delegates more readily than earlier models. Parallel work is useful only when tracks are genuinely independent and large enough to justify coordination.
Delegate only when the task contains independent, substantial workstreams that
can run in parallel.
Do not delegate:
- work that can be completed directly in a few tool calls;
- routine exploration;
- a second pass whose only purpose is to re-check your own work.
Use the fewest subagents needed. Keep each write scope separate and report the
result from every delegated task.
This keeps a simple website or report from becoming a costly agent swarm.
What Paul's Claude Design Test Proves
Paul gives Opus 5 a complete Northline Coffee homepage brief, attaches logos and product images, selects medium effort, and lets Claude Design build. The result arrives in under three minutes in his session, contains the six requested sections, uses the supplied assets, and returns the requested three-bullet summary.
That demonstrates strong instruction following in one configured environment. It does not establish that medium effort caused the speed, that the same prompt beats another prompting style, or that the design would outperform a baseline commercially. There is no repeated run, cost comparison, blinded review, accessibility audit, responsive test, or conversion data.
A Better Three-Run Evaluation
- Choose one real task. Use a deliverable you can judge, not a toy prompt designed to look impressive.
- Freeze the context. Use the same files, assets, tools, model version, and prompt for every run.
- Run high, medium, and low effort. Do not change the prompt between settings.
- Score before looking at cost. Grade completeness, correctness, scope control, taste, and acceptance checks.
- Record rework. Count human correction minutes, not just first-output quality.
- Calculate accepted-result cost. Include failed runs, delegated agents, retries, and review time.
- Choose the lowest stable setting. Escalate effort only for the task classes that need it.
Evaluation scorecard
- Outcome completeness: 0-5
- Factual or technical correctness: 0-5
- Scope discipline: 0-5
- Deliverable usefulness: 0-5
- Acceptance checks passed: yes/no
- Human rework minutes:
- Total latency:
- Total tokens or credits:
- Accepted for use: yes/no
Video Chapters
| Time | Chapter | Practical takeaway |
|---|---|---|
| 00:00 | Introduction | Paul frames the official guide as five changes for knowledge work. |
| 00:44 | Which model? | His simplified Sonnet, Opus, and Fable routing advice. |
| 02:36 | Effort level | Low and medium can be efficient, but should be validated against high. |
| 03:40 | Build the prompt | The fictional Northline Coffee website becomes the worked example. |
| 04:14 | Rule 1 | Give the complete job and final outcome at the start. |
| 05:21 | Rule 2 | Define scope, protected elements, question threshold, and stopping point. |
| 06:04 | Rules 3 and 4 | Limit the final response and the actual artifact separately. |
| 07:59 | Rule 5 | Remove vague repeated verification while keeping acceptance checks. |
| 09:18 | Claude Design test | One successful six-section website build and concise completion response. |
Bottom Line
The best Opus 5 prompts are not longer for the sake of being longer. They are complete where it matters: outcome, context, scope, artifact limits, acceptance criteria, and completion response.
Paul J Lipsky's five-rule translation is useful because it removes common ambiguity. Anthropic's documentation adds the production nuance: old prompts remain a valid starting point, effort needs evaluation, subagents need limits, and self-correction does not replace external evidence.
Give Opus 5 enough information to own the job, enough boundaries to stop at the right place, and enough objective checks to prove the result. Then use the lowest effort level that consistently passes. That is more reliable than piling motivational phrases and repeated verification rituals onto the prompt.