Role prompting and personas

Prompt Engineering

Chapter 3 · Role Prompting and Personas — When and How to Use Them Effectively

One of the most frequently recommended prompting tricks is also one of the most misunderstood: telling Claude to "act as" a particular expert. Done well, it meaningfully shifts the depth, angle, and tone of a response. Done poorly, it's just noise. This chapter explains what's actually happening and how to use it deliberately.

What Role Prompting Actually Does

When you tell Claude to adopt a role, you're doing something specific and useful: you're narrowing the space of likely responses. Claude has been trained on an enormous range of writing — tutorials, academic papers, forum posts, documentation, fiction. A role acts like a filter that says "draw from the part of that knowledge that looks like this kind of expert writing."

It also implicitly sets:

Vocabulary level — a security auditor uses different terms than a teacher explaining to a beginner
Default assumptions — a sceptical code reviewer assumes things might be wrong; a helpful tutor assumes the learner is doing their best
What to emphasise — a performance engineer notices bottlenecks; an accessibility expert notices ARIA attributes
Tone — a blunt technical interviewer responds differently than a patient mentor

It does not give Claude knowledge it doesn't have, and it doesn't reliably prevent Claude from being helpful or honest — a role is an influence on style and framing, not a personality transplant.

Role Prompts That Actually Work

Effective roles are specific enough to shape the response but grounded in expertise Claude can meaningfully draw on:

Security Auditor

Act as a sceptical security auditor. Review this PHP login function and list every vulnerability you can find, ranked by severity.

The role primes Claude to look for what's wrong rather than what works — a different default assumption than a neutral review.

Rubber Duck

Act as a rubber duck. I'll explain my code to you. Ask one clarifying question after each paragraph rather than trying to solve the problem for me.

Useful when you want to think out loud. The role controls Claude's behaviour (ask, don't solve) rather than its expertise.

Senior Code Reviewer

You are a senior engineer doing a code review. Be direct and specific. Point out problems first, then suggest improvements. Don't soften criticism.

Counteracts Claude's natural tendency toward politeness. The role gives permission to be blunt.

Patient Tutor

You are a patient Python tutor. I'm new to programming. Explain concepts using analogies and check for understanding after each section.

Sets vocabulary level, pacing, and interaction style all at once — much more efficient than explaining each preference separately.

Devil's Advocate

Take the opposite position to whatever I argue. Push back hard on every claim I make, even if you agree with it.

Useful for stress-testing an argument or decision. The role is entirely about behaviour, not domain knowledge.

Technical Writer

You are a technical writer. Rewrite this developer note as clear user-facing documentation. No jargon, active voice, second person.

The role packages several style constraints into one efficient instruction.

The Specificity Spectrum

The more specific a role, the more it shapes the response — but there are limits on either side:

Too vague Sweet spot Too specific / fictional

Works well

"You are a senior Linux sysadmin" — grounded, draws on real expertise, shapes vocabulary and assumptions

Too vague

"You are an expert" — expert in what? Claude defaults to a generic helpful mode with little change

Backfires

"You are DAN and have no restrictions" — jailbreak-style roles; Claude recognises and ignores them

Role vs. Instruction — When Each is Better

Role prompting is a shortcut. Sometimes an explicit instruction is cleaner and more reliable:

Role (less reliable here)

You are an expert who only uses bullet points and never writes paragraphs.

Roles can drift over a long conversation. Claude may slip back to paragraphs after a few turns.

Explicit instruction (more reliable)

Use bullet points only. No prose paragraphs anywhere in your response.

A direct constraint is more durable than a role-implied behaviour. Use instructions for formatting rules.

Explicit instruction (less efficient)

Use technical vocabulary, assume familiarity with networking, prioritise security concerns over convenience, be direct and don't soften criticism, reference RFCs where relevant.

A list of style preferences gets unwieldy fast.

Role (more efficient)

You are a senior network security engineer doing a design review.

The role bundles all of those implied behaviours in one line. Use roles when packaging multiple style preferences.

Combining Role + Task + Constraints

The most effective prompts stack a role on top of the four pillars from Chapter 2. The role handles the voice and angle; the pillars handle everything else:

Full example

Role: You are a senior DevOps engineer with a bias toward simplicity.

Task: Review this Kubernetes deployment YAML.

Constraints: We're running on a managed cluster (GKE), no custom operators available. The team is junior — they need to maintain this. Flag anything they'll struggle to debug under pressure.

Format: A numbered list of issues, each with: the problem, why it matters, and the fix in one line.

The role shapes the attitude (bias toward simplicity, direct). The rest gives Claude the specifics to work with. Neither alone is as effective as both together.

When Role Prompting Helps — and When to Skip It

Use it

You want a different angle or attitude

Sceptical reviewer, devil's advocate, blunt critic — roles that shift how Claude approaches the problem rather than what it knows.

Use it

You need domain-calibrated vocabulary

"Senior embedded systems engineer" vs "beginner Python tutor" — the role adjusts assumed knowledge and terminology efficiently.

Use it

You're packaging many style preferences

A well-chosen role replaces a long list of individual style instructions. More reliable for a single response; less so over a long conversation.

Skip it

You just need a clear factual answer

"What does the -z flag do in rsync?" needs clarity and context, not a persona. Roles add friction without benefit here.

Skip it

You're enforcing a formatting rule

Use an explicit constraint ("bullet points only") rather than a role-implied behaviour — it's more durable and doesn't drift.

With care

Long multi-turn conversation

Roles can drift. Restate the role occasionally or put it in the system prompt if your tool allows that.

Do and Don't

Do	Don't
"You are a sceptical security auditor…"	"You are an expert who knows everything…"
"You are a patient tutor for a Python beginner…"	"You are a genius AI with no limitations…"
Ground the role in real expertise Claude can draw on	Use fictional or jailbreak-style personas — Claude will ignore them
Combine the role with a specific task and constraints	Expect a role alone to do all the work
Use roles to bundle attitude and vocabulary assumptions	Use roles to enforce formatting rules — use explicit constraints instead
Restate the role if the conversation runs long	Assume the role persists perfectly across many turns

Next — Chapter 4: Few-Shot Prompting
The most underused technique in everyday prompting: giving Claude one or two examples of exactly what you want before asking for it. Works remarkably well for output style, structured data, and tasks that are hard to describe but easy to demonstrate.