Write a Role Prompt That Doesn't Overreach
"Act as a lawyer" makes AI answer with authority it doesn't have — a verdict or a diagnosis from partial context. Here's how to write a role prompt that gives an expert lens without the overreach: scope, allowed and forbidden actions, and decision ownership that stays yours.
Build a Role Prompt With BoundariesWhen "act as an expert" answers like one it isn't
You type "Act as a lawyer and tell me if this contract is safe to sign," or "You are my CTO — tell me what architecture to use," or "Act as a doctor and tell me what's wrong." The answer comes back fluent and sure: it pronounces the contract fine, picks the architecture, names the diagnosis. It reads like a verdict from someone qualified to give one. But nothing in the prompt made the model qualified — it made the model *sound* qualified. It reached a conclusion from whatever partial context you happened to paste, in the voice of a profession it is only impersonating, and quietly took a decision that was yours to make.
That gap — between the authority a role implies and the authority the model actually has — is what this guide closes. An AI role prompt is genuinely useful: naming a role gives the model a perspective to reason from, a set of priorities, and a house style for its answer. But a role on its own is a title, not a boundary, and the model will read the title as a license. A role prompt that doesn't overreach adds the missing half: what the role may do, what it may not, how to behave when the context is thin, and who still owns the decision. NewPrompt builds that role prompt for you — the Role Prompt Generator gives the role real reasoning instead of a bare "act as" line — and it is honest about the limit: it doesn't make the model a lawyer, run the model, or approve anything. You paste the prompt into your own AI tool, and what comes back is a bounded analysis to check, not a professional's judgment. The boundaries lower the risk of overreach; they don't remove it, which is exactly why you stay the decision owner.
Why "act as X" invites overreach
A bare role is a costume with no script. "Act as a lawyer" tells the model who to sound like and nothing about where to stop, so it fills the silence with the most authoritative-sounding answer it can produce. Two things go wrong at once — the model overreaches, and you are primed to believe it:
- The model reads the role as authority. "You are a senior architect" becomes permission to decide, so it hands you one answer instead of the trade-offs a real architect would lay out first.
- It answers from missing context as if it were complete. No jurisdiction, no full contract, no patient history — and it concludes anyway, because nothing told it that a missing piece changes the answer.
- It borrows the profession's certainty. A role cast as "doctor" or "lawyer" adopts the confident register of one, and confident phrasing reads as competence whether or not it is earned.
- You read the fluency as expertise. A well-worded answer in an expert's voice is easy to take at face value — the role convinces the reader as much as it steers the model.
- Role and task blur together. "Be a lawyer and tell me if this is safe" fuses who the model is with what you want, so the actual scope of the job never gets stated.
- Nobody names who decides. The prompt asks for a verdict, the model gives one, and the fact that the real decision — and its consequences — belong to you drops out of the exchange.
Step 1: Split the role from the task, and state the scope
Three things hide inside "act as a lawyer and tell me if this is safe": a role (the perspective), a task (the specific job), and a scope (what is in bounds and what isn't). Pull them apart. The role is the lens — "a contract risk reviewer." The task is the concrete ask — "point out clauses a freelancer should question before signing." The scope draws the fence — "look at payment, termination, and IP terms in the excerpt; don't rule on whether it is legally binding." Once the three are separate, the boundaries have somewhere to attach; while they stay fused, every limit you add lands as an afterthought.
The Role Prompt Generator builds the role half with real substance — the perspective a role reasons from, the responsibilities it owns, the criteria it weighs — instead of a name the model just wears. That gives you a role that thinks in character; the scope and the limits are the part you add on top, and the rest of these steps is how. One useful default it already carries: a generated role is told to say when a request falls outside its expertise rather than improvise an answer — a small boundary, but the right instinct to build on.
Step 2: Trade "act as X" for "use the perspective of X"
The wording of the role sets the ceiling on how far it reaches. "Act as a lawyer" casts the model as the authority; "use the perspective of a contract risk reviewer to flag what a freelancer should ask about" casts it as a lens pointed at a bounded job. The second version is not asked to approve the contract — its job is to surface questions, not to pass a verdict, so approval sits outside what you assigned. Pick a role name that describes a function you actually want, not a credential you can't confer: "contract risk reviewer," not "lawyer"; "architecture options analyst," not "CTO"; "symptom-information organizer," not "doctor." The renaming is not cosmetic — a reviewer flags and counsel rules, and the model follows the noun you give it.
This is where the high-authority roles need the most care. You can still borrow a CTO's or a lawyer's way of seeing — their priorities, the risks they would notice first — without handing the model their seat. The Startup Advisor Role Prompt is a worked example of the line held well: it reasons like an experienced advisor and stays opinionated, but it is explicit that legal, tax, and securities questions belong to licensed professionals, and it frames its own output as a plan to pressure-test, not a decision made for you. The perspective is the value; the authority is the part you withhold.
Step 3: Write what the role may do — and what it may not
The single most effective boundary is a plain two-part list: what the role is allowed to do, and what it is not. The allowed side keeps it useful — it can explain a clause, identify risks, compare options, and draft the questions worth asking. The forbidden side keeps it in its lane — it may not declare the contract safe, diagnose a condition, certify compliance, approve a design, or stand in for the professional whose sign-off actually matters. A model improvises in the gaps you leave, so the "cannot" side often does more work than the "can": it names the overreaches you are most worried about and puts them off-limits up front — which lowers the odds the model reaches for one, though it does not lock the door.
When those limits have to hold across a whole system rather than one chat, the System Prompt Generator is built for the standing version — its restrictions and escalation-handling sections are where "must not" rules and "hand this off" paths live. The Senior Code Reviewer Role Prompt shows the same discipline scoped to one role: it ranks findings by severity, phrases most comments as questions rather than verdicts, leaves style to the linter, and keeps a human accountable for the merge. Both build a prompt you run yourself; neither enforces the limits — the model can still cross a line, which is why the last two steps exist.
Step 4: Say what to do when the context is thin or the question is out of scope
Overreach usually happens in the dark — the model concludes because it was never told what to do when it can't. Give it the missing instructions. If required context is absent, it should say what cannot be determined from what it was given and ask for the specific piece it needs, not fill the hole with a plausible assumption presented as fact. If it is genuinely uncertain, it should say so and show the assumption its answer rests on, so a shaky call is visible instead of buried. And if the question runs past the role's scope, it should flag that rather than stretch to cover it.
Then draw the escalation line explicitly: name what has to go to a human, and to a real professional. "If a clause could carry legal or financial consequences, mark it for a lawyer" turns the model into a triage step that routes the heavy calls onward instead of swallowing them. This is the boundary that matters most on high-stakes topics — legal, medical, financial, safety — where the right output is not an answer but a well-organized set of questions and flags for someone qualified to decide. The role's job there is to prepare the decision, not to make it.
Step 5: Fix the output shape, and keep the decision yours
Give the answer a structure that has nowhere to hide a verdict. Ask for the role's stance up front (stated plainly — "contract risk reviewer, not legal counsel"), then the findings, the assumptions each one rests on, the risks, the questions to ask, and the next human check. A shape like that keeps the model doing the bounded job — surfacing and organizing — rather than collapsing everything into a single "yes, it's fine." The assumptions and questions fields carry the weight here: they are where the limits of the analysis show, and where you see what the answer depends on before you lean on it.
The last line of every role prompt is the one people forget: you decide. The model's output is a candidate analysis, a draft, a checklist — input to your judgment, not a replacement for it. Put it in the prompt if it helps ("end by noting that the final decision and any professional sign-off rest with the reader"), and treat it as true regardless: a role prompt shapes how the model reasons and talks, and on anything that carries real consequences, the verification and the decision stay with you — and, when the stakes call for it, a qualified human.
Common mistakes
The habits that let a role prompt reach past its remit:
- Naming the credential instead of the function. "Act as a lawyer" invites a verdict; "contract risk reviewer" invites the questions you actually want — name the job, not the title.
- Giving the role no "cannot" side. A role with only permissions improvises everywhere you left silent; spell out what it may not decide, approve, diagnose, or certify.
- Letting it conclude from partial context. Without an instruction to flag what is missing, the model treats an incomplete picture as a complete one and answers anyway.
- Leaving the escalation line undrawn. If nothing says "send this to a professional," the model absorbs the high-stakes call instead of routing it — say what has to go to a human.
- Reading fluent as qualified. An answer in an expert's voice is still a candidate analysis; the confident tone is the role working, not proof the content is right.
- Letting decision ownership go unsaid. If the prompt asks only for a verdict, the answer is a verdict — ask for findings, risks, and questions, and keep the call yours.
A worked example: a contract you're tempted to ask AI to clear
Watch a high-authority role prompt overreach, then get boxed into a job it can safely do.
"Act as a lawyer... is it safe to sign?" asks for a verdict the model can't own; a bounded "contract risk reviewer" surfaces the clauses and questions and routes the legal call to a professionalTHE WEAK ROLE PROMPT (a credential, a verdict, no limits):
"Act as a lawyer and tell me if this freelance contract is safe to sign."
WHY IT OVERREACHES:
- "lawyer" reads as authority, so the model answers like counsel
- no jurisdiction, and only an excerpt -- but it concludes anyway
- "safe to sign" asks for a final legal verdict it cannot own
- it can "approve" the contract in one sentence, with no basis
- no output boundary: everything collapses into yes / no
- who owns the decision is never stated -- so it drifts to the model
A BOUNDED ROLE PROMPT (perspective + scope + limits):
Use the perspective of a contract risk reviewer (not legal counsel).
Task:
Flag clauses a freelancer should ask about before signing this excerpt.
You may:
identify unclear terms, one-sided obligations, payment / termination /
IP risks, and the questions worth asking.
Do not:
- say whether the contract is legally safe to sign
- give legal advice or assume a jurisdiction
- approve or reject the contract
- treat missing sections as if they were present
If information is missing:
say what cannot be determined from the excerpt, and name what you'd need.
Output, per issue:
potential risk -> source wording -> why it may matter ->
question to ask -> whether this needs professional review.
THE SHAPE YOU WANT BACK:
Role lens: contract risk reviewer, not legal counsel
Potential risk: payment timing is unclear
Source wording: "Payment will be made after client approval."
Why it may matter: the excerpt sets no approval criteria or deadline
Question to ask: what objective acceptance criteria and payment
deadline apply?
Needs professional review: yes -- if this affects a real signing decision
NEXT: you take the flagged questions to the decision, and to a lawyer if the
contract actually matters. The role prepared the call; it did not make it.Where this fits in NewPrompt
A role prompt is the front half of prompting well: it sets who the model reasons as before you hand it the task. The Role Prompt Generator builds that half with real depth — perspective, responsibilities, decision criteria — so the role thinks in character instead of wearing a name. The Senior Code Reviewer Role Prompt and the Startup Advisor Role Prompt are two roles that already hold their limits — the reviewer defers the merge to a human, and the advisor defers legal and securities questions to licensed professionals — worth reading as models of the boundary, not just the persona. Each gives you a prompt you run in your own AI tool; NewPrompt writes the role, and the reasoning happens on your side.
When the limits have to become standing behavior — an assistant that must follow the same restrictions in every conversation, with defined escalation paths — that is a system prompt, not a one-off role, and the System Prompt Generator is built for it: its restrictions and escalation sections are where the "must not" and "hand off" rules live. A role prompt gives one conversation an expert perspective; a system prompt gives a whole AI worker its standing rules. Reach for the role when you want a bounded perspective on a single question, and the system prompt when the boundary has to outlast the chat.
A few neighbors are close enough to name. Getting the model to label facts, assumptions, and recommendations disciplines the shape of a given answer; this disciplines the role's remit before any answer arrives — different layers, and they stack well. Asking the model to surface the risks in an answer is a task-level move you run on a specific question; here, flagging risks is simply one of the things a bounded role is permitted to do, and the guide is about setting that permission, not about the risk pass itself. And getting the model to ask a question when information is missing is one behavior a bounded role should have, but here it is a piece of the boundary, not the whole of it. This guide is about the remit: how far the role reaches, and where it has to stop.
The useful way to picture a role prompt is a lens, not a license. It changes what the model looks for and how it talks — the risks a reviewer notices first, the trade-offs an architect weighs — but it grants no authority to decide, certify, or sign off, because a sentence in a prompt cannot confer expertise the model does not have. Set the perspective and the model sees more sharply; leave the authority out and it stays a sharp analyst that readies the decision and hands it back to you. The decision, and the qualified human behind it when the stakes are real, are yours to keep.