How to Structure an AI Prompt (and What Frameworks Actually Buy You)
Search for prompt advice and you will drown in acronyms: RICECO, TCF, CRISPE, RTF, each promising that the right template unlocks the model. The truth is less mystical and more useful. A prompt works when it carries five specific pieces of information, and it fails when one of them is missing — whatever labels it wears. This guide walks through that anatomy, takes a real prompt apart to show each piece doing its job, and explains when a framework genuinely earns its keep.
The five parts every effective prompt carries
Strip the branding off every popular prompt framework and the same anatomy appears underneath. A prompt is a small act of delegation, and delegation succeeds on the same information whether the worker is a model or a new colleague: what to do, what they need to know, what the result should look like, where the boundaries are, and what to do when the instructions run out.
| Part | What it tells the model | The failure it prevents |
|---|---|---|
| Task | The single job to do, stated as an action | Meandering output that summarises when you wanted a rewrite |
| Context | Who this is for, what it's about, the raw material | Generic answers that fit anyone's situation but not yours |
| Format contract | The shape of the output: sections, length, fields | Prose you have to re-edit into the thing you actually needed |
| Constraints | Hard rules — keep numbers exact, stay under 150 words | Rounded figures, padded filler, invented politeness |
| Escape hatch | What to do with missing or ambiguous information | Confident fabrication — the most expensive failure of all |
Notice what is not on the list: labels. The model does not need to see the word "Context:" to use context. It needs the context itself. That distinction is the whole argument of the next section, and it is why two prompts with identical information perform alike even when one looks like a form and the other reads like a paragraph.
RICECO, TCF and friends: checklists, not incantations
Frameworks are mnemonic devices for the anatomy above, and judged as that, they are genuinely helpful — a checklist you run before hitting enter, so you notice the missing piece while it is still cheap to add.
- RICECO — Role, Instruction, Context, Examples, Constraints, Output: the most complete of the family; its E is the only element the others skip.
- TCF — Task, Context, Format: the minimal viable checklist, and honestly enough for most day-to-day prompting.
- CRISPE — Capacity, Role, Insight, Statement, Personality, Experiment: aimed at exploratory and creative work rather than task execution.
- RTF — Role, Task, Format: TCF with a persona bolted on the front.
Where people go wrong is treating the checklist as a syntax. Writing "Role: project coordinator" and "You are a project coordinator" hands the model the same fact, and instruction-tuned models respond to the fact, not the heading. Short prompts written as labelled forms can even read worse, because the connective reasoning between elements — this format BECAUSE this audience — gets amputated at the section boundaries.
A worked example, taken apart
Here is a working prompt for turning meeting notes into action items, written as prose. The double-brace markers are fill-in blanks; everything else ships as-is.
You are a project coordinator for {{team}}. Turn the raw meeting notes
below into a list of action items.
For each item give: the task in one sentence, the owner (or
"unassigned" — never guess a name), and the deadline if one was
mentioned. Format the result as {{format}}. List decisions that were
made separately from tasks. If something is ambiguous, put it under
"Needs clarification" rather than inventing details.
Notes:
{{notes}}| Line | Anatomy part |
|---|---|
| "You are a project coordinator for {{team}}" | Role + context |
| "Turn the raw meeting notes below into a list of action items" | Task |
| "For each item give: task, owner, deadline … as {{format}}" | Format contract |
| "never guess a name" / "decisions separately from tasks" | Constraints |
| "put it under Needs clarification rather than inventing details" | Escape hatch |
| "Notes: {{notes}}" | Raw material |
Run it through the RICECO checklist and five of six letters are covered; only Examples is absent, deliberately — the format contract here is simple enough to state, and stating a format is cheaper than demonstrating one. That trade-off gets its own section below.
The escape hatch: one line that stops invented facts
If you adopt a single habit from this guide, make it this one. Models fill gaps by default: ask for owners and deadlines, and notes that name neither will come back with plausible owners and reasonable-sounding deadlines. Nothing in the output marks which facts were read and which were manufactured — that is what makes fabrication expensive rather than merely wrong.
The fix is to give uncertainty somewhere legitimate to go. A prompt that only rewards complete answers pushes the model to complete them by any means; a prompt with a sanctioned place for gaps makes honesty the path of least resistance.
- "If something is ambiguous, put it under Needs clarification instead of inventing details."
- "Use null for anything the text doesn't state — never infer a value."
- "If you are not certain what this function does, say so explicitly rather than guessing."
- "If the requirements conflict, tell me which ones and why, instead of producing output that quietly drops one."
One line, adapted to the task. Across every prompt we publish it is the single constraint that most changes output quality, because it converts silent guesses into visible questions you can actually answer.
When examples help — and when they backfire
Examples — the E that RICECO adds — are the most situational part of the anatomy. A demonstration is worth many words of description when the output format is fiddly: one sample changelog entry communicates tone, tense and length better than three sentences of instruction about them.
But examples anchor as hard as they teach. Show three formal headlines and every variation comes back formal; paste a sample summary and its emphasis quietly becomes the emphasis of yours. Examples also bloat a prompt meant to be copied and reused, and stale ones actively mislead.
- Add one when the format is strict and hard to describe — a JSON shape, a flashcard layout, a changelog line.
- Skip them when you want breadth — brainstorming, variations, options — where anchoring is the enemy.
- One good example nearly always beats three; three teach a pattern you may not have intended.
Write your own, in six steps
Write a prompt from scratch
State the task as one action
One verb, one deliverable: "turn these notes into action items". If you need two sentences to say what the job is, it is two prompts.
Hand over the context
Who it's for, what it concerns, and the raw material itself. Anything the model must know but cannot see will be invented on your behalf.
Set the format contract
Name the sections, the fields per item, and a concrete length budget — "under 150 words" outperforms "be concise" every time.
Add the constraints that matter
Two or three hard rules aimed at failures you have actually seen: keep figures exact, no added apologies, shorter than my draft.
Give uncertainty an exit
Add the escape hatch: where missing information should go, in so many words. This is the anti-fabrication line — never skip it.
Test on real input, then tighten
Run it on a genuinely messy sample, find the worst part of the output, and add one constraint targeting exactly that. Repeat until it holds.
Two of this site's tools slot straight into that loop: the word counter verifies a length budget before you paste, and the markdown previewer renders a model's markdown output so you can read the structure you actually received. And if you would rather start from something proven than from a blank page, every prompt in the Library ships with this anatomy already in place — fill in the blanks and go.