Role & Persona Prompting
Use a persona to set the depth, perspective, and priorities of an answer, and know when it helps versus when it is just noise.
TL;DR
- A persona sets the perspective, depth, and priorities of the answer, not magic correctness.
- It helps most for reviews, trade-off discussions, and matching an audience or tone.
- Make it concrete: name the priorities you want, not just the job title.
What A Persona Does
Sets DepthIt signals how detailed and rigorous the answer should be.
"Explain to a junior dev"
vs "Explain to a staff engineer"Sets PrioritiesIt tells the model which concerns to weigh first.
"A security reviewer" -> flags auth,
input handling, secrets first.Sets ToneIt shapes voice and audience for explanations and docs.
"Write the README as a friendly
onboarding guide."Make It Concrete
Name The LensAttach the specific thing the persona should optimize for.
"You are a performance engineer.
Focus on allocations and Big-O."Name The AudienceSay who the output is for so depth and jargon fit.
"Explain this regex to someone who
has never used regex."Name The BarState the quality standard you expect the persona to hold.
"Review as if this is going to
production on Friday."Good Fits
Code ReviewPersonas focus a review on the risks you care about.
"Senior reviewer: correctness,
edge cases, then readability."Trade-Off TalksA persona frames which criteria win when options compete.
"As an SRE, which option is easier
to operate and debug at 3am?"TeachingAudience personas tune explanations to the right level.
"Mentor a bootcamp grad through this."Weak Uses
Empty FlatteryGeneric expert claims change little without named priorities.
"You are a 10x genius engineer"
-> negligible effectKnowledge GapsA title cannot supply facts the model does not have.
Persona != real API knowledge.TheaterElaborate role-play wastes context better spent on the spec.
Keep it to one concrete line.Tips
- Pair a persona with what it should optimize for: 'a security reviewer focused on injection and auth'.
- Put a durable persona in the system prompt or project rules so you do not repeat it every turn.
Warnings
- A persona does not add knowledge the model lacks; it will not make invented APIs real.
- Vague personas ('act as an expert') change little; the priorities you name do the real work.
In Practice
The same code-review request with and without a concrete persona. The persona version produces a focused, prioritized review instead of a generic pass.
- Without a persona the review is broad and unprioritized.
- The persona names the lens: security, with the specific risks to hunt for.
- It sets the output shape so findings are ranked and actionable.
- Depth and tone now match a serious pre-production review.
# WITHOUT
Review this login handler.
# WITH A CONCRETE PERSONA
You are a security-focused senior engineer
reviewing a login handler before production.
Prioritize, in order:
1. auth and session handling
2. injection and input validation
3. secret and error leakage
List findings ranked by severity, each with the
line, the risk, and a concrete fix. Ignore style.
<paste the handler>FAQ
On its own, modestly. It nudges the model toward more careful, idiomatic output. The real gain comes from naming what that engineer cares about, such as correctness, types, edge cases, or readability, which focuses the response.
For perspective-shaped tasks: code review (name the lens), explaining to a specific audience, weighing trade-offs, or matching a tone. For a plain 'write this function' task, a precise spec matters far more than a persona.
If it applies to the whole session, put it in the system prompt or your project rules file so it persists. If it is one-off, state it inline. Repeating it every message wastes effort and context.
Yes, if it is irrelevant or overly theatrical. Elaborate role-play burns context and can distract from the task. Keep personas short and tied to concrete priorities.