Anthropic Just Revealed How to Prompt Opus 5 ![rw-book-cover](https://i.ytimg.com/vi/Z8CtXdQExek/sddefault.jpg) 🔗 **Source:** [Anthropic Just Revealed How to Prompt Opus 5](https://www.youtube.com/watch?v=Z8CtXdQExek) > [!note]+ Document Notes > tags: [prompt-engineering, opus-5, model-selection, effort-levels, scope-control, ai-workflow] > author: Paul J Lipsky > source: YouTube > reference: https://www.youtube.com/watch?v=Z8CtXdQExek > date created: 2026-07-27 10:20 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Anthropic Just Revealed How to Prompt Opus 5 > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [The video](https://www.youtube.com/watch?v=Z8CtXdQExek) - [Anthropic's Opus 5 prompting guide](https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview) — the source document being summarized - [Claude plans and pricing](https://claude.com/pricing) — context for the model/plan recommendations ## 📝 Summary - **What happened.** A summary-and-demo video walking through Anthropic's published prompting guidance for Claude Opus 5, distilled into five rules, plus recommendations on model choice and effort level. The presenter builds a single prompt incrementally for a fictional coffee brand's one-page website, then runs it in Claude's design tool and checks the output against the constraints. - **Why it matters.** Two of the five rules invert advice that has been standard for years. The most consequential: **stop telling the model to double-check its work.** Anthropic's guidance is that Opus 5 already verifies as it goes, so a redundant verification pass costs time and tokens without improving the result. If accurate, that removes a step most people have baked into their prompt templates. - **Key stakeholders.** Anyone with prompt templates written for earlier models; people choosing between plan tiers and effort levels; teams standardizing prompting practice; and Anthropic, whose guidance this relays. - **Risks and tradeoffs.** The whole video is downstream of a vendor's claims about its own product, and the verification test is a single successful run with no comparison arm. The presenter is careful to attribute claims to Anthropic rather than asserting them independently, which is the right posture, but "it worked once" is the entire evidentiary base for "these rules work." - **Bottom line.** The scope-control rules (define where the job ends, bound the output size, bound the response length) are sound prompt hygiene that would help with any model. The drop-the-verification-pass rule is the genuinely new and testable claim, and the one worth verifying against your own workload before you rewrite your templates. ## 📖 Main Content **The framing.** The premise is that Opus 5 is the strongest Opus model released, sometimes beating a more expensive sibling on benchmarks, but that prompting it the way you prompted previous Claude models will produce poor results — and that Anthropic agrees, which is why they published a guide. The presenter's stated service is having read the dense guide so the viewer doesn't have to, extracting five rules for knowledge work. That framing is honest about its own nature: this is a secondary source relaying a primary one, and the presenter says so. **Model selection.** With four models available, the recommendation is use-case and plan dependent: - Haiku: the presenter never uses it. Maybe acceptable for general chat questions; not recommended for work. - On the $20 plan: Sonnet as default, switching to Opus 5 for complex tasks or when Sonnet's results disappoint. - On the $100 Max plan or higher doing knowledge work: Opus 5 as the default. - The most expensive model: previously recommended for complex work, now recommended less. Reach for it only when unhappy with Opus 5's results and wanting a comparison. The presenter explicitly acknowledges that switching models per task would be more optimized, and chooses simplicity instead — leaving it on Opus 5 nearly always. That's a defensible tradeoff, stated as a tradeoff. **Effort level, and the misconception.** This is the more useful half of the setup. The presenter predicts a common mistake: assuming higher effort means better results. Anthropic's framing is different — the effort setting mainly controls how much thinking the model does, affecting time and tokens spent. That can produce better answers, but a lot of the time it's overkill. The relayed claim is that low and medium effort are "surprisingly strong" on Opus 5, with the recommendation to start there for normal knowledge work: low on Pro, medium as default on Max plans. The presenter's own default is Opus 5 on medium. The distinction between *more thinking* and *better output* is the substantive point, and it's underappreciated — effort is a cost dial that sometimes buys quality, not a quality dial. **The five rules, built into one prompt.** The demo scenario: Northline Coffee, a small brand selling beans online, with existing logos, colors, and product images, wanting a website that sells more coffee. **Rule one — give the full job at the start.** Older models rewarded decomposition: look at these files, then build a brand guide, then plan the site. Opus 5 is described as better at taking a whole job and working through it independently. The resulting opening states the deliverable, the audience goal, the asset location, and the output location in one instruction. **Rule two — say where the job ends, and set limits.** The stated failure mode: Opus 5 "loves to do more work than you ask it to do," which can be helpful but often overshoots. The added constraints scope the build to the home page, point buy buttons at an existing shop page, preserve brand elements, delegate small design decisions to the model, and — the sharpest line — instruct it to ask a question only if the answer would change the whole website. That last clause converts "ask clarifying questions" from an open invitation into a threshold test. **Rule three — bound the response length.** Another named Opus 5 behavior: long completion summaries, often too long to read. The fix is explicit — say where the site is, give no more than three short bullets, then note only what's truly important about how it works. **Rule three-and-a-half — bound the work product, which is a different thing.** The presenter draws a distinction worth keeping: constraining the *response* doesn't constrain the *artifact*. So the prompt also specifies six named sections, a headline of eight words or fewer, and no more than 70 words per section. He immediately adds that this precision is optional — you could say "six parts" and let the model choose, or specify a reading time ("under a minute and a half") and let it infer length. The point is to give *some* size guidance. **Rule four (framed as what not to do) — stop telling it to verify.** The rule that reverses standard practice. For years the advice has been to tell the model to check every file twice, find every mistake, and fix them, and this usually improved results. Anthropic's stated position is that Opus 5 already checks and fixes its work as it goes, so forcing a second full pass costs time and tokens without improving the outcome. The nuance preserved: still tell the model what good looks like, just don't make it repeat the same check. **The demo and what it shows.** The prompt goes into Claude's design tool with Opus 5 selected at medium effort and the brand assets attached. It completes in a little under three minutes, which the presenter calls fast for that tool, and attributes the speed to prompt precision — the model didn't need to ask follow-ups because the answers were already supplied. He then verifies against the constraints: counts six sections and matches them to the six requested; confirms the chat response contains exactly three bullets rather than a wall of text. That verification is real but narrow. It confirms the model *followed instructions about structure and response length* — which is genuinely useful evidence for rules two and three. It does not test rule four at all, because there's no arm of the experiment where the verification instruction was included for comparison. The single strongest claim in the video is the one the demo doesn't touch. **Contested and uncertain.** Everything rests on Anthropic's characterization of its own model. No independent testing, no comparison conditions, no failure cases shown. The claim that low and medium effort are "surprisingly strong" is relayed, not verified. And the demo is one run of one task with no baseline. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=Z8CtXdQExek&t=0) Premise and honest framing - Opus 5 described as the best Opus yet, sometimes beating a more expensive sibling on benchmarks. - Core claim: prompting it like previous Claude models produces poor results, and Anthropic agrees — hence a published guide. - Presenter's role stated plainly: read the dense guide, extract five rules for knowledge work. Secondary source relaying a primary one. - Flags that some rules are "the exact opposite of the advice we've been following for years." #### ⏱️ [00:00:47](https://www.youtube.com/watch?v=Z8CtXdQExek&t=47) Model selection by plan - Four models now available; choice depends on use case and plan. - Haiku: presenter never uses it; maybe for general chat, not for work. - $20 plan: Sonnet default, Opus 5 for complex tasks or when Sonnet disappoints. - $100 Max plan and above, knowledge work: Opus 5 as default. #### ⏱️ [00:01:35](https://www.youtube.com/watch?v=Z8CtXdQExek&t=95) When to reach past Opus 5 - Previously recommended switching to the most expensive model for complex work; now recommends that less. - Use it only when unhappy with Opus 5's output and wanting a comparison. - Explicitly acknowledges per-task model switching would be more optimized; chooses simplicity instead and leaves it on Opus 5. A stated tradeoff, not an oversight. #### ⏱️ [00:02:23](https://www.youtube.com/watch?v=Z8CtXdQExek&t=143) Effort level — the misconception - Predicts the common error: assuming higher effort means better results. - Anthropic's framing relayed: effort mainly controls how much thinking happens, affecting time and tokens. - **The substantive distinction:** more thinking sometimes produces better answers, but "a lot of the time, it's just overkill." Effort is a cost dial that sometimes buys quality. #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=Z8CtXdQExek&t=192) Effort recommendations - Relayed claim: low and medium are "surprisingly strong" on Opus 5. - Start there for normal knowledge work — low on Pro, medium as default on Max plans. - Presenter's own standing default: Opus 5 on medium. #### ⏱️ [00:03:30](https://www.youtube.com/watch?v=Z8CtXdQExek&t=210) The demo scenario - Northline Coffee: small brand selling beans online, existing logos, colors, product images. - Goal stated as commercial — the site should sell more coffee. - Prompt built incrementally across the five rules rather than presented finished. #### ⏱️ [00:04:00](https://www.youtube.com/watch?v=Z8CtXdQExek&t=240) Rule 1 — give the full job at the start - Older models rewarded decomposition into sequential steps; Opus 5 is better at taking a whole job and working through it. - Resulting opening supplies deliverable, audience goal, asset location, and output location together. - Rationale: "it gives the whole job up front, where we are starting and where we need to end up." #### ⏱️ [00:04:48](https://www.youtube.com/watch?v=Z8CtXdQExek&t=288) Rule 2 — say where the job ends - Named behavior: Opus 5 "loves to do more work than you ask it to do" — sometimes helpful, often overshooting. - Constraints added: home page only, link buy buttons to the existing shop page, keep current logo/colors/product names, make small design choices yourself. - **Sharpest clause:** "Only ask me a question if the answer would change the whole website." Converts clarifying questions from open invitation to threshold test. #### ⏱️ [00:05:37](https://www.youtube.com/watch?v=Z8CtXdQExek&t=337) Rule 3 — bound the response length - Named behavior: long completion summaries, "so long I don't even bother reading it." - Fix: say where the site is, no more than three short bullets on what was made, then only what's truly important about how it works. - Goal is a readable response containing only needed information. #### ⏱️ [00:06:25](https://www.youtube.com/watch?v=Z8CtXdQExek&t=385) Bounding the work product — a separate control - **Distinction worth keeping:** constraining the response does not constrain the artifact. Short reply, oversized website. - Specifies six named sections, headline of eight words or fewer, no more than 70 words per section. - Immediately softens: this precision is optional. "I only want six parts" works, or specify reading time ("under a minute and a half") and let it infer. The point is giving *some* size guidance. #### ⏱️ [00:08:00](https://www.youtube.com/watch?v=Z8CtXdQExek&t=480) Rule 4 — stop telling it to verify - The reversal. Standard advice for years: check every file twice, find every mistake, fix them all — and it usually helped. - Anthropic's relayed position: Opus 5 already checks and fixes its work as it goes. - Forcing a full re-check "may take more time and use more tokens without actually making the end result any better." - **Nuance preserved:** still tell it what good looks like; just don't make it repeat the same check. #### ⏱️ [00:08:49](https://www.youtube.com/watch?v=Z8CtXdQExek&t=529) Portability and setup - Rules apply anywhere Opus 5 is accessible — web chat, co-work, phone, desktop app, design tool. - Demo runs in Claude's design tool with Opus 5 selected, effort left on medium, brand assets attached. #### ⏱️ [00:09:38](https://www.youtube.com/watch?v=Z8CtXdQExek&t=578) The run - Usually the design tool asks follow-up questions; this time it didn't, which the presenter attributes to sufficient information in the prompt. - Completed in a little under three minutes — called fast for that tool. - Attribution: "because we were so precise with our prompt... it knew what we were going for right from the start." #### ⏱️ [00:10:25](https://www.youtube.com/watch?v=Z8CtXdQExek&t=625) Verification against constraints - Counts sections: six, matching the six requested — hero, products, brand info, reviews, FAQ, call to action. - Checks the chat response: three bullets as specified, not a wall of text. - **What this tests:** instruction-following on structure and response length (rules 2 and 3). **What it doesn't test:** rule 4, since there's no comparison arm with the verification instruction included. #### ⏱️ [00:11:14](https://www.youtube.com/watch?v=Z8CtXdQExek&t=674) Closing framing - Summary: choose Opus 5, match effort to task and plan, follow the five rules. - The compressed principle: "let Opus 5 use its intelligence without letting it overuse its intelligence." - Notes the model is only half the story; tool fluency is the other half. Points to a companion video. ## 📚 References - [The video — Paul J Lipsky](https://www.youtube.com/watch?v=Z8CtXdQExek) - [Anthropic prompt engineering documentation](https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview) — the primary source - [Claude pricing and plans](https://claude.com/pricing) — context for the plan-tiered recommendations - [Anthropic model overview](https://docs.claude.com/en/docs/about-claude/models) — for independent comparison of the model tiers discussed ## 🗣️ Paraphrase - Opus 5 is presented as the strongest Opus release, occasionally outperforming a costlier sibling, but requiring different prompting than earlier Claude models — a position the presenter attributes to Anthropic's own published guide. - The presenter's stated contribution is having read that dense guide and extracted five rules relevant to knowledge work, several of which reverse long-standing advice. - Model choice depends on plan and task: the smallest model is dismissed for real work, Sonnet serves as the default on the entry paid plan, and Opus 5 becomes the default on higher plans. - The most expensive model is now recommended less often, reserved for cases where Opus 5's output disappoints and a comparison is wanted. - Rather than optimizing model choice per task, the presenter deliberately keeps a single default for simplicity. - On effort level, he anticipates the mistake of assuming more effort yields better output, relaying Anthropic's framing that effort governs thinking time and token spend, which sometimes but not always improves results. - Low and medium effort are described as surprisingly capable on Opus 5, with low suggested for the entry plan and medium as a default on higher plans. - The first rule is to state the entire job at the outset rather than decomposing it into sequential steps, since Opus 5 handles whole tasks independently. - The second rule addresses the model's tendency to exceed the brief: state where the job ends, set explicit limits, and permit clarifying questions only when the answer would change the whole project. - The third rule targets overlong completion summaries by specifying exactly what the response should contain and how briefly. - A related but distinct control governs the size of the artifact itself, since a short response can accompany an oversized deliverable — here specified as six sections with word limits, though the presenter notes looser guidance also works. - The fourth rule is a subtraction: stop instructing the model to double-check its work, because Anthropic says Opus 5 verifies as it goes and a forced second pass spends time and tokens without improving output. - The rules apply across every surface where Opus 5 is available, and the demo runs in Claude's design tool at medium effort with brand assets attached. - The build finished in under three minutes without follow-up questions, which the presenter credits to prompt precision. - Verification confirms six sections matching the six requested and a three-bullet response matching the instruction, demonstrating adherence to the structural and response-length rules. - The closing principle is to let the model use its intelligence without overusing it, and the presenter notes that tool fluency matters as much as model choice. ## 📰 Newsletter **Stop telling Claude to double-check its work. Seriously.** That's the one genuinely surprising item in this walkthrough of Anthropic's Opus 5 prompting guidance, and it reverses advice most of us have had baked into our prompt templates for years. The standard move has been: *after you're done, check every file twice, find every possible mistake, and fix them all.* It used to help. Anthropic's position now is that Opus 5 already checks and fixes as it goes, so forcing a redundant pass burns time and tokens without improving the result. You should still tell it what good looks like — you just shouldn't make it run the same check twice. If that's right, a lot of people are paying for a verification step they're getting anyway. **The rest is scope discipline,** and it's good prompt hygiene regardless of model: - **Give the whole job up front.** Older models rewarded breaking work into steps. Opus 5 does better with the full brief — where you're starting, where you need to end up, where the assets live, where the output goes. - **Say where the job ends.** The model "loves to do more work than you ask it to." The best line in the video is a constraint on questions: *only ask me a question if the answer would change the whole website.* That turns "ask if you're unsure" from an open invitation into a threshold test, which is a trick worth stealing for any agent. - **Bound the response** so you don't get a wall of text you won't read. Three bullets, then only what matters. - **And separately, bound the artifact** — because a short reply can still ship an enormous website. Those are two different controls and conflating them is why people get one and not the other. **On effort levels**, the useful correction: effort isn't a quality dial, it's a *thinking-time and token* dial that sometimes buys quality. Low and medium are described as surprisingly strong on Opus 5. Starting high by default is just paying more for the same answer much of the time. **Where I'd hold back.** This is a summary of a vendor's claims about its own model, which the presenter is upfront about — he consistently says "Anthropic says" rather than asserting it himself, and that's the right posture. But the demo tests one prompt, once, with no comparison. It genuinely shows the model followed the structural constraints — six sections requested, six delivered; three bullets requested, three delivered. It shows nothing at all about the verification rule, because there's no run *with* the verification instruction to compare against. So: adopt the scope rules now, they cost nothing and they're sound. Test the drop-the-verification rule on your own work before you strip it out of every template you own. That's the claim with real money attached, and it's the one nobody has independently checked. ## ✅ Action Items #### DevRel - Developer advocacy: the "only ask if the answer would change the whole project" pattern is the most portable idea here — a threshold test for clarifying questions that works with any agent. Worth teaching directly. - Education: build a short module on the response/artifact distinction, which is routinely conflated and produces exactly the "short summary, sprawling output" failure people complain about. - Developer experience: audit SDK example prompts for redundant verification instructions written against older models. - Developer marketing: none applicable to this source. - Community management: none applicable to this source. - Internal/external/cross-project: adopt "effort is a cost dial" as shared framing when discussing model configuration, to stop teams defaulting to maximum. #### OSPO - Policy & Governance: none applicable to this source. - License Compliance: none applicable to this source. - Security Management: none applicable to this source. - Software Inventory: none applicable to this source. - Developer Support: publish internal guidance on model and effort defaults so people aren't guessing per task — the video's simplicity argument (one default, override when unhappy) is a reasonable organizational policy. - Community Engagement: none applicable to this source. - Strategic Alignment: if effort level materially affects token spend, it belongs in cost reporting rather than being left to individual discretion. #### Community - Maintainers: none applicable to this source. - Contributors: none applicable to this source. - Sponsors: none applicable to this source. - Ecosystem: none applicable to this source. #### WordPress - Core: none applicable to this source. - Core Performance: none applicable to this source. - Core AI: relevant to guidance on prompting practice — specifically that verification instructions written for earlier models may now be redundant cost. - **Core Program Team:** none applicable to this source. - Mobile: none applicable to this source. - Playground: none applicable to this source. - Community: none applicable to this source. - Training: a Learn WordPress lesson on scope control in prompts (job boundaries, artifact size, response size) would be genuinely useful and is model-agnostic. - Marketing: none applicable to this source. - Support: none applicable to this source. - Design: none applicable to this source. - Documentation: none applicable to this source. - Photos: none applicable to this source. - TV: none applicable to this source. - Polyglots: none applicable to this source. - Accessibility: worth flagging — a prompt that specifies six sections and word counts says nothing about semantic structure, heading order, or contrast. AI-generated marketing pages default to accessibility problems, and none of the five rules address it. Adding an accessibility constraint to the prompt template is the obvious fix. - Meta: none applicable to this source. - CLI: none applicable to this source. - Hosting: none applicable to this source. - Tide: none applicable to this source. - Openverse: none applicable to this source. - Themes: none applicable to this source. - Plugins: none applicable to this source. #### The WPOCC - Programs: none applicable to this source. - Projects: none applicable to this source. - Funding experiments: none applicable to this source. ### FAIR - Technical independence: mild relevance — prompting practice tied to one vendor's model behavior is a soft form of lock-in, since templates tuned to Opus 5's quirks don't transfer cleanly. - Policies and covenants: none applicable to this source. - Productized governance artifacts: none applicable to this source. ## 🧪 Hypotheses 1. **Redundant verification adds cost without quality.** For Opus 5, prompts including an explicit "check your work twice" instruction produce output of statistically indistinguishable quality from prompts without it, at measurably higher token and latency cost. 2. **Effort level has diminishing returns.** Output quality on typical knowledge-work tasks does not improve monotonically with effort setting; low and medium match high on a substantial share of tasks. 3. **Whole-job prompting beats decomposition.** For Opus 5, a single full-brief prompt produces better-rated output than the same work decomposed into sequential prompts, reversing the pattern for earlier models. 4. **Threshold-gated questions reduce interruption without harming quality.** Instructing a model to ask only questions whose answers would change the whole project reduces clarifying-question count without a measurable drop in output quality. 5. **Response and artifact size are independently controlled.** Constraining response length has no reliable effect on artifact size, and vice versa — they require separate instructions. 6. **Specification precision predicts speed.** More fully specified prompts complete faster, mediated by reduced clarifying-question rounds. ### 📊 Methodology - **H1 (verification instruction) — the key study.** Paired-prompt experiment: identical tasks, one arm with the verification instruction, one without, same model and effort, order randomized. Blind raters score output on a pre-registered quality rubric; log tokens and latency. Sample across task types (code, prose, analysis), because the effect plausibly differs by domain. This is the claim with money attached and it's entirely testable in a day. - **H2 (effort returns).** Same task set run at each effort level, multiple repetitions per cell to handle stochasticity. Blind quality rating plus token and latency logging. Report the quality-per-token frontier rather than a single winner, since the practical question is where the knee is. - **H3 (whole-job vs decomposed).** Within-task comparison: full brief versus the same content split into a sequential chain. Match total instruction content so the comparison is about *structure*, not information quantity — otherwise it measures the wrong thing. Blind rating of final artifacts. - **H4 (threshold-gated questions).** Vary the clarifying-question instruction across three arms: open invitation, threshold gate, no questions permitted. Measure question count, question relevance (rated), and final output quality. The interesting risk is that the gate suppresses questions that *should* have been asked, so include tasks with genuine ambiguity. - **H5 (response vs artifact size).** Full factorial: response constraint present/absent × artifact constraint present/absent. Measure both outputs. Tests whether the video's distinction is real or whether one constraint incidentally governs both. - **H6 (precision and speed).** Vary specification completeness across matched tasks; measure wall-clock completion and clarifying-question rounds. Mediation analysis to test whether question reduction carries the speed effect, which is the presenter's implicit causal claim. ### ❓ Questions - Has anyone tested the verification rule independently? It's the video's strongest and most actionable claim, it comes from the vendor, and the demo doesn't touch it. A paired-prompt comparison would settle it cheaply. - Does "already checks its work" mean the check is as thorough as an instructed one, or just that an additional pass adds little on top? Those are different claims with different implications for high-stakes work. - Where does the threshold gate on questions fail? "Only ask if it would change the whole project" is elegant, but genuinely ambiguous requirements might not clear that bar and should still surface. - How much of the three-minute completion is prompt precision versus the design tool's own variance? Attributed to precision with a sample size of one and no baseline. - Do these rules survive the next model? Prompting guidance tuned to specific model behaviors has a short shelf life, and templates rewritten now may need rewriting again. - What's the accessibility cost of size-constrained generation? Six sections, eight-word headline, 70 words per section — nothing about semantics, heading order, or contrast. AI-generated pages default badly here. - Is "low and medium are surprisingly strong" a claim about capability or about typical task difficulty? If most knowledge work is easy for the model, that's a statement about the tasks, not the effort setting. ### 🔮 Future Research - **Independent verification of vendor prompting guidance.** Model makers publish prompting advice for their own products; almost nobody tests it independently. A standing benchmark that evaluates published guidance against controlled comparisons would be broadly valuable and doesn't exist. - **Effort-level economics.** Systematic mapping of the quality-per-token curve across task types, which would replace guesswork with a defaults table. - **Prompt guidance durability.** How quickly model-specific prompting advice decays across releases, and which advice is model-invariant (scope control, probably) versus model-specific (verification behavior). - **Question-gating strategies.** Comparative study of clarifying-question instructions, including whether thresholds suppress genuinely necessary questions. - **Accessibility of size-constrained generation.** Whether prompt constraints on structure and length correlate with worse or better accessibility outcomes in generated markup. - **Instruction interference.** Whether instructions written for prior model generations actively degrade current-model output rather than merely wasting tokens — a stronger and more concerning version of the video's claim. ### 💡 Implications - **Practice.** Two immediate changes worth making regardless of the verification question: separate your response-length constraint from your artifact-size constraint, because they're different controls and people routinely set one and wonder why the other ran away. And replace open-ended "ask if unclear" with a threshold — the bar for interruption should be stated, not inferred. - **Policy.** For teams, the simplicity argument is worth adopting as policy: pick one default model and effort level, override when results disappoint, and don't ask people to optimize per task. Per-task optimization is real but the coordination cost usually exceeds the gain, and inconsistent defaults make cost reporting meaningless. - **Security.** Not directly applicable. One adjacent note: prompts that instruct a model to make design decisions autonomously and only surface project-level questions will also surface fewer security-relevant questions, which is a tradeoff worth naming when the artifact handles user data. - **Education.** The genuinely durable lesson is the distinction between *more computation* and *better output*. People consistently treat effort settings as quality settings, and the correction — it's a cost dial that sometimes buys quality — is teachable in a sentence and changes behavior immediately. - **Funding models.** Marginal, though the plan-tiered recommendations are a reminder that prompting practice is now stratified by subscription cost, which quietly shapes who can follow which advice. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade 5.8; Flesch Reading Ease 81.8 ("easy"), computed on the 2,274-word transcript. Genuinely accessible — short sentences, everyday vocabulary, deliberate repetition of key points. This is the most linguistically accessible source in the batch, and unusually for this pipeline the score reflects real accessibility, because the presenter defines the few technical terms he uses. #### 👀 Visual learners - Present: strong for the format — the prompt is built incrementally on screen, the design tool run is shown live, and the finished site is walked through section by section while counting against the specification. - Improve: the finished prompt is shown but not provided as copyable text, so acting on it means transcribing from video. A pinned comment or description block with the full prompt would cost nothing and multiply the video's usefulness. #### 🔊 Aural learners - Present: clear, well-paced narration with explicit signposting between rules. Twelve minutes is easy to hold. - Improve: no chaptering, though the rules are announced clearly enough to navigate by ear. #### 🗣️ Verbal learners - Present: the closing compression — "let Opus 5 use its intelligence without letting it overuse its intelligence" — is a genuinely useful mnemonic. Terms are defined as introduced. - Improve: "knowledge work" is used throughout as the scoping term and never defined, which matters because the recommendations are explicitly scoped to it and the demo is a web build. #### 🧩 Kinesthetic learners - Present: the best dimension. The whole video is a build-along — the viewer can construct the same prompt clause by clause and run it. Real assets, real tool, visible result. - Improve: no downloadable prompt, no sample assets, no starter template. Everything must be retyped from screen. #### 🧠 Logical learners - Present: clean rule-by-rule structure with a stated rationale for each. The response/artifact distinction is a genuine analytical clarification. The effort-level correction identifies a real confusion between computation and quality. - Improve: the evidentiary structure is weak in a way a logical viewer will notice immediately. Rules 2 and 3 are demonstrated (six sections requested and delivered, three bullets requested and delivered). Rule 4 — the strongest claim — is asserted from vendor documentation and never tested, and the demo has no comparison arm for anything. #### 🧑‍🤝‍🧑 Social learners - Present: minimal — a single-presenter explainer with no discussion element, though it does position itself as relaying a shared community problem. - Improve: no invitation to report results, no venue for comparing findings. Given that the central claim is independently testable and untested, asking viewers to run the comparison and report back would have been both useful and community-building. #### 🧘‍♀️ Solitary learners - Present: well suited — self-contained, immediately actionable alone, with a complete worked example. - Improve: no self-check. A viewer can't tell whether their own prompts are over- or under-specified, and no rubric is offered. Two contrasting examples — one overspecified, one underspecified — would give a solitary learner calibration. #### 🌿 Naturalistic learners - Present: essentially none; no environmental, ecological, or systems framing. - Improve: the token-and-energy dimension is genuinely relevant and goes unmentioned. Effort levels map directly onto compute consumed, and "don't use more effort than the task needs" is an efficiency argument with an environmental component the video makes purely on cost grounds. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: not directly assessable; video content on a third-party platform. - Improve: the generated website shown in the demo is the relevant artifact, and its semantic structure is never examined — only its section count. Maps to WCAG 2.2 AA 1.3.1 Info and Relationships. #### Keyboard navigation - Present: platform-level; player controls are keyboard-reachable. - Improve: the generated site's keyboard operability is untested on camera, which is a recurring gap in AI-generation demos. Maps to WCAG 2.2 AA 2.1.1 Keyboard. #### Contrast and readability - Present: unverifiable from transcript. - Improve: the prompt instructs the model to keep existing brand colors and make small design choices independently, with no contrast requirement. Brand palettes frequently fail contrast, and nothing in the workflow catches it. Maps to WCAG 2.2 AA 1.4.3 Contrast (Minimum). #### Text resizing and reflow - Present: not applicable to the video. - Improve: the generated site is only viewed at desktop width. Maps to WCAG 2.2 AA 1.4.4 Resize Text, 1.4.10 Reflow. #### Media and captions - Present: auto-captions available and largely accurate — this transcript required less correction than others in the batch, helped by clear enunciation and limited jargon. - Improve: no human-corrected track or transcript in the description, and the full prompt — the most reusable artifact — exists only as on-screen text a caption user cannot access. Maps to WCAG 2.2 AA 1.2.2 Captions, 1.2.5 Audio Description. #### Forms and interactions - Present: not applicable to this source. - Improve: none. #### Standards reference - Aggregate: the notable issue isn't the video's own accessibility, which is decent, but that **none of the five rules produce accessible output**. A prompt specifying six sections, an eight-word headline, and 70-word limits says nothing about heading hierarchy, alt text, contrast, or keyboard operability — and the verification step counts sections rather than checking any of that. For anyone shipping generated pages, an accessibility clause belongs in the prompt template and a keyboard pass belongs in the check. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the technique is culture-neutral, and the fictional brand example carries no regional assumptions. - Improve: entirely US-pricing-centric — recommendations are structured around $20 and $100 plan tiers with no acknowledgment that those thresholds represent very different burdens across economies. Advice explicitly gated by subscription cost deserves at least a nod to that. #### Inclusive language - Present: neutral, plain, and jargon-light throughout. Genuinely one of the more linguistically accessible pieces in this batch. - Improve: "knowledge work" recurs as the scoping category without definition, which quietly assumes a professional-office frame of reference. #### Neurodiversity support - Present: strong. Explicit enumeration, one rule at a time, consistent structure, deliberate repetition, and a stated preference for a single simple default over per-task optimization — which is itself an accommodation for decision fatigue and is presented as legitimate rather than lazy. - Improve: little to fault. The incremental prompt construction is well suited to sequential processing. #### Representation - Present: not applicable in the usual sense — no case studies, quoted individuals, or imagery beyond a fictional brand. - Improve: the implicit user has a paid subscription, brand assets ready, and a site to deploy to. The free-tier user is addressed only to be told the smallest model isn't worth using for work, which leaves them without a path. #### Psychological safety - Present: good. Non-hectoring tone, explicit permission to keep things simple ("you don't have to be this precise"), and consistent attribution to Anthropic rather than claiming personal authority. That last habit protects the viewer from mistaking relayed guidance for tested fact — though it also means the video never takes responsibility for verifying it. - Improve: minimal concern. The framing that prompting the old way means "you are not going to get good results" is mildly alarming for a video whose actual advice is incremental, but it's a headline convention rather than a real pressure. ### ✅ Logical Validity #### Strong reasoning - **The effort-level correction.** Distinguishing *amount of computation* from *quality of output* identifies a real and widespread confusion, and the conclusion — that high effort is often overkill — follows directly from the premise that effort governs thinking time rather than capability. This is the video's best conceptual contribution. - **The response/artifact distinction.** Recognizing that constraining the reply doesn't constrain the deliverable is a genuine analytical clarification, correctly derived, and it explains a failure people experience without diagnosing. - **Threshold-gating clarifying questions.** "Only ask me a question if the answer would change the whole website" is well-constructed: it doesn't forbid questions, it supplies a decision criterion for when interruption is warranted. That's the right shape for an instruction to an autonomous agent. - **Consistent attribution.** Claims about model behavior are repeatedly sourced to Anthropic rather than asserted personally. For a summary video this is the correct epistemic posture and it lets the viewer discount appropriately. - **Acknowledged tradeoff on model switching.** Explicitly stating that per-task optimization would be better and choosing simplicity anyway is honest reasoning about a real cost, rather than pretending the simple choice is optimal. #### Fallacies - **Appeal to vendor authority on the central claim.** The verification rule — the video's most consequential and most actionable item — rests entirely on Anthropic's statement about its own product. **Weakness:** the party making the claim benefits from users spending fewer tokens on redundant passes *and* from the perception that its model self-verifies. No independent evidence is offered. **Fix:** run the paired comparison, which takes an afternoon, or explicitly flag the claim as untested vendor guidance rather than folding it in alongside demonstrated rules. - **Demonstration that doesn't test the claim.** The demo verifies section count and bullet count, then the video concludes the five rules work. **Weakness:** rules 2 and 3 are genuinely evidenced; rules 1 and 4 are not tested at all, and rule 4 is the one that reverses prior practice. Successful adherence to *some* instructions is presented as validation of *all* the guidance. **Fix:** run the same task with and without the verification instruction and show both. - **Post hoc attribution of speed.** The three-minute completion and absence of follow-up questions are attributed to prompt precision. **Weakness:** single run, no baseline, and the tool's own latency variance is unmeasured. The presenter notes it's "quite fast for Claude design," which is an impression rather than a measurement. **Fix:** run the underspecified version of the same prompt and compare. - **Overstated framing in the premise.** "If you prompt it the same way you've been prompting previous Claude models, you are not going to get good results." **Weakness:** the actual guidance that follows is incremental — give fuller context, bound scope, skip one redundant instruction. None of that supports "not going to get good results," which implies failure rather than suboptimality. **Fix:** match the framing to the advice. - **Unexamined scope of the recommendations.** Rules are presented as applying to "knowledge work" generally, demonstrated on a single creative-generation task. **Weakness:** whether whole-job prompting and reduced verification transfer to analysis, code, or high-stakes reasoning is untested and unaddressed — and the verification rule is exactly the one whose risk profile varies most by domain. **Fix:** scope the claims to demonstrated task types, or test across domains. #### Tone of voice - Instructional and efficient, with the register of a practitioner sharing a workflow rather than an expert asserting authority. The service framing — "I read through this entire thing so you don't have to" — is stated plainly and delivered on. - Consistently deferential to the source. "Anthropic agrees," "Anthropic has said," "that is not the way that Anthropic describes it." The repetition is doing real epistemic work, keeping relayed claims distinguishable from the presenter's own. - Permissive rather than prescriptive on details — "you don't have to be this precise," "you could say something like," "I like to keep it simple." This lowers the barrier and models a reasonable relationship to guidance. - Mildly promotional at the edges: an emphatic opening claim and a closing pivot to another video. Both are genre conventions and neither distorts the content. - Notably calm about model capability. No hype vocabulary, no transformation claims — the strongest praise is "it's just that good," delivered in passing. ### 🛡️ DARVO Analysis - **Deny:** No DARVO pattern present. This is an instructional summary with no accusation in play, nothing to deny, and no defensive posture. The presenter's relationship to the material is that of a relay, and where uncertainty exists he attributes rather than asserts. - **Attack:** Not present. No person, competitor, tool, or critic is disparaged. The smallest model is dismissed for professional use on capability grounds, which is a recommendation rather than an attack, and no vendor or practitioner is criticized. - **Reverse victim/offender:** Not present. No party is positioned as wronged or aggrieved, and no role reversal occurs. The framing throughout is problem-and-solution, not grievance. - **Emotional cues and rhetoric:** Persuasion runs through demonstration and clear enumeration rather than through grievance, blame, or victim positioning. Applying the DARVO frame to a prompting tutorial is a category error — the frame targets defensive responses to accusation, and this is unprompted instructional content. The honest finding is absence; the piece's real epistemic weakness is uncritical relay of vendor claims, logged under Fallacies. ## 🎯 Conclusion - **Bottom line.** Five rules, of which four are ordinary good prompt hygiene that would help with any model — give the full brief, bound the job, bound the response, bound the artifact — and one that genuinely reverses years of standard practice: stop instructing the model to double-check its work, because Anthropic says Opus 5 already does. The scope rules are safe to adopt today. The verification rule is the one with real money attached and the one nobody has independently tested. - **The best single line to steal.** "Only ask me a question if the answer would change the whole website." That converts an open invitation to interrupt into a stated threshold, and it works with any agent on any task. Most people write "ask if anything's unclear" and then wonder why they're fielding trivia. - **The distinction most people are missing.** Constraining the response is not constraining the artifact. A three-bullet reply can ship a sprawling website. They are separate controls requiring separate instructions, and the video is right to separate them. - **Where to be skeptical.** The demo proves the model followed structural instructions — six sections asked for, six delivered. It proves nothing about the verification claim, because there is no comparison run. And "it finished in three minutes because my prompt was precise" is a sample of one with no baseline. Adopt the rules, but run the paired test before you strip verification instructions out of templates you rely on. - **On effort levels.** The correction worth carrying: effort is a *cost* dial that sometimes buys quality, not a quality dial. Defaulting to maximum is usually paying more for the same answer. Start low or medium and escalate on disappointment. ## 🔄 Refactor Appendix — Anthropic Just Revealed How to Prompt Opus 5 > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) ### [H1] Effort level is a cost dial, not a quality dial > [!quote] ID:rw_pending > The effort setting mainly controls how much thinking Claude does, which affects the time and tokens it spends on the task. While that can produce better answers, sometimes, a lot of the time, it's just overkill. **Context & use**: - [00:02:23](https://www.youtube.com/watch?v=Z8CtXdQExek&t=143), the effort-level section - The video's best conceptual contribution and the most widely misunderstood setting in agentic tooling. People treat effort as a quality slider and default to maximum, paying more for the same answer. Directly relevant to my own model/effort policy. **Tags**: #xref #share #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H2] Gate clarifying questions with a stated threshold > [!quote] ID:rw_pending > Only ask me a question if the answer would change the whole website. **Context & use**: - [00:04:48](https://www.youtube.com/watch?v=Z8CtXdQExek&t=288), rule two - The most portable single line in the video. Converts "ask if unclear" from an open invitation into a decision criterion. Works with any agent on any task. Test its failure mode: does the threshold suppress questions that genuinely should surface? **Tags**: #xref #share **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H3] Bounding the response does not bound the artifact > [!quote] ID:rw_pending > if we left the prompt as is, we might get a short response from Claude, but the website could be too large **Context & use**: - [00:06:25](https://www.youtube.com/watch?v=Z8CtXdQExek&t=385) - A genuine analytical clarification that explains a failure people experience without diagnosing. Two separate controls requiring two separate instructions — most people set one and wonder why the other ran away. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H4] Opus 5 self-verifies, so re-check instructions are redundant > [!quote] ID:rw_pending > Anthropic says that Opus 5 already checks and fixes its work as it goes along. If we force it to do the whole check again, it may take more time and use more tokens without actually making the end result any better. **Context & use**: - [00:08:00](https://www.youtube.com/watch?v=Z8CtXdQExek&t=480), the rule that reverses standard practice - The most consequential and least supported claim in the video. Sourced entirely to the vendor; the demo never tests it. Worth a paired-prompt comparison before stripping verification instructions from templates. Note the domain question too — the risk profile of skipping verification differs sharply between marketing copy and production code. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] More computation is not the same as better output **Claim** (one sentence, Courtney's voice): Spending more effort on a task only improves the result when the task was actually limited by effort. **Evidence pointer**: [[#H1]] > [!quote] > a lot of the time, it's just overkill **Scope & conditions**: Holds where the binding constraint is something other than compute — clarity of the request, quality of context, or inherent task difficulty. Applies well past model settings: more meeting time, more reviewers, more analysis. Breaks where the task genuinely is compute-bound, and where extra effort buys reliability rather than average quality (worth paying for in high-stakes work even at flat expected quality). **Links**: - [[Diminishing returns]] — because extends - [[Model and effort policy]] — because applies-in - [[Context problem before effort problem]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Direct confirmation of my own diagnostic order — context problem → effort problem → model problem. This video is the vendor-side version of the same point: don't escalate effort to compensate for an underspecified prompt. Worth citing in the routing policy. — #fleeting #inbox #xref - [F2] The verification-rule claim is testable in an afternoon with a paired-prompt comparison, and nobody appears to have done it. Small, useful, publishable experiment. — #fleeting #inbox #articleseed - [F3] "Only ask if the answer would change the whole project" — steal this for my own agent instructions and skill definitions. Threshold-gating beats open invitation everywhere. — #fleeting #inbox #share - [F4] Accessibility gap worth writing up: none of the five rules produce accessible output, and the verification step counts sections rather than checking heading order, alt text, or contrast. "Add an accessibility clause to your prompt template" is a short, useful post nobody has written. — #fleeting #inbox #articleseed - [F5] Prompting guidance tuned to a specific model has a short shelf life. Which parts are model-invariant (scope control) versus model-specific (self-verification behavior)? Useful frame for anything I write about prompting. — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Run the paired-prompt test on the verification rule — same task with and without "check your work," compare quality, tokens, latency — AI workflow experiment #things - [ ] Add a threshold-gated clarifying-question clause and an accessibility constraint to my standing prompt templates — tooling #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Anthropic Just Revealed How to Prompt Opus 5.md|Anthropic Just Revealed How to Prompt Opus 5 by Paul J Lipsky]] ## Highlights - to keep it simple. So now I just leave it on Opus 5 almost all the time. Okay, so let's assume you're going to use Opus 5. The next decision is what effort level are you going to use? And this is where I think a lot of people are going to make a mistake. They just assume that higher effort levels mean that it's going to produce better results. But that is not the way that Anthropic describes it. The effort setting mainly controls how much thinking Claude does, which affects the time and tokens it ([View Highlight](https://read.readwise.io/read/01kyhzcnvfnpghj59j68pb1hy1)) - Note: [H1 / P1] Effort level is a COST dial, not a QUALITY dial. The video's best conceptual contribution and the most widely misunderstood setting in agentic tooling. Effort governs how much thinking happens — time and tokens. That sometimes produces better answers and "a lot of the time, it's just overkill." People treat it as a quality slider, default to maximum, and pay more for the same answer. DIRECT CONFIRMATION of my own diagnostic order: context problem → effort problem → model problem. Never escalate effort to compensate for a vague prompt. This is the vendor-side version of the same point. General principle (P1): more computation only improves the result when the task was actually limited by computation. Applies well past model settings — more meeting time, more reviewers, more analysis. Caveat worth holding: extra effort may buy RELIABILITY rather than average quality, which is worth paying for in high-stakes work even at flat expected quality. - Tags: atom/zettel/z1, atom/literature/h1, effort-levels - helpful sometimes, but often it results in Claude going overboard and doing more than you really need or want it to do. So, tell it when the job ends and add some clear limits. For our prompt, we will add this. "Build only the home page. Link the buy buttons to the shop page that already exists. Keep the current logo, colors, and product name. Make small design choices yourself. Only ask me a question if the answer would change the whole website. So, now Claude ([View Highlight](https://read.readwise.io/read/01kyhzd8mbnr57zvbd14kjq8a9)) - Note: [H2] "Only ask me a question if the answer would change the whole website." The most portable single line in the video. Converts "ask if anything's unclear" from an open invitation into a stated THRESHOLD. Most people write the open version and then wonder why they're fielding trivia. Works with any agent, any task. ACTION: steal this for my own agent instructions and skill definitions. Failure mode to test: does the threshold suppress questions that genuinely SHOULD surface? Ambiguity that doesn't change the whole project can still change the right answer. Worth checking on tasks with real ambiguity before adopting wholesale. Also note the accessibility gap in this same prompt — "make small design choices yourself" plus "keep the current colors" with no contrast requirement. Brand palettes routinely fail contrast and nothing here catches it. - Tags: scope-control, atom/literature/h1, action/h1 - isn't about what you should tell Opus 5, it's what you shouldn't tell it. For a while now, we've been telling AI to check the work that it's done. After it's done, check every file twice, find every possible mistake, and fix all of them. And usually that would get you better results. However, Anthropic says that Opus 5 already checks and fixes its work as it goes along. If we force it to do the whole check again, it may take more time and use more tokens without ([View Highlight](https://read.readwise.io/read/01kyhzdstxb4pwwn7sb5ppmjmk)) - Note: [H4] THE claim that reverses years of standard practice — stop telling it to double-check its work. If accurate, a lot of people are paying tokens for a verification pass they're getting anyway. Nuance preserved: still tell it what good looks like, just don't make it repeat the same check. FALLACY (appeal to vendor authority): rests entirely on Anthropic's statement about its own product. The party making the claim benefits both from users spending fewer redundant tokens AND from the perception that its model self-verifies. No independent evidence offered. AND THE DEMO DOESN'T TEST IT. The walkthrough verifies section count (6 requested, 6 delivered) and bullet count (3 requested, 3 delivered) — real evidence for the scope rules. There is no comparison arm with the verification instruction included, so the strongest claim in the video is the one never demonstrated. TESTABLE IN AN AFTERNOON: paired prompts, same task, one with "check your work" and one without, blind quality rating plus token/latency logging. Domain matters — risk profile of skipping verification differs sharply between marketing copy and production code. Run this before stripping verification from templates I rely on. - Tags: atom/literature/h1, fallacy/appeal-to-authority, prompt-engineering ## Links - [[3. Resources/Permanent Notes/Effort Is a Cost-Quality Dial That Subsumes Prompt Complexity]] — evidence-for: higher effort changes time and token spend, not guaranteed quality. - [[3. Resources/Permanent Notes/Vague Prompts Are Expensive Specificity Cuts AI Error and Cost Together]] — applies-in: explicit scope, endpoint, and artifact bounds reduce follow-up work.