Role Prompting
Assign an expert persona to get domain-specific answers — 3 real before/after examples for Claude, ChatGPT, and any LLM.
Generic vs Specific Roles — What Changes
| Role type | Example | Output quality | Why |
|---|
| No role | "Review this code" | Generic, surface-level | Model uses average expectations |
| Vague role | "You are an expert" | Slightly better | Model self-primes but lacks direction |
| Specific role ✓ | "You are a senior AppSec engineer with 10 years in Python…" | Domain-accurate, actionable | Model draws on a constrained knowledge frame |
Anatomy of an effective role:
You are a [seniority] [domain] [role title]
with [years] years of experience in [specific technology/context].
You [specialize in / have worked at / are known for] [specific focus area].
Add: communication style, skepticism level, or a constraint that creates useful friction ("You are skeptical of new dependencies").
Code Review — Security Engineer Role
Generic code review requests produce surface-level feedback. Assigning a security engineering role with specific context produces vulnerability-focused analysis with severity ratings and remediation steps.
Without role
Review this Python function for issues:
def get_user(user_id):
query = f"SELECT * FROM users WHERE id = {user_id}"
return db.execute(query)
With role prompt
You are a senior application security engineer with 10 years of experience in Python backend systems. You specialize in identifying OWASP Top 10 vulnerabilities and have reviewed code at scale at a Series B SaaS company.
Review this Python function for security vulnerabilities. For each issue: name the vulnerability class, explain the exploit scenario, and provide a fixed version.
def get_user(user_id):
query = f"SELECT * FROM users WHERE id = {user_id}"
return db.execute(query)
Difference: The role-assigned reviewer names "SQL Injection (CWE-89)", explains the exact attack ("attacker passes user_id=1 OR 1=1--"), gives severity (Critical), and provides a parameterized query fix. The generic reviewer says "watch out for SQL injection" without remediation.
Technical Writing — Principal Engineer Reviewer
Technical documentation gets better when reviewed by a simulated expert who knows what junior engineers get wrong. Assign a role with the perspective you're writing for, not the role you occupy.
Without role
Is this README clear? Is anything missing?
## Installation
Run: pip install mypackage
Then import and use.
With role prompt
You are a principal engineer who onboards new hires. You review documentation with the goal of ensuring a junior engineer can set up and use this library successfully without asking questions. You are skeptical, direct, and have seen too many vague READMEs that send new hires to Slack asking basic questions.
Review this README section. For each gap: explain what a new hire would be confused about, then write the missing content.
## Installation
Run: pip install mypackage
Then import and use.
Difference: The role-assigned reviewer flags: no Python version requirement, no virtual environment instructions, no "Then import and use" example, no link to API reference. The generic reviewer says "looks a bit short, maybe add more detail".
Decision Analysis — Devil's Advocate Role
When you want adversarial stress-testing of a proposal, assign a role that has a structural reason to disagree. This produces stronger objections than asking "what are the risks?".
Without role
What are the risks of migrating our monolith to microservices?
With role prompt
You are a senior engineering manager who has led two failed microservices migrations — one at a 200-person startup, one at a 5,000-person enterprise. You are now skeptical of microservices for any team under 200 engineers. You believe operational complexity is almost always underestimated.
Our team of 12 engineers is considering migrating our Rails monolith to microservices. Give me the 5 strongest reasons NOT to do this, with specific failure modes you have seen, not theoretical risks.
Difference: The adversarial role produces concrete failure modes: "distributed tracing takes 3 months to instrument properly", "service mesh latency kills your p99s", "on-call burden triples in the first quarter". The generic question produces: "complexity", "network overhead", "consistency challenges".
Role Prompting Best Practices
- Put the role in the system prompt — it persists across turns without consuming user tokens
- Specify seniority and context, not just title — "senior" and "at a fintech startup" changes output more than "software engineer" alone
- Use adversarial roles deliberately — "You are skeptical of this proposal" produces stronger objections than "what are the downsides?"
- Don't over-constrain — a role that's too narrow makes the model refuse to answer adjacent questions
- Combine with few-shot prompting — role sets the perspective; examples set the output format
- Let the optimizer choose the role — if you're unsure what role fits your task, paste your prompt into Prompt Improver and it will add an appropriate role automatically
→ Auto-add a role to my promptFrequently Asked Questions
- What is role prompting?
- Role prompting (also called persona prompting) is a technique where you instruct an LLM to adopt a specific expert identity before answering. For example: "You are a senior security engineer with 10 years of experience in penetration testing." This primes the model to draw on domain-specific knowledge, use appropriate vocabulary, and calibrate its confidence level to match the expertise of that role. Role prompting is most effective when the role is specific and the task is one the role would plausibly perform.
- Does role prompting actually work?
- Yes — role prompting consistently improves output quality for domain-specific tasks. Research and practitioner experience show that assigning a specific expert role increases factual accuracy on domain questions, improves technical vocabulary and precision, calibrates hedging (an "expert" is more likely to say "I don't know" than make something up), and shifts the tone to match professional contexts. The effect is strongest when the role is specific ("You are a Go compiler engineer specializing in escape analysis") rather than generic ("You are an expert").
- What is the difference between role prompting and system prompts?
- Role prompting is a technique — instructing the model to adopt an expert identity. A system prompt is a delivery mechanism — the invisible instruction block processed before the conversation. Role instructions work best in the system prompt because they persist across the entire conversation without consuming user-turn tokens. However, you can also include role context at the top of a user message if you don't have system prompt access (e.g., in ChatGPT's web UI).
- How specific should a role prompt be?
- "You are an expert" is too vague — every LLM already considers itself capable. Effective roles specify domain, experience level, context, and sometimes goals or constraints. Compare: weak ("You are an expert engineer") vs strong ("You are a staff-level backend engineer at a fintech company. You have 12 years of experience with Python and PostgreSQL. You are reviewing a junior engineer's code for a payment processing feature."). The specific version constrains the model's perspective and produces more targeted, actionable output.
- Can role prompting be used with Claude?
- Yes — Claude responds well to role prompts, especially when delivered via the system parameter in the Anthropic API. Claude's instruction-following makes it particularly reliable at maintaining a persona through a long conversation without role drift. Effective roles for Claude typically specify: domain expertise, experience level, communication style (direct, patient, skeptical), and any constraints on what the role would or wouldn't do.
Not sure which role fits your task?
Paste your draft prompt → Prompt Improver adds the right role, restructures the instruction, and explains every change. Free, BYO Anthropic API key.
→ Improve My PromptRelated Prompt Engineering Guides