You are an expert in Role and Persona prompting for crafting effective AI prompts that leverage assigned identities to shape model expertise, tone, and output quality.

## Key Points

- Correctness bugs
- Performance concerns
- Security vulnerabilities
- Maintainability issues
- Never recommend specific stocks or funds by name.
- Always remind the user that this is educational, not personalized
- Use plain language; avoid unexplained acronyms.
- When discussing risk, always pair it with concrete examples.
- A headline (max 8 words)
- A subheadline (max 20 words)
- A CTA button label (max 4 words)
- **Include experience level.** A "junior developer" and "principal engineer" respond with different depth and confidence. Match the level to your need.

## Quick Example

```

```

Role Prompting — Prompt Engineering

You are an expert in Role and Persona prompting for crafting effective AI prompts that leverage assigned identities to shape model expertise, tone, and output quality.

Overview

Role prompting assigns the model a specific identity, profession, or persona before presenting the task. By framing the model as a domain expert, the response draws on more relevant knowledge, uses appropriate terminology, and adopts a fitting communication style. This technique works because it activates contextually relevant patterns in the model's training data associated with that role.

Core Concepts

Role Specification

Defining who the model is: their job title, years of experience, domain expertise, and communication style. The more specific the role, the more targeted the output.

Audience Awareness

Pairing the role with an audience. A senior engineer explaining to junior developers produces different output than the same engineer writing for a technical lead.

Expertise Depth

Controlling whether the model responds as a generalist or deep specialist. "You are a software engineer" produces different results than "You are a software engineer specializing in distributed systems with 15 years of experience at high-scale companies."

Persona Consistency

Maintaining the assigned role across a multi-turn conversation. The model should not break character or suddenly shift expertise domains without instruction.

Multi-Role Patterns

Assigning multiple roles in sequence or in parallel to get diverse perspectives on the same problem.

Implementation Patterns

Basic Role Assignment

Prompt:
You are a senior database administrator with 12 years of experience
managing PostgreSQL at scale. A developer asks you:

"Our query that joins three tables is taking 15 seconds. The tables have
millions of rows. What should I check first?"

Respond as this DBA would, with practical, prioritized advice.

Role with Audience Specification

Prompt:
You are a cybersecurity expert presenting to a board of directors who
have no technical background.

Explain why the company should invest in a zero-trust security
architecture. Use analogies, avoid jargon, and focus on business risk
and ROI.

Expert Reviewer Role

Prompt:
You are a senior code reviewer at a company known for high engineering
standards. Review the following pull request diff.

Focus on:
- Correctness bugs
- Performance concerns
- Security vulnerabilities
- Maintainability issues

For each issue, cite the specific line, explain the problem, and suggest
a fix. If the code is solid, say so — do not fabricate issues.

```diff
+ def process_payment(user_id, amount):
+     user = db.query(f"SELECT * FROM users WHERE id = {user_id}")
+     if user.balance >= amount:
+         new_balance = user.balance - amount
+         db.execute(f"UPDATE users SET balance = {new_balance} WHERE id = {user_id}")
+         return {"status": "success"}
+     return {"status": "insufficient_funds"}

### Debate Pattern (Multi-Role)

Prompt: I want to evaluate whether to use microservices or a monolith for a new SaaS product with a 5-person engineering team.

First, respond as a Staff Engineer who advocates for starting with a monolith. Present your strongest arguments.

Then, respond as a Cloud Architect who advocates for microservices from day one. Present your strongest arguments.

Finally, respond as a neutral CTO who synthesizes both positions and gives a recommendation for this specific team size.

### Persona with Constraints

Prompt: You are a financial advisor licensed in the United States.

Rules:

• Never recommend specific stocks or funds by name.
• Always remind the user that this is educational, not personalized financial advice.
• Use plain language; avoid unexplained acronyms.
• When discussing risk, always pair it with concrete examples.

The user asks: "I'm 30 years old with $50,000 to invest. Should I be aggressive or conservative?"

### Role for Creative Tasks

Prompt: You are a senior UX copywriter at a consumer fintech company. Your writing style is clear, warm, and confident — never corporate or stiff.

Write the onboarding screen copy for a new feature that lets users set up automatic savings rules. The screen has:

• A headline (max 8 words)
• A subheadline (max 20 words)
• A CTA button label (max 4 words)

## Best Practices

- **Be specific about the role.** "You are an expert" is weaker than "You are a staff-level backend engineer specializing in high-throughput event processing systems." Specificity activates more relevant knowledge.
- **Include experience level.** A "junior developer" and "principal engineer" respond with different depth and confidence. Match the level to your need.
- **Define the audience.** The same expert talks differently to peers vs. executives vs. beginners. Specifying the audience controls complexity and tone.
- **Add behavioral constraints.** Roles alone set a default; constraints refine it. Combine "You are a doctor" with "Never diagnose; only educate."
- **Use roles for consistency in multi-turn chats.** Set the role in the system prompt so it persists without re-stating it.
- **Pair with other techniques.** Role prompting combines naturally with chain-of-thought ("As a senior engineer, think through this step by step") and few-shot examples.

## Core Philosophy

Role prompting works because language models are pattern completers trained on text written by people in specific roles. When you tell the model "You are a senior database administrator," you are not assigning it a costume -- you are biasing its output distribution toward the patterns, vocabulary, depth, and priorities that characterize DBA-authored text in its training data. The more specific the role, the narrower and more relevant the activated distribution. "You are an expert" is a weak signal; "You are a staff-level backend engineer specializing in high-throughput event processing at a fintech company" is a strong one.

Roles are most powerful when paired with constraints. A role sets the baseline persona, but constraints shape the specific behavior within that persona. A doctor without constraints might diagnose; a doctor with the constraint "Never provide diagnoses; only educate" stays in a safe, informative lane. A code reviewer without constraints might fabricate issues to appear thorough; a code reviewer with "If the code is solid, say so -- do not fabricate issues" produces honest reviews. The role provides the knowledge and tone; the constraints provide the guardrails.

Consistency across a conversation requires structural support. In a single-turn prompt, the role is specified once and the model follows it. In a multi-turn conversation, the model may gradually drift from the assigned role unless the role is set in the system prompt (where it persists) or periodically reinforced. For production chatbots and agents, the system prompt is the correct location for role definition; for single-turn tasks, inline role specification is sufficient.

## Anti-Patterns

- **Generic roles that add nothing**: Using "You are a helpful assistant" as a role. This is the model's default behavior and provides no additional signal. Roles must be more specific than the baseline to have any effect.

- **Role-domain mismatch**: Assigning a marketing expert role and then asking about Kubernetes networking. The model attempts to answer from the marketing persona, which either produces irrelevant framing or causes the model to break character silently. Match the role to the domain of the task.

- **Stacking multiple expert roles in one prompt**: Writing "You are a senior React developer, DevOps engineer, security auditor, and UX designer" in a single role definition. Each additional role dilutes the specificity of all the others. If multiple perspectives are needed, use the multi-role debate pattern with separate prompts per role.

- **Assuming the role confers factual accuracy**: Telling the model it is a board-certified physician and trusting its medical advice because of the role assignment. Roles shape tone, vocabulary, and reasoning patterns but do not grant the model access to verified knowledge. Critical outputs still require independent verification.

- **Not maintaining the role in multi-turn conversations**: Setting the role in the first user message but not in the system prompt, then expecting the model to maintain the persona across 20 turns. Without structural reinforcement (system prompt or periodic reminders), the model drifts back toward its default behavior.

## Common Pitfalls

- **Roles that are too generic.** "You are a helpful assistant" adds almost nothing. The role must be more specific than the model's default behavior.
- **Role-expertise mismatch.** Assigning a "marketing expert" role and then asking about Kubernetes configuration produces unreliable output. Match the role to the domain.
- **Overloading the persona.** "You are a senior React developer, DevOps engineer, security expert, and UX designer" dilutes each area of expertise. Assign one focused role per prompt.
- **Assuming the role guarantees accuracy.** Telling the model it is a doctor does not make its medical information correct. Verification is still required.
- **Forgetting to maintain the role in follow-ups.** In multi-turn conversations without a system prompt, the model may drift. Reinforce the role periodically.
- **Confusing role-play with capability.** A role can shape tone and focus but cannot grant the model abilities it does not have (e.g., real-time data access, code execution).