Four Prompt Patterns Worth Testing on Claude (None of Them Is 10x)

My working title for this post was "The Prompt Pattern That Gets 10x Better Results from Claude."

I changed it. I can't back that up. Not honestly.

A 10x claim needs a metric. Ten times fewer errors? Ten times cheaper? Ten times more useful? Without a metric, a multiplier is a slogan, and nobody can check it.

What I can do is show you patterns Anthropic documents, point out which ones come with published measurements, say exactly what was measured, and give you a way to test them on your own work. That is a smaller promise. It is also one you can verify.

Scope, upfront: I did not run any benchmarks. Every result below is Anthropic-reported, from its Sonnet 5.5 prompting guide and its general best practices, read on 2026-11-10. The prompt wording in this post is my own, modeled on those patterns. For Anthropic's exact text, use their pages.

The idea: a prompt is a contract

Most prompts say what to do and stop there. A better prompt makes four promises explicit:

1. Task: what you want, and why.
2. Scope: where the job ends.
3. Proof: how the model shows it's done.
4. Shape: what the answer looks like.

Standing rules go in the system prompt. The specific request goes in the user message. Let's start with the groundwork, then take the four in turn.

Pattern 0: frame the task like a briefing

Before the four patterns, the groundwork. Anthropic's general guidance is consistent:

• Be clear and direct. Treat Claude like a brilliant new employee who lacks your context. The docs offer a test: show your prompt to a colleague with minimal context. If they'd be confused, Claude will be too.
• Give the reason. The docs' example is telling Claude that output will be read aloud by a text-to-speech engine, rather than just banning ellipses. Claude can generalize from the reason.
• Say what to do, not what not to do. Ask for flowing prose paragraphs instead of "no markdown."
• Set a role, even in one sentence. The docs say a single sentence in the system prompt makes a difference.
• Ask for the extra effort explicitly. If you want more than the minimum, say so rather than expecting the model to infer it.

None of that is surprising. It is also the layer most prompts skip.

Pattern 1: scope control

Here's what the Sonnet 5.5 guide says about how far the model goes on its own. It depends on effort and on the request:

• At low and medium effort on long agentic tasks, the model sometimes checks in before finishing. It might confirm a plan, ask something it could answer itself, or stop after one part of a multipart task.
• At every effort level, and more at higher ones, it tends to add tests, docs, and small supporting files you didn't ask for. On open-ended requests it can start building something, such as a presentation, when you only wanted ideas.

The docs' first advice is to try a higher effort level. If you want to steer with the prompt instead, the pattern has two halves. Here is my wording:

<scope>
Work through the whole request without pausing for confirmation, unless you are
genuinely blocked or about to take an action that is risky or hard to reverse.

Once the requested work is finished and verified, send your report and stop.
Anything extra that would be nice to have (more tests, docs, cleanup) goes in a
closing note as a suggestion, not into the change itself.
</scope>

Two cautions from the docs. First, Anthropic's keep-going instruction makes sessions at low and medium effort run longer and cost more. Second, this does not replace your own rules about risky or irreversible actions. Keep those in the system prompt.

There is also a variant for very high effort. At xhigh and max, the model can start its own rounds of review and verification, sometimes with subagents, and make related fixes it noticed. Anthropic's guide has a prompt telling it to stop and report after the work and its checks pass, and not to start extra review rounds or launch reviewer subagents unless asked. Anthropic reports that in testing on coding tasks at max effort, this stopped the reviewer subagents and cut session cost by about a third, with no change in quality. It also notes that it reduces self-started reviews without removing them entirely.

My wording of the same idea:

<scope_review>
Once the requested work is finished and its checks pass, report back. Don't begin
additional review passes or spawn reviewer agents unless a review was requested.
If you think a deeper review is warranted, recommend it in your closing note.
</scope_review>

Read the fine print. The one-third figure belongs to Anthropic's instruction, not to my wording. It is for one model, one effort level, one family of tasks, and one specific prompt.

Pattern 2: proof of work

The second pattern fixes a common failure: "done" without evidence.

The Sonnet 5.5 guide says the model generally checks its work before reporting a code change as done. At low effort, though, it sometimes reports done without running a check that exercises the change. The example given is skipping the project's tests because dependencies weren't installed.

The pattern: require a real check, define what counts as real, and give an honest exit.

<proof>
Before you call a code change finished, verify it by actually running something
that touches the change: the test suite, the type-checker, the build, or the
command you modified. Merely parsing the file doesn't count. If nothing
meaningful can be run in this environment, say which check you couldn't run and
why, rather than declaring success.
</proof>

Anthropic reports that at low effort, its version of this paragraph makes skipped or superficial checks rare, with no measurable change in task quality and a slightly higher cost per task. Notice the honest exit at the end. My reasoning, not a documented claim: without a sanctioned way to say "I couldn't run it," a model has more reason to skip the check quietly.

My extension, untested: this pattern is not only for code. The general form is: define what counts as evidence, and say what to do when evidence is unavailable.

Pattern 3: the reasoning nudge

This one is narrow, and I'd rather you know that.

It applies when you ask Claude Sonnet 5.5 for a JSON answer to a task that needs a few steps of working out, such as totaling figures from a document, applying a rule, or ranking items. The docs say the model often answers without thinking first on tasks like these, especially at low and medium effort. With structured outputs, the response text holds only the JSON, so the model can work the problem out only in its thinking. If it skips thinking, accuracy can drop.

The fix, in Anthropic's wording, is one line at the end of the system prompt, with adaptive thinking:

Think the problem through before you answer.

What Anthropic reports:

• At high effort, the line brings accuracy close to what the model reaches at xhigh, for a modest increase in output tokens.
• At low and medium effort, it raises accuracy, but not to what high reaches, and the token increase is larger.
• xhigh effort gives the highest accuracy on these tasks even without the line, at more output tokens than high.

Three conditions matter:

1. Use adaptive thinking, not between_tools. In a request without tools, between_tools means no up-front thinking, so the line does nothing.
2. Treat stop_reason: "max_tokens" as a failure, even if the text holds valid JSON, and retry. At low and medium effort with structured outputs, the model occasionally keeps thinking until it hits the limit.
3. Prefer structured outputs where available. If you can't use them and ask for JSON in the prompt, the model may work out the answer in the response text and write JSON at the end. The docs recommend parsing the last JSON value in the response, not everything between the first { and the last }, because a draft can sit before the final answer.

Pattern 4: the output contract

The fourth pattern is about shape. Unlike the three above, I found no published numbers for it. It is guidance. I covered most of it in Day 5, so briefly:

• Name the format positively. "Write the answer as flowing prose" beats "don't use bullet points."
• Use tags for the parts you parse. Tell Claude which tags to use, then extract them, and handle a missing tag.
• Match your prompt's style to the output style you want. The docs say removing markdown from the prompt can reduce markdown in the answer.
• Don't ask for the model's reasoning in the answer. On several current models, including Sonnet 5.5, this can trigger a reasoning_extraction refusal. Read summarized thinking blocks instead. You can still ask for a short explanation of the answer or a summary of the actions taken.

<output_format>
Put the answer in <answer> tags. Put anything the user should double-check in
<caveats> tags. Keep each to a few sentences.
</output_format>

Putting it together

Here is a starting system prompt that combines the four. It's my wording, and it's untested. Use it as a draft to measure, not a recommendation to ship.

<role>
You are a careful engineer working in this repository.
</role>

<scope>
Work through the whole request without pausing for confirmation, unless you are
genuinely blocked or about to take an action that is risky or hard to reverse.
Once the requested work is finished and verified, send your report and stop.
Suggest extras in a closing note instead of adding them.
</scope>

<proof>
Before you call a code change finished, verify it by actually running something
that touches the change. If nothing meaningful can run here, say which check you
couldn't run and why.
</proof>

<output_format>
Put the answer in <answer> tags and anything to double-check in <caveats> tags.
</output_format>

Add the one-line reasoning nudge only for multistep, structured-output tasks, and only with adaptive thinking. If your product answers questions that depend on current details, such as what's allowed or what something costs, the Sonnet 5.5 guide also suggests telling the model to check specifics that may have changed with its search tool. It says to first remove any wording that discourages tool use.

Prompts decay

One more point, because it is where good prompts quietly go bad.

The docs say existing Claude Sonnet 5 prompts should perform well on Sonnet 5.5 without changes. They also say a technique measured on one model should be re-checked on another. A few examples from the guides:

• Telling the model not to think can make it more likely to write internal XML tags into its visible output when you run with between_tools.
• If you want progress updates on Sonnet 5.5, the guide says to remove older instructions like "hold all findings for the final response."
• Verification instructions carried over from earlier prompts can cause over-verification on Opus 5.
• Asking the system prompt to make Sonnet 5.5 think less doesn't reliably work. Lower the effort instead.

So the maintenance rule is: when you change models, re-test your prompt, and delete instructions that were patches for a problem the new model no longer has. (This is why named blocks from Day 5 matter. Deleting one block is easy.)

How to measure it yourself

Here is a small harness. Hold the model, effort, and thinking settings constant across variants (the lesson of Day 4). Otherwise you are measuring settings, not prompts.

import time

def evaluate(system_prompt: str, cases: list[dict]) -> dict:
    passed, out_tokens, seconds = 0, 0, 0.0
    for case in cases:
        start = time.perf_counter()
        r = client.messages.create(
            model="claude-sonnet-5-5",
            max_tokens=16000,
            thinking={"type": "adaptive"},
            output_config={"effort": "medium"},
            system=system_prompt,
            messages=[{"role": "user", "content": case["task"]}],
        )
        seconds += time.perf_counter() - start
        text = "".join(b.text for b in r.content if b.type == "text")
        if r.stop_reason != "max_tokens" and check(text, case):  # your own check
            passed += 1
        out_tokens += r.usage.output_tokens
    n = len(cases)
    return {"pass_rate": passed / n, "avg_output_tokens": out_tokens / n, "avg_seconds": seconds / n}

for name, prompt in {"baseline": BASELINE, "contract": CONTRACT}.items():
    print(name, evaluate(prompt, CASES))

Track three numbers per variant: pass rate, output tokens, and latency. A pattern that raises quality by adding cost is not the same as one that holds quality while cutting cost. You need to see both columns. As a rule of thumb of mine, not Anthropic's, use 20 or more real cases, include the awkward ones, and write check so it tests something concrete.

What I'm not claiming

• I didn't run these tests. The numbers are Anthropic's, and I haven't reproduced any of them.
• They don't transfer automatically. The docs themselves say a technique measured on one model should be re-checked on yours. The results here were on Sonnet 5.5, on coding and structured-output tasks. I don't know how Haiku 5.5 or Opus 5.5 behave.
• The wording is mine. I wrote my own versions of the patterns. Anthropic's exact prompts are on its pages, and the numbers belong to those prompts, not to mine. Mine are untested.
• Only three of the four patterns have published numbers. The output contract is guidance, not a measured result.
• There is no 10x. If someone shows you one, ask what they measured.
• Docs move. This reflects documentation read on 2026-11-10.

The short version

Treat a prompt as a contract: say the task and why, say where it ends, say how to prove it's done, and say what the answer looks like. Each of those has a documented pattern. None of them is magic, and every one of them is worth testing on your own inputs.

Smaller promise. Better odds of keeping it.

---

Sources

• Anthropic docs: Prompting Claude Sonnet 5.5
• Anthropic docs: Prompting best practices
• Anthropic docs: Effort