Claude Code prompt engineering masterclass: 10 patterns we use daily

Most prompt engineering guides online are recycling 2023 advice for 2026 models. Many of the old tricks (begging, threatening, “you are an expert”) have stopped helping or actively hurt. The new ones aren’t yet well-documented.

Here’s what we’ve learned from running Claude Code daily across content production, agentic ops, code refactors and client work.

1. Anchoring

State the expected output shape + length explicitly, with anchor examples.

Weak:

“Write a blog post about Claude Code.”

Strong:

“Write a blog post in our voice. 800-1,200 words. Structure: punchy hook → ‘what it is’ → 3 specific examples with AUD pricing → ‘who it’s for’ → CTA. Like [paste example URL].”

Anchors compress the model’s distribution. You get more predictable output.

2. Exemplars (few-shot)

Two specific examples beat 500 words of description.

Instead of “write in our voice, punchy, direct, no fluff, Australian English…” (which Claude will interpret a thousand ways), paste 2-3 actual prior pieces and say “match this exact voice.”

The exemplars are the prompt. Everything else is gravy.

3. Role priming (use sparingly)

“You’re an expert [domain]” was the 2023 cornerstone. In 2026, it mostly doesn’t help, frontier models default to expert behaviour without being told.

When role priming DOES help:

• Domain-specific voice (“You’re drafting in the style of an Australian small-business owner, not a corporate strategy consultant”)
• Audience targeting (“You’re writing for a non-developer Australian SMB operator who doesn’t want jargon”)
• Constraint framing (“You’re a tax-preparer’s assistant, never give tax advice, draft only”)

The role should give the model something to be, not just a credential to wave.

4. Negative constraints

What NOT to do is often more useful than what TO do.

Strong:

“Do NOT use the phrases ‘get into’, ‘elevate’, ‘let’s dive in’, or ‘in today’s fast-paced world’. Do NOT start sentences with ‘In summary’. Do NOT use em dashes. Do NOT add disclaimer paragraphs unless I asked for one.”

Each “do NOT” eliminates a specific failure mode. Cheap, effective.

5. Scratchpads (explicit thinking)

For complex tasks, ask the model to think in a scratchpad before producing final output.

You'll respond in two blocks:

<thinking>
[Work through the problem step by step. Consider counter-examples. Check your math.]
</thinking>

<final>
[Final answer only. Tight. No restatement of the question.]
</final>

Two benefits: better reasoning (the model literally thinks longer), and you get clean final output without rambling.

6. Structured-output forcing

If you’ll parse the output programmatically, force structured output. JSON Schema, defined function-call shapes, or explicit “respond in EXACTLY this format” tags.

For Claude API specifically, use the tool_use mechanism with input schemas. The model is constrained at decode time to produce conformant outputs.

For Claude Code interactive use, the format-forcing pattern works:

“Respond with three sections, in this exact order, with these exact headings: ## What I changed / ## Why / ## What to verify. No other text outside these sections.”

7. Criteria-explicit grading

Want the model to judge something? Don’t ask “is this good?” Ask “is this good against these specific criteria”:

“Grade this draft email against the following criteria, 1-10 each:

1. Australian English (no Americanisms)
2. Specific to the reader (not generic)
3. Clear action requested
4. Tone matches our brand voice (warm + direct, not corporate)
5. Under 200 words

Output: scores + 1-sentence justification each. No overall recommendation.”

You get usable feedback instead of “looks good!“

8. Role-as-coach (not role-as-doer)

For your own learning, use Claude as a coach who critiques your work, not as a doer who replaces it.

“Here’s my first draft. Don’t rewrite it. Tell me the three biggest weaknesses and what I’d do to fix each. Don’t fix them for me.”

Build your skills; don’t atrophy them.

9. Plan-then-execute

For multi-step tasks, split into “plan” and “execute” turns.

Turn 1:

“Plan how you’d approach this refactor. List the files you’d touch, the order, and the risk areas. Do NOT make changes yet.”

You review. Turn 2:

“Approved. Execute the plan.”

Two benefits: you catch dangerous approaches before they happen, and the executed work is higher quality because the model has thought first.

10. Post-hoc verification

After Claude produces output, ask it to verify against the spec.

“Now review your response against the original request. List anything you missed, any assumptions you made, any places you weren’t sure. Be honest.”

Models in 2026 are surprisingly good at self-critique when prompted. The catch rate on this verification pass is typically 1 out of every 5-10 outputs, small but real.

What stopped working in 2026

• Begging (“Please please give me a perfect answer, I’ll lose my job”), neutral to mildly negative on modern frontier models.
• Threatening / urgency, same.
• “You are an expert [domain]” alone, frontier models default to expert behaviour. Save the role frame for cases where you’re narrowing the model’s defaults, not just labelling competence.
• Long preambles before the actual ask, wastes tokens. Get to the ask faster.
• Asking for “100% accuracy”, meaningless to the model and ignored.

How we layer patterns

A typical content prompt for On Autopilot might use:

• Role priming (writer for AU SMB audience)
• Voice exemplars (2-3 prior pieces)
• Anchoring (length, structure)
• Negative constraints (banned phrases)
• Plan-then-execute for long pieces

5 patterns. Not 10. Picking the right 3-5 for the task beats throwing everything at the wall.

How to test what works for you

Run the same prompt twice, once with the pattern, once without. Look at the actual output. If you can’t tell the difference, the pattern isn’t earning its keep on your task.

Repeat for each pattern, each task type. Build your personal kit.

If you want the CLAUDE.md template we use across Boring Ventures, it’s in our Claude Code Starter Pack.