# Role Prompting

Course: [Prompt Engineering](https://www.devtutorials.ai/learn/prompt-engineering) · Section: Core Prompting Techniques
Source: https://www.devtutorials.ai/learn/prompt-engineering/core-techniques/role-prompting

> Set who the model is and who it writes for: roles, system prompts, personas, audience prompting, checking reading level and rules in code, and the limits of roles.

Ask a doctor, a primary school teacher, and a comic writer "What is a fever?" You get three very different answers. The facts are the same, but the words, the amount of detail, and the tone change with the person.

You can get the same effect from a model by giving it a **role**. "You are a patient teacher for 10-year-olds" changes the words, the length, and the tone of every reply. This is called **role prompting**.

**The main idea:** a role tells the model **how** to answer: what voice to use, how much detail to give, and who the reader is. It does not give the model any new knowledge.

## A Real-World Example

Think about a call centre. Before their shift, every agent gets a short script:

- "You work for Brightgrid support."
- "Be friendly and keep it short."
- "Never promise a refund. Send refund questions to the billing team."

The script doesn't change what the agent knows. It changes how they talk, and what they will and won't do. A **system prompt** is a script like this for a model.

## What You Will Learn

In this lesson, you will learn:

1. What a role and a system prompt are.
2. How to write a role that says who, for whom, what tone, and what rules.
3. How naming the reader changes the level of a reply.
4. How to check a reply's reading level and rules with code.
5. What a role can do, and what it can't do.
6. Where roles go: in the system prompt or in the user message.

The **Chat** tab in the Prompt sandbox has a System box at the top. Change it, and send the same question again, to see a role at work. The code boxes run plain JavaScript without a model.

## Roles and System Prompts

A **role** is a short description of who the model should act as. It usually goes in the **system prompt**. This is the first message the model reads, before any message from the user.

A role can describe:

- **A job.** "You are a senior JavaScript reviewer."
- **A character.** "You are Max, a cheerful guide for a cooking app."
- **A reader.** "Explain things to a 10-year-old."
- **Rules.** "Answer in under 80 words. Never give medical advice."

Try a role. Send the question. Then change the system prompt to "You are a doctor writing for other doctors." and send it again.

## Write a Role in Four Parts

A strong system prompt answers four questions:

1. **Who** is the model? Its job or character.
2. **Who is it writing for?** The reader.
3. **How should it sound?** The tone and the length.
4. **What are the rules?** What it must always do, or never do.

The next box builds a system prompt from these four parts.

```js runnable title="Build a system prompt from four parts"
function makeRole(r) {
  const lines = ["You are " + r.who + ".", "You write for " + r.audience + ".", "Tone: " + r.tone + "."];
  r.rules.forEach((rule) => lines.push("- " + rule));
  return lines.join("\n");
}

const role = makeRole({
  who: "a support agent for Brightgrid, a data grid for web apps",
  audience: "developers who use Brightgrid",
  tone: "friendly and brief, under 80 words",
  rules: ["Answer only questions about Brightgrid.", "Send refund questions to billing@example.com."],
});

console.log(role);
```

Expected output:

```text
You are a support agent for Brightgrid, a data grid for web apps.
You write for developers who use Brightgrid.
Tone: friendly and brief, under 80 words.
- Answer only questions about Brightgrid.
- Send refund questions to billing@example.com.
```

It is easier for the model to follow rules in a short list than rules hidden inside a long paragraph.

**Easy Way to Remember:** a good role answers four questions: **Who am I? Who am I talking to? How do I sound? What are my rules?**

## Audience Prompting

Sometimes you don't need a job title at all. You just need to say who the reader is. This is called **audience prompting**, and it is one of the most useful parts of a role.

```js runnable title="One question, three audiences"
const audiences = {
  child: "Explain to a 10-year-old. Use short sentences and one everyday example.",
  beginner: "Explain to a new developer. Define any technical word you use.",
  expert: "Explain to a senior engineer. Be precise and skip the basics.",
};

const question = "What is an API?";
for (const name in audiences) {
  console.log("[" + name + "] " + audiences[name] + " Question: " + question);
}
```

Expected output:

```text
[child] Explain to a 10-year-old. Use short sentences and one everyday example. Question: What is an API?
[beginner] Explain to a new developer. Define any technical word you use. Question: What is an API?
[expert] Explain to a senior engineer. Be precise and skip the basics. Question: What is an API?
```

Compare two different readers with the real model:

## Check the Reading Level

How can you test that a reply really suits a 10-year-old? One simple sign is the **average sentence length**. Shorter sentences are usually easier to read. The next box measures this for two sample replies written for this example.

```js runnable title="Measure the average sentence length"
function avgWords(text) {
  const sentences = text.split(/[.!?]+/).map((s) => s.trim()).filter(Boolean);
  const words = text.split(/\s+/).filter(Boolean).length;
  return Math.round((words / sentences.length) * 10) / 10;
}

const forChild = "An API is like a waiter. You ask for food. The waiter brings it from the kitchen.";
const forExpert = "An API is a contract that defines the requests a client may send to a service and the responses it can expect, usually over HTTP.";

console.log("For a child:", avgWords(forChild), "words per sentence");
console.log("For an expert:", avgWords(forExpert), "words per sentence");
```

Expected output:

```text
For a child: 5.7 words per sentence
For an expert: 25 words per sentence
```

For a child, aim for short sentences of fewer than about 12 words. You can add a check like this to your tests.

## Check the Rules

Rules in a system prompt are instructions, not promises. Small models break them more often. So turn each rule into a check, and test the replies.

```js runnable title="Turn role rules into checks"
const checks = [
  { rule: "under 80 words", test: (r) => r.split(/\s+/).length < 80 },
  { rule: "no refund promise", test: (r) => !/we will refund|you will get a refund/i.test(r) },
  { rule: "mentions billing for refunds", test: (r) => !/refund/i.test(r) || /billing/i.test(r) },
];

const reply = "Sorry about that! You will get a refund within 3 days.";
checks.forEach((c) => console.log(c.test(reply) ? "pass" : "FAIL", "-", c.rule));
```

Expected output:

```text
pass - under 80 words
FAIL - no refund promise
FAIL - mentions billing for refunds
```

This sample reply breaks two rules. If the real model does this in your tests, make the rule stronger, put it at the end of the system prompt, or add an example of the right answer.

## What a Role Cannot Do

A role changes the style, the amount of detail, and the focus. It does **not**:

- **Add knowledge.** "You are an expert tax lawyer" does not teach the model tax law. It only makes the model sound like a lawyer, and that can make wrong answers more convincing.
- **Make the model safe.** A user can still ask the model to ignore its role. Don't depend on a system prompt to protect secrets.
- **Replace a clear task.** "You are a world-class marketer" without a task still gets an unclear reply.

Never ask a model to pretend to be a real, named person. Never use a role to make advice look more official than it is. For medical, legal, or money questions, a role does not make the answer safe to follow.

## System Prompt or User Message?

You can put a role in either place:

| Where | Best for | Example |
|---|---|---|
| System prompt | Rules and style for the **whole chat** | The support assistant in an app |
| User message | A role for **just one task** | "As a code reviewer, check this function." |

The next box shows both ways, as the messages the model receives.

```js runnable title="A role in the system prompt or in the user message"
const inSystem = [
  { role: "system", content: "You are a strict code reviewer." },
  { role: "user", content: "Review: let x = 1" },
];
const inUser = [
  { role: "user", content: "As a strict code reviewer, review: let x = 1" },
];

console.log("System way:", inSystem.length, "messages, role applies to every turn");
console.log("User way:", inUser.length, "message, role applies to this turn");
```

Expected output:

```text
System way: 2 messages, role applies to every turn
User way: 1 message, role applies to this turn
```

## Common mistakes

| Mistake | Wrong idea | Correct idea | What goes wrong |
|---|---|---|---|
| Using an expert role to get facts | "You are an expert" makes the answers correct. | A role changes the style, not the knowledge. Give the facts as context. | Wrong answers sound more sure. |
| A role with no task | "You are a great writer" is enough. | Add the task, the reader, and the format. | You get an unclear reply in a fancy voice. |
| Rules in a long paragraph | "The model will find the rules." | List the rules as short bullet points. | The model misses some rules. |
| No reader named | "The model will choose the right level." | Name the reader: a child, a beginner, or an expert. | Replies are too hard or too simple. |
| Trusting the system prompt | "It's in the system prompt, so it always works." | Test the rules with code checks. | Rules get broken, and nobody notices. |
| Using the system prompt for security | "Users can't see or change the system prompt." | Users can try to get around it. Keep secrets out of it. | Hidden instructions or data get leaked. |

## Exercises

In each exercise, the last line should give back a value. Press **Check** to compare your value with the expected answer.

## What to Remember

- A **role** tells the model who to act as. It usually goes in the **system prompt**.
- A good role says **who**, **for whom**, **what tone**, and **what rules**.
- **Audience prompting** sets the level of a reply by naming the reader.
- Check the reading level and the rules **with code**. Rules are not promises.
- A role changes the **style, not the knowledge**, and it does **not keep things secure**.
- Use the **system prompt** for the whole chat, and the **user message** for just one task.

Next: **Delimited and Template Prompting**, where you keep instructions separate from data and build prompts you can use again.