Skip to main content
Back to Blog
Featured
prompt engineeringprompt structureRCAFprompt frameworksprompt templates

The RCAF Prompt Structure: A 4-Part Skeleton for Maintainable Prompts

RCAF is a 4-part prompt skeleton — Role, Context, Action, Format — that produces maintainable prompts by separating identity, background, task, and output shape.

SurePrompts Team
April 21, 2026
11 min read

TL;DR

RCAF is a 4-part prompt skeleton — Role, Context, Action, Format — that produces maintainable prompts by separating identity, background, task, and output shape.

Tip

TL;DR: RCAF is a 4-part prompt skeleton — Role, Context, Action, Format — that separates identity, background, task, and output shape so each can be edited independently without breaking the others.

Key takeaways:

  • RCAF is four slots, not five or seven. The minimalism is the point.
  • Each slot corresponds to a distinct failure mode: wrong identity, missing background, vague task, unspecified output.
  • RCAF is a drafting skeleton. Pair it with the SurePrompts Quality Rubric for auditing.
  • Named frameworks like RACE, CREATE, RISEN, and TCREI are fine for learning; RCAF is tuned for maintenance.
  • Break RCAF for conversational one-offs. Use it everywhere a prompt will run more than once.

Why a prompt structure at all?

Prompts written freehand look easy to edit and are not. A paragraph that mixes identity ("you're a helpful analyst"), background ("the spreadsheet has sales by quarter"), task ("find anomalies"), and output ("return a bullet list") reads fine until someone needs to change one of them. Tightening the output format requires re-reading the whole thing to confirm you did not accidentally change the task. Swapping the role requires scanning every sentence for tone drift. The four concerns are physically tangled in the same text.

A skeleton fixes that. By putting each concern in a labeled slot, you get three properties prose prompts lack:

  • Editability. Changing the format does not touch the task. Changing the role does not touch the context.
  • Diffability. Two versions of an RCAF prompt produce a readable diff. Two versions of a paragraph produce a rewrite.
  • Transferability. The role and format slots are reusable across tasks; the context and action are per-run. That separation is where template libraries come from.

These properties do not matter for a prompt you will type once and discard. They matter enormously for prompt engineering done at scale — product features, agents, reusable templates, team-shared libraries — where the cost of re-reading and re-testing compounds.

Why RCAF and not RACE, CREATE, RISEN, or TCREI?

Other frameworks exist. A short, honest comparison:

  • RACE (Role, Action, Context, Execute) puts Action before Context, which inverts the natural reading order and makes templates harder to compose.
  • CREATE — one common expansion is Character, Request, Examples, Additions, Type, Extras (other sources use slightly different slot names) — has six slots, two of which ("Additions," "Extras") are catch-alls. Catch-all slots collect everything that does not fit and eventually become where bugs hide.
  • RISEN (Role, Input, Steps, Expectation, Narrowing) bakes chain-of-thought structure (Steps) into the skeleton itself. That is correct for some tasks and wrong for many others, and a skeleton should not decide that for you.
  • TCREI (Task, Context, References, Evaluate, Iterate) mixes prompt structure with a meta-workflow (evaluate, iterate). The workflow is useful; it does not belong in the prompt.

RCAF's bet is different: strip the skeleton down to the four structural concerns that every non-trivial prompt contains, and push everything else — examples, reasoning style, constraints, iteration loops — into the four slots as sub-elements. Examples go into Context. Step-by-step reasoning goes into Action. Length limits and banned words go into Format. The skeleton stays small; the content grows where it should.

The result is a framework you can recall from memory under pressure, teach in five minutes, and map onto a template engine without ceremony. That is the trade-off. You give up the self-documenting prompts that longer frameworks produce, and you gain a structure people actually use.

The four parts

R — Role

The Role slot assigns the model an identity with enough specificity to constrain tone, voice, expertise level, and posture. "You are a helpful assistant" fails — it is a placeholder, not a role. "You are a senior backend engineer reviewing a pull request for production readiness" works — it names the seniority, the activity, and the bar.

Role is not the same as persona prompting. Persona prompting ("pretend you are Shakespeare") is a stylistic trick that sometimes helps and sometimes confuses the model about what it is actually being asked to do. Role in RCAF is functional: who do you need the model to be for this task to come out right? The answer is almost never a celebrity. It is usually a job title plus a posture.

Common mistakes:

  • Using "expert" without specifying the domain. Expert is a null word; every model already thinks it is an expert.
  • Stacking multiple roles ("you are a senior engineer and a designer and a PM"). The model averages them and produces no clear voice.
  • Writing the role in the user turn instead of the system prompt. The Role slot belongs at the top of the system prompt when one is available.

C — Context

The Context slot supplies the background the model needs to act correctly — the user's situation, prior decisions, constraints, domain facts, relevant history, and any reference material. Context is where most prompts are thinnest and where context engineering becomes a discipline of its own.

Context has no upper bound in principle but has sharp trade-offs in practice. Too little context and the model fills in plausible but wrong defaults. Too much and attention dilutes, latency rises, and cost climbs. The Context Engineering Maturity Model describes how teams scale context assembly from ad-hoc pasting to tiered retrieval — RCAF's Context slot is where that machinery lives.

Things that go in Context:

  • Facts the model needs but cannot infer (product specs, user account state, org policies).
  • Constraints that shape the response but are not output-format rules (tone conventions, compliance requirements, known failure modes to avoid).
  • Few-shot examples. Examples belong in Context, not in their own slot, because they are part of the background the model uses to calibrate.

A — Action

The Action slot is the task itself: what you want the model to do, its sub-tasks, and the success criteria. Specificity wins here, but specificity is not the same as verbosity. A three-sentence Action that names the task, the sub-steps, and the bar for success beats a three-paragraph Action that hedges.

The common mistake is a vague verb. "Help me with my resume" is not an action; it is a topic. "Rewrite my resume summary section to be three sentences, lead with my current role, and name two quantifiable outcomes from the last two years" is an action. The first prompt will get you a generic rewrite; the second will get you what you meant.

For multi-step tasks, the Action slot can name the steps explicitly, but it does not have to. Chain-of-thought reasoning is a technique you apply inside Action, not a separate RCAF slot. Some tasks benefit from "think step by step"; others do not, especially when using a reasoning model that already produces structured internal reasoning.

F — Format

The Format slot specifies the output shape. In practice this is the highest-leverage slot and the most under-specified. A prompt with a strong Role, Context, and Action and a weak Format produces output that is nearly right but shaped wrong — which is almost always more annoying to fix than output that is clearly wrong.

Format includes:

  • Structure (JSON schema, section headers, markdown table, prose with specific sections).
  • Length (word count, bullet count, sentence count).
  • Tone and voice (if not already pinned by Role).
  • Any enforceable constraints (banned phrases, required fields, ordering).

When the output needs to be machine-parsed, specify it as a schema and consider asking for structured output explicitly. When it is for humans, specify the shape anyway — "3 bullets, each under 15 words, benefit-first" is a format. "Make it concise" is not.

The heuristic: when in doubt, over-specify Format. Format instructions are cheap to add, cheap to ignore when unnecessary, and expensive to recover from when missing.

Worked example

Start with a weak prompt:

Summarize this customer support transcript for our weekly ops review.

Scored against the SurePrompts Quality Rubric:

  • Role clarity: 1 (no role)
  • Context sufficiency: 1 (no transcript, no audience definition)
  • Instruction specificity: 2 (task named, nothing else)
  • Format structure: 1 (no format)
  • Example quality: 1 (no example)
  • Constraint tightness: 1 (no constraints)
  • Output validation: 1 (no validation plan)

Total: 8/35. Not functional.

Restructured via RCAF:

Role: You are a support operations analyst preparing a weekly summary for a 30-minute cross-functional review attended by product, engineering, and support leads. Voice: neutral, concrete, no marketing language.

>

Context: The input below is a raw chat transcript from a single customer support case. The audience already knows the product but does not know this case. They care about: root cause, whether the issue is likely to recur, and whether any other customer is at risk. They do not care about the play-by-play of the conversation.

>

Action: Produce a summary of the case that a lead can read in under 60 seconds. Name the root cause in one sentence. List the facts that support that diagnosis. Flag any second-order risks to other customers. Call out open questions the support agent did not resolve.

>

Format:

- One-sentence root cause line, prefixed Root cause:.

- Up to 4 bullets of supporting facts, each under 20 words.

- One line prefixed Recurrence risk: with low/medium/high and a one-sentence justification.

- Open questions as a numbered list, or "None" if none.

- Total length under 150 words.

Re-scored:

  • Role clarity: 5
  • Context sufficiency: 4 (we could add the customer's account tier)
  • Instruction specificity: 5
  • Format structure: 5
  • Example quality: 2 (no example; acceptable for this task)
  • Constraint tightness: 4 (length cap and prefix conventions; could ban marketing language explicitly)
  • Output validation: 3 (structure is machine-checkable; no explicit validation instruction)

Total: 28/35. Ship it.

The before/after is not a miracle. It is what happens when four things that were tangled get put into four labeled slots.

When to break RCAF

Skip RCAF when:

  • The prompt is conversational and under 50 words.
  • You are exploring — you do not yet know the task well enough to specify it, and the goal of the turn is to find out.
  • You are in a multi-turn agent loop where Role, Context, and Format already live in the system prompt and each per-step message is a short action delta. The structure is still there; it is just distributed across layers.
  • You are using a few-shot prompting pattern where examples carry most of the signal and explicit slots would be redundant.

RCAF is a discipline for high-stakes, repeatable, or production prompts. Applying it to every chat message is the prompt-engineering equivalent of writing unit tests for throwaway scripts — technically correct, practically wasteful.

Our position

  • RCAF paired with the SurePrompts Quality Rubric is the recommended SurePrompts workflow. RCAF to draft, Rubric to audit, iterate on the lowest-scoring dimension.
  • Prefer RCAF over RACE, CREATE, RISEN, or TCREI for production prompts. The longer frameworks are fine teaching tools; RCAF is tuned for maintenance, not introduction.
  • Skip RCAF for conversational prompts under 50 words. The overhead is real and the benefit vanishes.
  • Format is almost always under-specified. When in doubt, over-specify Format — it is the cheapest dimension to add and the most expensive to omit.
  • Examples belong inside Context, not in a separate slot. Promoting examples to a top-level slot (as CREATE does) encourages adding examples by default, which is the opposite of what a good prompt library should do.
  • Role should live in the system prompt when one is available, not duplicated in every user turn. Role is the slowest-changing slot; cache it at the layer that caches.

Build prompts like these in seconds

Use the Template Builder to customize 350+ expert templates with real-time preview, then export for any AI model.

Open Template Builder