The RTF Prompt Framework (Role, Task, Format)

TL;DR: RTF is Role, Task, Format: three lines that turn a bare request into a prompt that reliably works. Role sets whose expertise the model answers from, Task states the exact action, Format defines how the output should look. It's the smallest framework that consistently beats no framework, which is exactly why it's worth learning first.

What Is the RTF Prompt Framework?

RTF is a three-part prompt structure: Role, Task, Format. You tell the model who it's answering as, what to do, and how to shape what it hands back.

That's the whole framework. No tone setting, no audience field, no constraints block — just the three things a prompt cannot skip and still be reliable. A request with none of the three ("write about our pricing change") gets you generic filler. The same request with Role, Task, and Format attached gets you something usable on the first try.

RTF isn't the most powerful framework in this cluster; templates like CO-STAR or AUTOMAT carry more. It's the floor everything else builds on. If you've never used a framework before, this is the one to learn, because you'll feel the difference on the very first prompt you rewrite with it.

Why Does Assigning a Role Change the Output?

A Role changes the output because it changes which vocabulary, priorities, and assumptions the model draws on to answer. It's the single highest-leverage line in the whole prompt.

Compare a bare request to the same request with a Role attached.

Bare: "Review my code for bugs."

With Role: "You are a senior backend engineer who specializes in API security and has reviewed thousands of production pull requests. Review my code for bugs."

The second version doesn't just sound more authoritative. It changes what the model looks for. "Senior backend engineer" narrows the model toward runtime behavior, edge cases, and failure modes instead of style nitpicks. "Specializes in API security" narrows it further, toward injection risks and auth bypasses specifically, before you've said a single word about what the code does.

What Belongs in the Task Component?

Task is the exact action and deliverable: what to do, to what, and how much of it. A vague Task produces a vague answer even with a strong Role attached.

Building on the example above:

With Role + Task: "You are a senior backend engineer who specializes in API security and has reviewed thousands of production pull requests. Review the function below for SQL injection and authentication bypass vulnerabilities, and identify the exact line each issue occurs on."

Notice what changed: "review my code for bugs" became "review for two named vulnerability classes and cite line numbers." That's the difference between a Task that describes a category of work and one that describes a specific, checkable deliverable. The model can't tell if it succeeded at "find bugs." It can tell if it succeeded at "list SQL injection and auth bypass issues with line numbers."

A good Task answers three things: what action, on what input, to what scope. Skip any one of the three and the model fills the gap with a guess, usually the most generic interpretation available.

How Does the Format Component Lock Down the Output?

Format tells the model the shape of the answer (list, table, JSON, word count, code block) so structure isn't left to chance. This is the component most people skip, and it's the one that decides whether you can actually use the output without editing it first.

Finishing the example:

With Role + Task + Format: add "Respond as a numbered list. Each entry: the vulnerability type, the line number, and a one-sentence fix. If no vulnerabilities are found, say so explicitly. Do not invent one."

That last sentence matters as much as the structure request. Format isn't only about layout; it's also where you tell the model what to do when there's nothing to report, which heads off the common failure of a model manufacturing an issue just to have something to say.

Here's the complete prompt, built from all three components, ready to paste with your own code underneath it:

Role: You are a senior backend engineer who specializes in API security and has reviewed thousands of production pull requests.

Task: Review the function below for SQL injection and authentication bypass vulnerabilities. Identify every issue and the exact line it occurs on. Do not comment on style, naming, or formatting.

Format: Respond as a numbered list. Each entry: (1) the vulnerability type, (2) the line number, (3) a one-sentence fix. If no vulnerabilities are found, say so explicitly — do not invent one.

[paste your function here]

That's RTF end to end: one line each for who's answering, what to do, and how to shape it back. Compare that final version to the one-sentence bare prompt at the top of this section: same request, three lines added, and the output goes from "read it and hope" to "check the list against the code."

RTF vs CO-STAR vs CRISPE vs AUTOMAT: Which Should You Use?

RTF is the right choice for quick, single-purpose requests; the others earn their extra components on audience-facing, iterative, or high-stakes prompts. Component count is a reasonable proxy for how much a framework asks of you before you get an answer.

For a wider tour of frameworks beyond these four, see the 7 ChatGPT prompt frameworks overview, or the prompt engineering cheat sheet for a one-page reference across all of them.

When Does RTF Stop Being Enough?

RTF stops being enough exactly where tone, constraints, edge cases, and examples matter. Three components can't carry all four of those, and it isn't trying to.

Here's where each gap shows up in practice:

• Tone. RTF has no slot for how the output should sound. A Role implies some tone, but "senior backend engineer" doesn't tell the model whether to be terse or explanatory.
• Constraints. RTF has no slot for what to avoid, hard limits, or "unless X, then do Y" logic. Format can carry a length limit, but not much beyond that.
• Edge cases. RTF has no slot for "if the input doesn't match what you expect, do this instead." You saw a version of this bolted onto the Format line in the code-review prompt above, and that's a workaround, not a real component.
• Examples. RTF has no few-shot slot for showing the model what "good" looks like when your instructions alone keep landing slightly off.

This is also, not coincidentally, the shape Prompt Architects enhances every prompt into: Role, Task, Format, Constraints, Tone. The first three are RTF. The last two are the exact gap listed above: constraints for edge cases and limits, tone for how it should sound. RTF is genuinely the first three-fifths of a fuller structure, not a separate idea competing with it. For background on why structure matters at all in prompting, this beginner's guide to prompt engineering covers the underlying mechanics.

What Do Ready-to-Use RTF Prompts Look Like?

Here are nine RTF prompts across common jobs, ready to copy and adapt. Swap the bracketed parts for your own details.

Email, customer-facing apology:

Role: You are a customer support lead known for direct, no-corporate-speak apologies.
Task: Write an email to a customer whose [order/account/service] was affected by [issue]. Acknowledge the problem, explain the fix, and state what they get as compensation.
Format: Under 150 words. No subject line. Plain paragraphs, no bullet points.

Summary, long meeting notes:

Role: You are an executive assistant who summarizes meetings for people who weren't there.
Task: Summarize the notes below into decisions made, action items with owners, and open questions.
Format: Three headed sections: Decisions, Action Items (owner — task), Open Questions. No narrative recap.

[paste notes]

Code, refactor for readability:

Role: You are a staff engineer who reviews code for maintainability, not just correctness.
Task: Refactor the function below for readability without changing its behavior. Flag anything you're unsure preserves the original logic.
Format: Return the refactored code in a single code block, followed by a short bullet list of what changed and why.

[paste function]

Analysis, comparing two options:

Role: You are an analyst who's built the business case for dozens of buy-vs-build decisions.
Task: Compare [option A] and [option B] on cost, implementation time, and risk, using only the facts provided below.
Format: A markdown table with those three rows, followed by a two-sentence recommendation.

[paste facts]

Social post, LinkedIn:

Role: You are a founder who posts on LinkedIn without sounding like a LinkedIn post.
Task: Turn the update below into a post about [topic], written like you're telling a colleague, not announcing to an audience.
Format: Under 120 words. No hashtags. No "here's what I learned" opener.

[paste update]

Blog outline:

Role: You are a content editor who plans posts for search intent, not just topic coverage.
Task: Outline a post targeting the query "[target query]" — cover what a searcher actually needs answered, in the order they'd need it.
Format: H2-level outline only, one line per section describing what it answers. No full sentences.

Customer support reply:

Role: You are a support agent trained to de-escalate frustrated customers without sounding scripted.
Task: Reply to the message below, address the specific complaint, and offer the next concrete step.
Format: Three short paragraphs max. No opening pleasantry longer than one sentence.

[paste customer message]

Product description:

Role: You are a product copywriter who writes for people comparing three tabs at once.
Task: Write a description for [product], leading with the one thing it does better than the alternative they're probably also looking at.
Format: 60-80 words. One sentence, then three bullet points, then a closing sentence.

Resume bullet rewrite:

Role: You are a recruiter who reads 200 resumes a week and skims for impact, not duties.
Task: Rewrite the bullet points below to lead with outcomes and include a number wherever one is implied but missing.
Format: Same number of bullets as the input, each one line, no more than 20 words.

[paste bullets]

Run any of these once as written, then adjust exactly one component — usually Format — based on what came back. That's the whole workflow: build the three lines, run it, and fix the one line that's off. Nothing more elaborate than that is required for the vast majority of everyday prompts.