Claude prompts — what works, what changed, and how to write better ones

Why your old prompts feel different now

Anthropic rebuilt how Claude follows instructions with the Claude 4 series. The result is a model that is more precise and more steerable — but also one that won't add things you didn't ask for. A prompt that used to produce a polished, padded response ("go beyond the basics to create a fully-featured implementation") now produces the minimum viable version of what you described.

This isn't a regression. It's a deliberate trade: predictable, controllable behavior in exchange for a model that improvises less. The fix is usually adding one line — the specific scope, the desired depth, the explicit request for detail — rather than re-prompting from scratch.

Anthropic's own docs now include this example:

The lesson holds across every domain: name the outcome you want, not just the task.

The techniques that consistently work

XML tags

XML tags are the single highest-leverage change most people haven't made. Claude's training makes it parse labeled sections reliably, in a way plain paragraphs don't guarantee. Wrapping distinct elements in <instructions>, <context>, and <input> removes ambiguity about which text is which:

<context>
You are helping a product manager write a one-pager for an internal stakeholder audience.
</context>
 
<instructions>
Write a 300-word one-pager for the feature described below. Use plain prose, no bullet points. End with a single clear ask.
</instructions>
 
<input>
{{FEATURE_DESCRIPTION}}
</input>

DreamHost tested 25 prompt techniques and found structured/labeled prompts scored 9–10/10 for effectiveness — the highest of any single method. For prompts that mix instructions, context, and variable inputs, XML tags aren't optional.

Few-shot examples

Telling Claude what you want is less reliable than showing it. Three to five concrete examples in <example> tags produce more consistent output than any amount of descriptive instruction — especially for tone, format, and edge cases.

One FSM design study found 90% success rates with structured examples versus instructions alone, versus significantly lower rates without them. Put your examples in <examples> tags with each individual one in <example> tags:

<examples>
  <example>
    Input: "Quarterly review was postponed"
    Output: "Q3 review rescheduled — new date TBD"
  </example>
  <example>
    Input: "The launch event got cancelled due to low signups"
    Output: "Launch event cancelled — will revisit when pipeline is stronger"
  </example>
</examples>

Make examples diverse enough to cover the edge cases you care about. If they're too similar, Claude picks up unintended patterns.

Context before the question

For long documents or data-heavy inputs, put the material first and the question last. Anthropic's internal testing found this can improve response quality by up to 30% on complex multi-document inputs. The intuition is simple: Claude reads the full context before it knows what to look for, and placing the question at the end means it was just answered rather than previewed.

Give Claude a reason, not just a rule

Negative constraints backfire. "Never use ellipses" produces worse results than "Your response will be read aloud by a text-to-speech engine, so avoid ellipses." Claude is good enough at generalizing from explanations that it will honor the spirit of the rule rather than hunting for loopholes around the literal one.

The same goes for format preferences: instead of "don't use markdown," try "Write in flowing prose paragraphs — this will be pasted into a Notion doc."

Adaptive thinking for complex tasks

For tasks that require reasoning — competitive analysis, architecture decisions, anything with multiple valid approaches — Claude 4.6+ supports adaptive thinking. When enabled, Claude decides how much to think before responding. For hard tasks, this produces meaningfully better output than a flat prompt. You don't need to enable it explicitly in the Claude web interface; the model uses it when complexity warrants it.

If you're using the API, the switch from budget_tokens to effort levels is the migration path. More in Anthropic's prompt engineering docs.

What stopped working

ALL CAPS emphasis. Claude now prioritizes logical context over typographic shouting. NEVER do X often produces the same results as never do X. Use it sparingly, or not at all.

Manual chain-of-thought when thinking is on. Telling Claude to "think step by step" in a prompt while adaptive thinking is enabled is redundant and can inflate thinking tokens without improving output. Pick one.

Prefilled responses. Starting with Claude 4.6, prefilling the last assistant turn returns a 400 error. The migration: use explicit instructions in the system prompt ("Respond directly without preamble") or ask Claude to output inside XML tags and strip the tags in post-processing.

Over-prompting aggressive instructions. Phrases like "CRITICAL: you MUST use this tool when..." were necessary in Claude 3.5 to get tools to trigger. In Claude 4.5+, those same phrases cause overtriggering. Dial them back to plain language.

The thing most people get wrong: sessions, not prompts

One maker tracked 2,300 prompts over 31 days (6.3B tokens, ~$6K equivalent spend) and found only 5% led to commits or PRs — far below his expected 20–30%. The diagnosis: he was thinking in prompts when he should have been thinking in sessions.

The problem is context resets. Without a clear "exit contract" — a handoff file, a structured summary, a PR branch — the next session starts cold. Commenters on the analysis noted spending 20–30% of prompts re-explaining things that should be constants.

The fix is boring but effective: at the end of any session that produced something worth building on, tell Claude to write a progress.txt or a handoff note that captures the current state. The next session opens that file first. No re-explaining, no drift.

For product managers: Claude's Projects feature solves a version of this — drop your PRD templates, company context, and voice samples into Project Knowledge once, and every chat in that project starts grounded. PMs using this pattern report 3–5x improvement in output quality, because Claude already knows the situation.

The sharing problem nobody talks about

You write a prompt, Claude produces something good — a PRD, a spec, a one-pager, a competitive analysis — and then you need someone else to look at it. The default path is screenshots, copy-pasted text in Slack, or "I'll share my screen." None of these scale, and none let the reviewer point at the exact spot they want to change.

That loop — generate, share, collect feedback, iterate — is where most AI-assisted work actually stalls. The prompt is the easy part. The review is where things get stuck in Slack threads.