Tips are easy to forget. A framework sticks. The trouble with most prompting advice is that it arrives as a disconnected list, and under pressure you remember none of it. A framework solves that by giving you one structure to run through every time, so the right moves happen automatically.
This guide introduces CRAFT, a five-part model that organizes the basics of prompting into a sequence you can apply to any task: Context, Role, Action, Format, and Tests. It is not a magic formula, and you will not need all five parts for every prompt. The value is having a checklist-shaped mental model so nothing important slips.
We will define each component, explain when it matters most, and show how the pieces fit together. By the end you will be able to assemble a strong prompt by walking through five letters instead of trying to recall a dozen scattered rules.
Why Use a Framework at All
A framework converts knowledge into a habit. Knowing that examples help is useless if you forget to include one. A model like CRAFT forces the question "did I cover this?" for each component, which is exactly how experienced practitioners think even when they are not naming the steps.
The other benefit is diagnosis. When a prompt fails, you can walk the framework to find the missing piece: weak output usually means a gap in one specific component. This turns vague frustration into a targeted fix. Our common mistakes guide maps most failures to a missing CRAFT component.
C: Context
Context is everything the model needs to know that it cannot infer: background facts, source material, constraints, prior decisions. The model has no access to your situation, so context is where you load it in.
When it matters most
Context is critical whenever the task depends on specifics the model could not guess: your product details, your project history, the document to operate on. Wrap pasted material in delimiters to keep it separate from your instructions. The failure mode of skipping context is generic output that ignores your actual situation, the most common complaint about AI tools.
R: Role
Role tells the model who to be: "You are a contracts lawyer," "Act as a skeptical editor," "Respond as a patient tutor." A well-chosen role primes the model toward the right vocabulary, depth, and stance.
Role is optional but powerful for tasks where perspective shapes the answer. A legal review, a code critique, and a beginner explanation all benefit from naming the right persona. Skip it for simple, perspective-neutral tasks like a factual lookup, where it adds nothing. Our examples guide shows roles applied to real tasks.
A: Action
Action is the single, specific task stated as an imperative: "Summarize," "Rewrite," "Extract," "Compare." This is the one component you always need. Lead with it, state it as a command, and keep it to one job.
- One clear verb beats a polite ramble.
- One task per prompt; sequence multiple jobs rather than cramming them.
- Specific verbs ("critique," "condense") beat vague ones ("help with," "look at").
The failure mode here is the multi-task pile-up, where one prompt asks for four things and does each poorly. Our how-to guide treats the single imperative as the backbone of every prompt.
F: Format
Format specifies exactly how the output should look: length, structure, and presentation. "Three bullets under 20 words each," "a markdown table with these columns," "a single paragraph under 100 words."
The strongest version of format is showing rather than describing. Paste a literal example of the structure you want and say "match this." Models reproduce concrete examples far more faithfully than abstract format descriptions. The failure mode of weak format specification is output you have to reformat by hand, which defeats the point of automating the task at all.
T: Tests
Tests is the component everyone forgets and the one that separates reliable prompts from lucky ones. Before you trust output, define your success criteria, verify facts, and run the prompt against more than one input.
What testing looks like
- Define "this succeeds if ___" before you write.
- Verify every fact, number, and citation; never trust the model's memory.
- Run the prompt on several varied inputs, not just the one that worked.
Tests is also where you decide a prompt is done. A prompt that passes on one input but fails on the next is not finished. Our checklist is essentially the Tests component expanded into a usable pre-flight tool.
Putting CRAFT Together
You do not march through all five letters mechanically. The skill is knowing which components a task needs. A quick factual question needs only Action. A high-stakes client document needs Context, Role, Action, Format, and Tests in full.
Run the framework as a question, not a template: "What context does this need? Does it need a role? What is the exact action? What format? How will I test it?" Five questions, asked in order, assemble a strong prompt every time and tell you exactly where to look when one fails. For the deeper reasoning behind each move, see our best practices guide.
Using CRAFT to Debug a Failing Prompt
The framework's second job is diagnosis, and it is where CRAFT earns its keep day to day. When a prompt produces bad output, do not rewrite it blindly. Walk the five components and ask which one is missing or weak.
- Output is generic? You probably skimped on Context or gave no audience.
- Output adopts the wrong stance or depth? Your Role is missing or wrong.
- Output does the wrong thing, or several things badly? Your Action is unclear or overloaded.
- Output is hard to use or inconsistently structured? Your Format is underspecified, so show an example.
- Output looks fine but contains errors? You skipped Tests and trusted it without verifying.
This turns debugging from guesswork into a checklist. Most failed prompts have exactly one weak component, and walking CRAFT finds it in seconds. Pair this with the one-variable-at-a-time iteration habit from our how-to guide: diagnose the weak component, fix only that, rerun, and confirm.
Frequently Asked Questions
Do I need to use all five CRAFT components every time?
No. Action is the only component you always need. The others are added based on the task: Context and Format for anything substantive, Role when perspective matters, and Tests for anything you will rely on. Applying all five to a trivial question is over-engineering.
How is CRAFT different from just listing prompt tips?
A framework is ordered and exhaustive, so it doubles as a diagnostic. When a prompt fails, you walk the five components to locate the missing piece, which a flat list of tips cannot do. The structure is what makes the advice stick and stay actionable under pressure.
Which CRAFT component do people skip most?
Tests. People write a prompt, get one acceptable result, and ship it without verifying facts or checking other inputs. Skipping Tests is how fabricated information and one-off-only prompts make it into real work. It is the highest-value component to stop neglecting.
Can I reorder the components?
The letters are a memory aid, not a strict sequence for the prompt text itself. In practice you often place the Action first or last in the actual prompt for emphasis, with Context in a delimited block. Use the order to make sure you considered each piece, not to dictate prompt layout.
Does this framework work across different AI tools?
Yes. CRAFT reflects how language models use input generally, not a quirk of one product. Context, clear action, format, and verification improve output everywhere. You may tune small details per tool, but the five-component structure transfers across models.
Key Takeaways
- CRAFT, Context, Role, Action, Format, Tests, turns scattered tips into one repeatable process.
- Action is the only always-required component; add the others based on the task.
- Context prevents generic output; Format is strongest when you show rather than describe.
- Tests is the most-skipped component and the one that makes prompts reliable.
- Use the framework as five diagnostic questions to both build and debug prompts.