Most people build prompt templates by intuition: write something, try it, tweak it until it seems good enough. That works for one template. It does not scale to a library, because there is no shared model for what a good template contains, no checklist of components, and no common vocabulary for discussing them. Two people build two structurally different templates for the same task and neither can say which is better designed.
A framework fixes this by naming the components and the order to assemble them. The model below is called CRAFT — Contract, Role, Anchors, Fallbacks, Tests. It is deliberately small: five components, each addressing one recurring source of template failure. CRAFT is not the only way to think about templates, but it gives a team a shared structure, so a template is "done" when all five components are present and validated rather than when it happens to feel right.
This article defines each component, explains when it matters most, and shows how the five fit together. By the end you should be able to look at any template and name what it is missing.
C — Contract: Define the Output First
The Contract is the exact shape of the output you want back, and in CRAFT it comes first.
Why Contract Leads
Deciding the output format before anything else makes every other component easier, because they all serve the contract. Specify precisely: bullet counts, JSON schema, word limits, required sections. A template built contract-first rarely suffers the most common failure — vague, inconsistent output. Build the contract last and the instruction and format tend to conflict, leaving the model to resolve the conflict however it likes. The case for contract-first design is argued in Prompt Templates: Best Practices That Actually Work.
When It Matters Most
Always, but especially for any output that feeds an automated pipeline, where a malformed format breaks everything downstream.
R — Role: Anchor Tone and Domain
The Role is the short statement of who the model should act as and in what context.
Why Role Matters
A single line — "You are a support agent for a software company" — anchors tone, vocabulary, and domain assumptions. Without it, the model defaults to a generic voice that rarely matches your brand or context. The Role is cheap to write and disproportionately effective at making output feel consistent.
When It Matters Most
For any customer-facing or brand-sensitive output, and for domain-specific tasks where the model needs to assume specialized context.
A — Anchors: Scope the Variables
Anchors are the variables — the placeholders for what changes — and the discipline of scoping them tightly.
Why Anchors Need Discipline
Each variable is a degree of freedom, and every degree of freedom is a place inconsistency enters. Good Anchors are few, specifically named, and capture one clear thing each. The failure mode — overstuffed variables that swallow everything — is one of the most common in 7 Common Mistakes with Prompt Templates (and How to Avoid Them). Prefer several focused templates over one with sprawling anchors.
When It Matters Most
For any template multiple people will use, since loosely scoped variables get filled inconsistently across users.
F — Fallbacks: Plan for Messy Input
Fallbacks are the explicit instructions for what to do when the input is not what you hoped.
Why Fallbacks Are Non-Negotiable
Real inputs are empty, off-topic, oversized, or ambiguous. Without Fallbacks, the model improvises — often by fabricating content. A line like "If the input is empty, respond 'No content provided'" converts an unpredictable failure into defined behavior. Fallbacks are what make a template safe to run unattended. You can see them woven through every example in Prompt Templates: Real-World Examples and Use Cases.
When It Matters Most
For any automated or high-volume use, where messy inputs are guaranteed to arrive eventually.
T — Tests: Prove It Before You Trust It
Tests are the set of representative inputs and expected outputs you validate the template against.
Why Tests Complete the Framework
A template is not finished when it works once; it is finished when it passes a set of cases spanning typical, edge, and adversarial inputs. Tests turn "I think it works" into evidence and catch regressions when you change the template or the model changes underneath you. Five to ten cases catch the overwhelming majority of problems. The procedure for assembling them is in A Step-by-Step Approach to Prompt Templates.
When It Matters Most
Always — and re-run after every model update, because Tests are the only thing that catches silent drift.
Putting CRAFT Together
The components assemble in order. Define the Contract, set the Role, scope the Anchors, add the Fallbacks, and validate with Tests. A template missing any one has a predictable weakness: no Contract means inconsistent output, no Role means off-brand tone, loose Anchors mean unpredictable behavior, no Fallbacks mean fabrication under messy input, and no Tests mean undetected drift. Run any existing template against the five letters and the gaps name themselves.
CRAFT Applied: A Worked Example
To see the framework in motion, build a support-reply template with it. Contract: a reply under 100 words, warm and professional, no markdown. Role: "You are a support agent for a software company." Anchors: a single variable, {{customer_message}}, scoped to just the inbound message. Fallbacks: "If the message is off-topic or empty, respond that you need more detail; if it requests a refund, do not promise one — say it is escalated." Tests: eight historical tickets including an empty message and a refund request, each with an expected reply. Assembled in that order, the template is finished the moment all five are present and the test set passes — not when it happens to feel right. Notice how the Contract decided first made every later component obvious. The same five-part build, told as a team narrative, is in Case Study: Prompt Templates in Practice.
Using CRAFT to Diagnose, Not Just Build
The framework's second use is diagnostic. When a template misbehaves, walk the five letters and ask which is weak. Inconsistent formatting points to the Contract. Off-brand voice points to the Role. Erratic behavior across users points to loose Anchors. Fabrication on unusual inputs points to missing Fallbacks. A regression after a model update points to absent Tests. Because each failure mode maps to one component, CRAFT turns vague "this template is bad" complaints into specific, fixable diagnoses. This is the same one-failure-one-cause logic that makes the audit in The Prompt Templates Checklist for 2026 fast to run. Most underperforming templates are missing exactly one of the five, and naming which one is most of the work of fixing them.
Frequently Asked Questions
Why does Contract come before Role in CRAFT?
Because the output format constrains everything else — the role, variables, and fallbacks all exist to serve the output you want. Deciding the format first makes the other four components follow naturally. The acronym order reflects design order, not arbitrary letters.
Is CRAFT overkill for a simple personal template?
For a quick personal template you may only need Contract and maybe a Fallback. CRAFT scales: use all five for anything shared or production-bound, and a lighter subset for throwaway personal use. The value grows with how many people and how much volume the template serves.
How is CRAFT different from a generic prompt checklist?
CRAFT is a design framework with an assembly order, not just a list to verify after the fact. It tells you what to build and in what sequence, giving a team shared vocabulary. A checklist verifies a finished template; CRAFT guides building one from scratch.
Which CRAFT component do teams most often skip?
Fallbacks and Tests, in that order. Authors test with clean inputs and forget messy ones (skipping Fallbacks), and they validate once instead of building a standing test set (skipping Tests). Those two omissions cause most production failures.
Can I adapt CRAFT for non-text outputs like code or structured data?
Yes. The Contract becomes a schema or a code spec, and Fallbacks cover malformed or impossible inputs, but the five components still apply. CRAFT is about the structure of a reliable template, which holds regardless of what the output format happens to be.
Key Takeaways
- CRAFT names five template components: Contract, Role, Anchors, Fallbacks, Tests.
- Contract comes first because the output format constrains every other component.
- Role anchors tone and domain with a single cheap, high-impact line.
- Anchors must be few and tightly scoped; loose variables invite inconsistency.
- Fallbacks convert messy-input failures into defined behavior, making templates safe to run unattended.
- Tests complete the framework and are the only defense against silent model drift.