RCTCO Prompt Framework: Role, Context, Task, Constraints, Output (+ Template)

RCTCO stands for Role, Context, Task, Constraints, Output — five parts, written in that order, that turn a vague request into a prompt a model can't misread. It works the same in ChatGPT, Claude, Gemini or any other chat AI, because it fixes the prompt, not the model.

Part	The question it answers	One-line example
Role	Who is answering?	"You are a staff engineer reviewing a pull request."
Context	What is the situation?	"The service handles payments; this change touches retries."
Task	What exactly do you want?	"List correctness risks, most serious first."
Constraints	What must it avoid or respect?	"No style comments. Say when you are unsure."
Output	What should the answer look like?	"A table: risk, line, why, fix."

Most bad AI outputs are not a model problem — they are a missing-information problem. Give any prompt five parts in order, Role, Context, Task, Constraints, Output, and you remove the ambiguity that forces the model to guess, which is what produces ninety percent of the answers you end up rewriting.

The reason is mechanical, not magical. A language model predicts the most probable continuation of your text. When your prompt is underspecified, "most probable" defaults to "most generic" — the bland, average-of-the-internet answer. Each of the five parts narrows the space of probable continuations toward the specific answer you actually wanted. Structure reduces cognitive load on you (you stop re-explaining the same context every turn) and removes ambiguity for the model (it stops filling gaps with assumptions).

This is the backbone behind every reliable prompt, and it is exactly why every prompt in the Library gives each of these five parts its own labelled line. Below is what each one does, the specific failure you get when you omit it, a full before-and-after rewrite, and a template you can copy today.

The five parts, in order: Role (who the model is) · Context (what it needs to know) · Task (the one thing to do) · Constraints (the rules and limits) · Output (the exact shape of the answer).

Why answer-first, top-down structure works

Before the parts, one principle that shapes all of them: lead with the answer, then support it. Humans and models both parse top-down. When you bury the actual task under three paragraphs of preamble, the model weights the preamble as heavily as the request and drifts. When you state Role and Task up front and let Context and Constraints support them, the model locks onto the goal first and treats everything after as refinement.

This mirrors how good writing works and how good prompts work: the structure is the message. If you want the deeper version of this idea, how to prompt walks through the reasoning, and the sibling piece how to prompt AI correctly covers the habits that surround it. Here we focus on the five-part skeleton itself.

Part 1 — Role: who the model is

The Role sets the model's stance, vocabulary, and quality bar. "You are a senior tax accountant" and "You are a friendly explainer for kids" will answer the same question in completely different registers, depth, and assumed knowledge.

What omitting it costs you: without a role, the model defaults to a neutral, mid-level generalist voice — competent but flavorless, and often wrong on depth. Ask a tax question with no role and you get a Wikipedia-grade summary; assign "senior tax accountant specializing in freelancers" and you get the deductions a generalist skips.

Weak: Explain compound interest.

With a role: You are a financial educator who teaches absolute beginners. Explain compound interest.

The second version will use a concrete savings example, avoid jargon, and define terms — because that is what the role implies. Role is powerful enough to deserve its own treatment; see role-prompting for how far you can push it. As a rule: name a specific role with a specialty, not a generic title. "Marketing expert" is weak. "B2B SaaS content strategist who has launched developer tools" is strong.

Part 2 — Context: what it needs to know

Context is every fact the model cannot infer: your audience, your product, what you have already tried, the source material, the constraints of your situation. This is the single biggest lever on output quality, because the model has zero knowledge of your specifics unless you supply them.

What omitting it costs you: the model invents plausible-sounding context to fill the gap. You asked for "an email to the client about the delay" — with no context it guesses the client's name, the reason, the tone, and the relationship, and you spend three turns correcting all four. Missing context is the number-one cause of "technically correct but useless" answers.

Without context: Write a follow-up email about the project delay.

With context: Write a follow-up email about the project delay. Context: the client is a mid-size law firm we have worked with for two years; the delay is two weeks, caused by a third-party API outage on our vendor's side, not ours; our point of contact, Dana, is detail-oriented and dislikes vague timelines.

The second prompt produces something you can almost send. The first produces a template you have to rebuild. Good context is specific and relevant — dump only what changes the answer, not your life story.

Part 3 — Task: the one thing to do

The Task is the single, explicit action you want. One clear verb: summarize, draft, compare, rank, debug, rewrite, generate. The most common mistake here is bundling three tasks into one sentence and getting a shallow pass at all three.

What omitting or muddying it costs you: ambiguity in the verb produces a mismatched deliverable. "Can you help me with my resume?" might get you advice, a critique, a rewrite, or a list of tips — the model picks one and you may not want that one. And when you ask for "analyze and summarize and suggest improvements" in one breath, you get a thin version of each instead of a strong version of the one that mattered.

Vague task: Help me with this sales page copy. [pastes copy]

Sharp task: Rewrite the headline and first paragraph of this sales page to lead with the customer's main pain point. [pastes copy]

If you genuinely need multiple actions, sequence them or use chain-of-thought-prompting to make the model reason through steps in order — but make the primary task unmistakable.

Part 4 — Constraints: the rules and limits

Constraints are the boundaries: length, tone, what to include, what to avoid, the reading level, the must-use or must-not-use terms. They convert "good enough" into "fits my actual situation."

What omitting them costs you: the model picks defaults you did not choose. No length constraint and a "summary" comes back at 600 words. No tone constraint and your customer apology reads like a press release. No "avoid" list and the model cheerfully recommends the competitor you cannot mention. Every unstated constraint is a coin flip the model makes for you.

No constraints: Summarize this article for our newsletter.

Constrained: Summarize this article for our newsletter. Constraints: 80 to 100 words; warm but professional tone; no marketing hype; one concrete takeaway the reader can act on today; do not mention pricing.

Notice how the constraints do the heavy lifting — they encode the editorial judgment you would otherwise apply by hand on every draft. The more often you reuse a prompt, the more your constraints are worth, because they bake your standards in once.

Part 5 — Output: the exact shape of the answer

The Output part specifies format and structure: a table, JSON, a numbered list, a three-section memo, a tweet thread, markdown with specific headers. This is what makes outputs predictable enough to paste into a document, a spreadsheet, or downstream code without reformatting.

What omitting it costs you: you get prose when you needed a table, or a wall of text when you needed five bullets. For anything you process programmatically, an unspecified output shape is a guaranteed second round-trip — and sometimes a parsing bug.

No output spec: Give me three subject line options for this email.

With output spec: Give me three subject line options for this email. Output as a markdown table with two columns: "Subject Line" and "Why It Works (max 12 words)". No preamble, no closing remarks.

The "no preamble" line alone saves you from the "Sure! Here are three options:" warm-up you would otherwise delete every time. Be as literal about shape as you can — show the format if you can, do not just name it.

The full transformation: vague to structured

Here is the move in full. Start with a prompt almost everyone writes:

Before: Write a LinkedIn post about our new feature.

This will produce something generic, off-brand, the wrong length, and probably opening with "Excited to announce." Now rebuild it with all five parts, each labeled so you can see them at work:

Role: You are a B2B social media writer for a developer-tools company. Your posts sound like a sharp engineer talking, never like a corporate account.

Context: We just shipped a feature called Replay that lets developers re-run any failed API request from their dashboard with one click, capturing the exact headers and payload. Before this, they had to reconstruct failed requests by hand from logs, which took 15 to 30 minutes per incident. Our audience is backend engineers at startups.

Task: Write one LinkedIn post announcing Replay.

Constraints: 120 to 160 words; open with the pain (manual request reconstruction), not the announcement; one short concrete example; no hashtags; no "excited to announce"; confident but not hype-y; end with a single question to drive comments.

Output: Plain text ready to paste into LinkedIn. Use short line breaks between thoughts for readability. No title, no preamble.

The second prompt is longer — and that is the point. It does the thinking up front so the model does not have to guess. The first version takes five edit-and-retry cycles to get usable; the structured version typically lands in one, occasionally two. That is the ninety-percent figure in practice: most of the rewrites you do are the model paying back ambiguity you left in the prompt.

The trade you are making: roughly 60 extra seconds writing the prompt buys you back the 10 minutes you would have spent re-rolling and hand-editing a vague one. On any prompt you reuse, that trade compounds.

The reusable template

Copy this, fill the five slots, delete any line that genuinely does not apply (Role and Context are the two you should almost never skip):

Role: You are a [specific role with a specialty].

Context: [Audience, situation, source material, what you've tried, anything the model cannot infer.]

Task: [One clear action verb + the single deliverable.]

Constraints: [Length; tone; must-include; must-avoid; reading level; anything off-limits.]

Output: [Exact format — table / list / JSON / sections — and "no preamble" if you want clean output.]

A few rules that make the template hold up:

• Order matters, but presence matters more. Lead with Role and Task so the model locks onto the goal; just don't drop Context or Constraints to save typing — those are where the quality lives.
• Specific beats long. A tight three-line context beats a rambling paragraph. Include only what changes the answer.
• Reuse the skeleton, swap the slots. Once a structured prompt works, keep it as a reusable block and change only Context and Task next time.

If you want a deeper bench of starting points instead of writing every prompt cold, the Library has thousands of prompts already built on this structure, and AI Courses runs 36 courses that drill the five parts until structuring a prompt is automatic.

Where this clicks into place

The hard part of the five-part structure is not understanding it — it is remembering to apply all five, in order, every time, under deadline pressure. The fix is to write each part as a labelled line, so Role, Context, Task, Constraints, and Output stop being a checklist you forget and become the literal shape of what you build. Each line maps one-to-one to a part of this structure, which means you cannot quietly skip the context — it is sitting right there, empty, asking to be filled.

Start with the worked example above, rebuild one prompt you use every week, and watch your retry count drop. Then make that same five-part skeleton the default shape of every prompt you write — or start from the ready ones in the Library.