Role and Context Framing: Telling Claude Who to Be
Two prompts can ask for the exact same task and still get very different answers, just because one tells Claude who it's supposed to be and the other doesn't.
//
Search across all documentation pages
Two prompts can ask for the exact same task and still get very different answers, just because one tells Claude who it's supposed to be and the other doesn't.
Role and context framing is the technique of assigning Claude a persona, an audience, or a situation before you state the actual request.
Done well, it compresses a paragraph of instructions about tone, vocabulary, and depth into a single sentence.
There are two related but distinct kinds of framing worth telling apart.
Role framing assigns Claude a persona: "You are a senior security engineer," "You are a patient kindergarten teacher," "You are a blunt, no-nonsense editor."
Context framing describes the situation or audience instead: "I'm a complete beginner," "This is for a board of directors," "I'm debugging a production outage right now."
Both work by the same underlying mechanism described elsewhere in this section: they narrow the space of reasonable responses before Claude starts generating.
A role like "senior security engineer" implies a vocabulary, a level of caution, and a set of priorities that a bare question would leave undefined.
Context like "this is for a board of directors" implies a formality level and a bias toward high-level takeaways over technical detail, again without you having to spell either one out explicitly.
No framing: "Explain rate limiting."
Role framing: "You are a backend engineer explaining rate
limiting to a new hire who has never worked with APIs before."The second prompt doesn't just add words, it resolves two real questions at once: how technical to be, and what the reader already knows.
Framing works only to the extent that it carries a checkable behavioral implication, not because naming a role is inherently powerful.
"You are a world-class expert" sets almost no real constraint, since it doesn't tell Claude anything about vocabulary, structure, or priorities that it could actually apply.
"You are a technical writer who avoids jargon and always defines acronyms on first use" sets three constraints Claude can directly act on: avoid jargon, define acronyms, first-use only.
This is the same distinction covered on the specificity page in this section, applied specifically to personas: a role is a compressed bundle of specifics, and it's only useful in proportion to how many real specifics it actually bundles.
Context framing interacts with this in a complementary way, by supplying information about the reader rather than the writer.
Telling Claude "I'm a first-time founder" changes what counts as an appropriate level of explanation for a legal or financial topic, the same way telling it "I already have a CS degree" changes it in the other direction.
Framing also stacks with other techniques rather than replacing them: a role sets the voice, while a format instruction still needs to set the structure, and a length constraint still needs to set the size.
One common failure mode is framing that conflicts with the actual task: asking Claude to be "a blunt, no-nonsense reviewer" and then reacting badly to blunt feedback is a mismatch between the frame you set and the response you actually wanted, not a sign that framing doesn't work.
Another is stacking too many roles or contexts at once, "you are a doctor, lawyer, and financial advisor," which usually produces a diluted, generic voice instead of three sharp ones, because the constraints from each role can pull in different directions.
Role framing is most valuable when a task is repeated often enough that a consistent voice matters, such as customer support replies, code review comments, or a recurring newsletter section.
In those cases, teams often settle on a short, reusable role description, refined over a few iterations, rather than reinventing the framing every time.
Context framing tends to matter most for anything audience-sensitive: technical depth, formality, and assumed background knowledge are the three dimensions it most reliably controls.
It's worth being honest about where framing does not help: it does not make Claude more factually accurate about specialized domains, and it does not substitute for giving Claude the actual facts, data, or documents a task needs.
A role like "you are a doctor" changes tone and structure, it does not grant real medical training, and content built on that framing should still be treated with the same scrutiny as any other Claude output.
| Framing type | Strength | Weakness | Best Fit |
|---|---|---|---|
| Role framing ("you are a...") | Sets vocabulary, priorities, and structure in one phrase | Only as strong as the concrete behaviors it implies | Repeated tasks needing a consistent voice |
| Context framing ("I'm a...", "this is for...") | Calibrates depth and formality to the actual reader | Requires you to know your audience accurately | Audience-sensitive explanations |
| Combined role + context | Covers both writer voice and reader calibration | More to write per prompt | High-stakes or recurring communications |
| No framing | Fastest to write | Claude defaults to a generic, middle-of-the-road register | Quick, low-stakes, single-use questions |
Not directly, an expert role mainly shapes tone, vocabulary, and structure.
For specialized or high-stakes facts, you still need to verify the content yourself or supply the actual source material Claude should rely on.
The role you named may not have implied any concrete, checkable behavior, such as a vocabulary choice, priority, or structural habit.
A role like "you are amazing at this" carries no actionable constraint; a role like "you are a copy editor who cuts every sentence over 20 words" does.
You can, but competing roles often dilute into a single, generic voice rather than layering cleanly.
It's usually more effective to pick the one role most relevant to the current task.
Yes, describing your own situation or audience ("I'm new to this," "this is for executives") works on its own and is often enough by itself.
Role and context framing are independent techniques that happen to combine well.
Specific enough to imply real behavior: a job title alone is weaker than a job title plus a habit or priority, such as "a technical writer who avoids jargon."
The more checkable behaviors a role implies, the more it actually shapes the response.
The underlying mechanism, narrowing tone and structure based on the assigned role, is consistent across the current lineup.
More capable models may apply a role's implications more consistently across a long response, but the basic effect holds throughout.
Usually not, since Claude keeps the role active as part of the ongoing conversation context.
Re-state it only if the conversation has drifted far enough that the original framing might no longer feel active, or if you're starting a new conversation.
Yes, stating your own background level ("I have never coded before") is one of the most reliable ways to get an appropriately simplified explanation.
It works better than asking generically for something "simple," because it gives Claude an actual calibration point.
"You are the best writer in the world" sets no checkable behavior, it's a compliment, not a constraint.
Replacing it with a concrete habit, such as "you write in short, punchy sentences," gives Claude something it can actually act on.
No, a role mainly shapes voice and depth.
Structure and length are separate decisions that still need to be stated explicitly if they matter to you.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.
Reviewed by Chris St. John·Last updated Jul 19, 2026