1. Give It a Role and a Reason

You finished the Super Beginner course, so you can already get useful work out of AI. This track is about getting reliable work out of it: the same quality every time, on jobs that matter, without babysitting each answer.

We are starting with the technique that gave us the biggest measurable difference of anything we tested for this course, and it is one line long.

The same document, reviewed twice

We took a paragraph from a company handbook, the kind nobody reads until there is an argument about it:

Employees are expected to submit expense reports within a reasonable timeframe following the conclusion of business travel. Reports submitted outside of this window may be subject to review by the finance team and could potentially result in delayed reimbursement.

First we asked the obvious way: "Review this paragraph from our company handbook and tell me what to change."

It came back with 134 words of writing advice. Cut the vague phrase. Use active voice. Move the consequence up. It offered a rewrite and signed off with "half the words, twice the clarity". All of that is correct and none of it is what the paragraph's actual problem is.

Then we ran it again with one sentence in front:

You are an employment lawyer reviewing a company handbook
for ambiguity that could cause a dispute. You are not
editing for style.

Review this paragraph and tell me what to change.

235 words came back, and they were about different things entirely. It flagged that "may be subject to review" does not say whether review is standard for every report or triggered only by lateness, which changes whether the sentence is a warning or a description. It flagged that "could potentially result in delayed reimbursement" never says whether you can be denied reimbursement or only delayed, and called that the biggest liability in the paragraph.

Why this works when it does

"Review this" is one of the vaguest instructions in English. Review it for what? Grammar, tone, accuracy, legal exposure, whether it matches your brand, whether it is too long? The model has to pick, and it picks the most common interpretation, which is copy editing.

A role collapses that ambiguity in about eight words. It is not roleplay and you are not pretending. You are naming the lens.

Which is why the useful roles are specific about a job, not a personality:

Weak	Does actual work
You are a helpful assistant	You are a copy editor checking for claims we cannot support
You are an expert writer	You are the customer receiving this, looking for a reason to say no
Act as a professional	You are an accountant checking whether these categories will survive an audit
You are a genius programmer	You are reviewing this for the failure that happens at 3am, not for style

Every one on the right names a thing to look for. Every one on the left is flattery, and flattery does nothing because the model was already trying its best.

The second half: give it the reason

Roles set the lens. Reasons set the boundaries, and they generalize in a way rules do not.

Anthropic's own prompting guidance uses an example worth stealing. "Never use ellipses" is a rule. "This will be read aloud by a text to speech engine, so never use ellipses, because it will not know how to pronounce them" is a reason. The second one also gets you out of em dashes, asterisks, and the emoji you forgot to ban, because the model now understands what you are protecting against instead of following one instruction literally.

So the pattern for anything with a constraint on it:

[who you are, in terms of what to look for]

[the task]

[the constraint, and why it exists]

Worked example, for a job most people have:

You are reviewing this job description for anything that
would put off a strong candidate who is currently employed
and not actively looking.

[paste the job description]

Keep it under 400 words, because we know from our own
analytics that people stop reading past that on mobile,
and most of our applicants are on mobile.

That last clause does more than "keep it short". It tells the model what it is optimizing for, so when it has to choose what to cut, it cuts what a phone reader would skip rather than whatever happens to be at the end.

Roles that are actually worth saving

After a few weeks you stop inventing these each time and start reusing five or six. Ours, with the job each one does:

The adversarial reader. The highest value role there is, and the one people reach for last.

You are the person receiving this and you are looking for
a reason to say no. What would you push back on, and what
is unclear or missing?

This works because "is this good?" is a leading question that reliably gets you a yes. Handing it a reason to object gets you the objection instead.

The person who has to do the work.

You are the engineer who will be handed this ticket on
Monday with no chance to ask questions. What is missing
that would stop you starting?

The one checking a specific kind of failure.

You are checking this for claims we cannot support with
a source. Ignore style. List every sentence that asserts
something we would have to back up.

The outsider.

You have never heard of our product. Read this page and
tell me what you think we sell, then tell me which sentence
made you think it.

That last one is unusually good on marketing copy, because the second half makes the answer checkable. You find out not just that the message landed wrong but which line did it.

Stacking a role with a reason

The two techniques compound, and this is where the lesson pays off on real work. Here is a prompt using both, on a job that genuinely goes wrong without them:

You are a support engineer reading this bug report cold at
the start of your shift. You cannot contact the reporter.

<report>
[paste the bug report]
</report>

List what you would need before you could reproduce this,
in priority order. Be specific about what is missing rather
than describing it generally.

I am going to send your list straight back to the customer,
so phrase each item as a question they can answer without
knowing anything about our codebase.

The role decides what counts as missing. The reason at the end decides how the list is worded. Drop either and you get something you have to rewrite: without the role, a generic quality review of the report; without the reason, a list full of internal jargon you cannot send to anyone.

When a role does nothing

Being honest about the limits, because a technique you apply everywhere stops being a technique:

• When the task is already unambiguous. "Convert this list to a CSV" does not need a persona. There is one way to do it.
• When you are asking for facts. A role will not make it more accurate. Telling it that it is a doctor does not give it medical knowledge it did not have, and it may make you trust the answer more than you should, which is worse than no role at all.
• When the role is a personality. "You are a witty writer" mostly produces the model's idea of wit, which is the average of everyone's idea of wit.

Try it on something real

Take a document you already own. A contract, a job posting, a landing page, a policy, an email you are about to send to someone who matters.

1. Ask it to "review this" with no role. Read what it gives you.
2. Now ask again with a role that names the specific failure you are actually worried about. Not "review this contract" but "you are looking for the clauses that cost me money if the relationship goes badly".
3. Compare the two lists. If they are the same, your task was already unambiguous and you did not need a role. If they are different, the second list is the one you wanted.

Our two lists overlapped on exactly one point, the vague phrase. Everything else was different.

Next

Lesson 2 is about the other half of a good prompt: keeping your instructions and your material from bleeding into each other. We tested the standard advice on that one and got a result we did not expect.