The CRISPE Framework: What It Actually Stands For

TL;DR: The CRISPE framework is Capacity and Role, Insight, Statement, Personality, Experiment. It has six letters and five components because Capacity and Role covers both C and R. Matt Nigh published it on GitHub on 7 February 2023. Several widely-shared blog posts expand the acronym differently, and those expansions are not the original.

What Is the CRISPE Framework?

The CRISPE framework is a five-part structure for writing an AI prompt: you tell the model what expertise to bring, what background it needs, what to do, how to sound, and how many different attempts to hand back.

Those five glosses are close to verbatim from the source, which matters more than it sounds, because the second thing you find when you search for CRISPE is four other people's versions of the same acronym.

The component that makes CRISPE distinct is Experiment. Nearly every prompt framework in circulation covers role, context, task, and tone in some arrangement. CRISPE is the only common one with a named slot that says give me several of these. That single line is the reason to reach for it, and it is also the reason it is wrong for about half the prompts you write.

Who Created CRISPE, and Where Is the Original?

Matt Nigh created it, and the original is a GitHub README, first published on 7 February 2023. The commit is literally titled add CRISPE.

The repository is mattnigh/ChatGPT-Free-Prompt-List (accessed 27 August 2026). It was created on 14 January 2023 under the name ChatGPT3-Prompt-Engineering and has been renamed at least twice since, which is why old links to it redirect. In the README as it stood in February 2023, Nigh wrote:

"I created the below framework (CRISPE) for my own use and experimentation of ChatGPT."

That sentence is the whole attribution question settled in nineteen words. It is preserved in the commit-pinned README from 10 February 2023 and independently in an Internet Archive snapshot taken 10 February 2023 (both accessed 27 August 2026). Two separate systems, same text, same week.

Why Does CRISPE Have Six Letters but Five Components?

Because the first component is called "Capacity and Role," which swallows both the C and the R. And the reason it is called that is visible in the commit history: Nigh renamed it twice in the framework's first 48 hours.

The public record runs like this, all times UTC, all from the repository's own commit log:

The version that spread across the internet is the third one, and it has been stable ever since, including in the 2025 rewrite. But the first published version used a different word for C entirely and headed its own section with a five-letter acronym. Anyone who tells you CRISPE has always meant one fixed thing has not looked.

I checked the 9 February wording against an Internet Archive snapshot from 9 February 2023 (accessed 27 August 2026), which shows "Capacity" standing alone, without "and Role." The archive and the commit log agree on the intermediate state, so this is not a rendering artifact.

What Does Each CRISPE Letter Do in Practice?

Each letter answers a question the model would otherwise have to guess at. The fastest way to see that is to build one prompt across all five, adding a line at a time, and watch what each line removes from the guesswork.

The task: a 900-word explainer about database indexing, for a company engineering blog.

C and R: Capacity and Role

What role (or roles) should the model act as? Note the plural in the original. Nigh's own example stacks two roles, a subject expert and a writer, which is the trick most people miss.

Capacity and Role: Act as a backend engineer with ten years of production
Postgres experience, and as an experienced technical blog writer.

One role gets you accuracy or readability. Two get you both, and the seam between them is where the good sentences live. This is the same mechanism covered in our post on persona prompting, applied at the top of a longer structure.

I: Insight

The behind-the-scenes background and context. Insight is not the task. It is everything the model needs in order to make good decisions while doing the task.

Insight: The audience is mid-level product engineers who write SQL daily but
have never read an EXPLAIN plan. Our blog has already covered query
optimisation basics, so assume that ground is covered. House style is short
paragraphs and no marketing language.

Every sentence there prevents a specific failure. Without the audience line you get either undergraduate definitions or unexplained jargon. Without the "already covered" line you get four hundred words retreading old ground.

S: Statement

What you are asking the model to do. Short, imperative, one deliverable.

Statement: Write a 900-word explainer on how B-tree indexes work and when
adding one makes a query slower rather than faster.

The most common CRISPE mistake is a Statement that has quietly absorbed the Insight, so the prompt says everything twice. Keep it to the ask.

P: Personality

The style, personality, or manner you want. Nigh's own example names four real people to blend, which is a stronger move than a list of adjectives, because "clear and engaging" means nothing and "write like Julia Evans" means something.

Personality: Direct and concrete. Lead with a real symptom a reader would
recognise, not a definition. No lists of three. Use second person.

E: Experiment

Asking the model to provide multiple examples to you. This is CRISPE's signature and its sharpest edge.

Experiment: Give me three different opening sections, each taking a different
angle: one starting from a slow query, one from a schema decision, one from a
production incident. Do not write the full article yet.

Notice what that does. It converts an evaluation problem into a comparison problem. Judging one opening in isolation is hard; picking between three is easy, and the second and third almost always wander further from the model's most predictable output than the first.

Assembled, the whole prompt reads as ordinary prose:

Act as a backend engineer with ten years of production Postgres experience,
and as an experienced technical blog writer. The audience is mid-level product
engineers who write SQL daily but have never read an EXPLAIN plan. Our blog has
already covered query optimisation basics, so assume that ground is covered.
House style is short paragraphs and no marketing language. Write a 900-word
explainer on how B-tree indexes work and when adding one makes a query slower
rather than faster. Be direct and concrete. Lead with a real symptom a reader
would recognise, not a definition. No lists of three. Use second person. Give me
three different opening sections, each taking a different angle: one starting
from a slow query, one from a schema decision, one from a production incident.
Do not write the full article yet.

CRISPE is a checklist, not a syntax. Labels help while you are learning and are unnecessary once you are not.

Which CRISPE Definitions Are Wrong?

Several widely-circulated ones. The acronym has drifted badly, and because almost nobody cites the source, the variants get copied forward as though they were equivalent. Here is what different pages currently publish, all accessed 27 August 2026.

Look at what the four divergent versions have in common with the original: two of them keep the word Role and nothing else, and juuzt.ai's shares not a single component. None of the four preserves the five-part structure, and none of them contains Experiment, which is the one component that makes CRISPE different from every other framework people compare it to.

The Praxis Library case is the most instructive, because both pages are on the same site. Its dedicated CRISPE page is faithful, and even explains that "the 'R' is embedded within the Capacity component rather than standing alone." Its CRISP page describes CRISPE as CRISP plus "Persona and Evaluation." They cannot both be right, and the faithful one is the one that agrees with the source.

Was CRISPE an Internal OpenAI Framework?

No. That claim appears on at least one prominent page and it does not survive contact with the record.

Parloa's prompt-engineering framework guide lists the components correctly as "Capacity/role, insight, statement, personality, experiment" and then states that CRISPE "was initially developed as an internal framework by OpenAI and has since found a broader audience in technical and strategic contexts" (accessed 27 August 2026). Against that we have a named individual saying "I created the below framework (CRISPE) for my own use," a timestamped commit called add CRISPE, and two subsequent commits visibly renaming the C component while the author settled on wording. That is what an individual's working notebook looks like, not an internal framework escaping a lab.

I also searched OpenAI's own properties for any page defining CRISPE and found none. Absence of evidence is weak on its own, but combined with a dated, attributed, publicly versioned origin, the OpenAI attribution has nothing holding it up.

The same page also glosses Insight as "surfacing a core idea," which inverts the original. In Nigh's version Insight is context you supply to the model, not an insight the model produces. Small drift, real consequence: readers following that gloss leave out the background the framework exists to capture.

When Is CRISPE Worth the Ceremony, and When Is It Overkill?

CRISPE earns its five components when the output is subjective, audience-facing, and you do not yet know what good looks like. It is overkill the moment the task has one correct-shaped answer.

Reach for CRISPE when:

• The result is judged on taste, not correctness: naming, positioning, opening lines, campaign angles.
• You are exploring rather than executing, and want options to react to.
• Tone genuinely changes the answer, not just its surface.
• You will spend real time editing the output, so a better starting point compounds.

Skip CRISPE when:

• The task is extraction, conversion, classification, or lookup. There is nothing for Personality to do and Experiment will manufacture false variety.
• You need one deterministic output to feed into something else, which is a job for structured output and a schema, not a personality line.
• It is a throwaway question. Writing five components to ask what a status code means costs more than the improvement is worth.
• You are running the prompt at volume through an API, where the Experiment step multiplies token cost on every call for variety no one reads.

That last one deserves emphasis. Experiment is a human-in-the-loop instruction. In an automated pipeline it is pure overhead unless you have written something downstream that actually chooses between the variants.

How Does CRISPE Compare to Other Prompt Frameworks?

CRISPE sits in the middle of the pack on size and is unique on one axis: it is the only common framework that builds iteration into the prompt itself.

If you want the shortest thing that reliably beats no framework at all, that is RTF: Role, Task, Format, three lines. If you are hardening a prompt your whole team will reuse and you need somewhere to put edge cases and scope, that is AUTOMAT. For the wider tour, our roundup of seven prompt frameworks covers CRAFT, CARE, RACE, BAB, TAG and CO-STAR side by side.

There is no framework tournament to win here. CRISPE, RTF and AUTOMAT are three different amounts of ceremony, and the skill is matching the ceremony to the stakes. The underlying habits are the same ones in our guide to writing better ChatGPT prompts; frameworks just stop you forgetting one.

14 Copy-Paste CRISPE Prompts

Every one of these fills all five components. Swap the bracketed parts and run.

1. Blog post outline

Capacity and Role: Act as a content strategist for B2B SaaS and an editor who
has shipped 500+ technical articles.
Insight: Target reader is a head of ops at a 50-200 person logistics company.
They are evaluating whether to build or buy a routing tool. We sell the tool but
this piece must be genuinely useful to someone who chooses to build.
Statement: Produce a section-by-section outline for a 2,000-word article on
build-vs-buy for routing software.
Personality: Practical and unsentimental. No thought-leadership voice.
Experiment: Give me three outlines with different organising principles: one by
cost, one by timeline, one by failure mode.

2. Cold outreach email

Capacity and Role: Act as a founder who has written cold email that got replies,
not as a sales copywriter.
Insight: Recipient is a VP Engineering at a Series B fintech. We noticed they
posted about on-call fatigue. Our product reduces alert noise. We have no mutual
connection and no case study in fintech yet.
Statement: Write a first-touch email under 90 words asking for a 15-minute call.
Personality: Plain, specific, slightly informal. No "hope this finds you well",
no bold claims we cannot back.
Experiment: Give me four versions with different opening lines, one of which
opens by admitting we have no fintech case study.

3. Code review

Capacity and Role: Act as a staff engineer who specialises in concurrency bugs
and reviews Go code daily.
Insight: This service handles 2,000 req/s. It was recently changed from a mutex
to a sync.Map and we have seen intermittent stale reads in staging. The team is
mid-level and will act on whatever you say, so be precise about severity.
Statement: Review the code below and identify anything that could produce a
stale read under concurrent access.
Personality: Terse. Reference line numbers. State severity before rationale.
Experiment: Give me two readings of the code: the most likely cause, and a
second, less obvious cause worth ruling out.

[paste code]

4. Product requirements doc

Capacity and Role: Act as a senior product manager who has shipped billing
systems, and as a technical writer.
Insight: We are adding usage-based pricing on top of existing flat-rate plans.
Existing customers must not be migrated automatically. Finance needs invoices to
reconcile with our current ledger. Engineering has six weeks.
Statement: Draft a PRD covering scope, non-goals, user stories, and open
questions.
Personality: Direct. Non-goals get equal weight to goals. Flag every assumption
explicitly rather than smoothing it over.
Experiment: Produce two versions of the scope section: one that ships in six
weeks, one that ships properly in twelve.

5. Customer support macro

Capacity and Role: Act as a support lead who has handled refund escalations, and
as a writer who keeps things short.
Insight: Customer is asking for a refund four days outside our stated window.
They have been a customer for two years. We can approve one-off exceptions but
must not imply the policy has changed.
Statement: Write a reply that approves the refund as a one-time exception.
Personality: Warm but not effusive. No apology stacking. One paragraph.
Experiment: Give me three versions at different warmth levels so I can pick by
account value.

6. Investor update

Capacity and Role: Act as a bootstrapped founder writing to a small group of
angels, and as someone who reads a lot of these.
Insight: Month was mixed. Revenue up 8%, churn up from 3% to 4.5%, one enterprise
deal slipped a quarter. Nothing is on fire. I want honesty without triggering
panic emails.
Statement: Write a monthly investor update covering metrics, the churn spike, and
what I am doing about it.
Personality: Calm, numerate, no spin. Lead with the bad number.
Experiment: Give me two openings: one that leads with revenue, one that leads
with churn. I want to see which reads more credible.

7. Literature review synthesis

Capacity and Role: Act as a research assistant trained in systematic review
methodology, and as a domain reader in behavioural economics.
Insight: I have twelve papers on default-effect interventions in retirement
savings. Sample sizes vary by two orders of magnitude. Three are pre-registered,
nine are not. I need to write a related-work section, not a meta-analysis.
Statement: Synthesise the twelve abstracts below into a thematic summary,
grouping by mechanism rather than chronology.
Personality: Neutral academic register. Attribute every claim to a specific
paper. Never merge two findings into one sentence.
Experiment: Offer two groupings: one by mechanism, one by strength of evidence.

[paste abstracts]

8. Landing page hero copy

Capacity and Role: Act as a conversion copywriter who has written for developer
tools, and as a developer who is sceptical of marketing.
Insight: Product is an error-tracking tool. The main competitor is well known and
cheaper at low volume. Our real advantage is that setup takes one line and we do
not sample events. Visitors arrive from a Hacker News post.
Statement: Write a hero headline, subhead, and primary CTA.
Personality: No superlatives, no "supercharge", no em-dash drama. A developer
should not wince.
Experiment: Give me five headline options across different angles: setup speed,
no sampling, price honesty, migration ease, and one that names the tradeoff.

9. Job description

Capacity and Role: Act as a hiring manager who has interviewed 200 engineers, and
as a writer who has seen how bad most JDs are.
Insight: Role is a senior backend engineer, fully remote, EU timezones, on a team
of four. We cannot match FAANG salary. We can offer genuine ownership and no
on-call rotation. We want people who have run something in production, not
people optimising for prestige.
Statement: Write a job description with responsibilities, requirements, and an
honest "this job is not for you if" section.
Personality: Human, specific, no corporate boilerplate. Say the salary band.
Experiment: Give me two versions: one conventional structure, one written as a
letter from the hiring manager.

10. Meeting notes to decisions

Capacity and Role: Act as a chief of staff who turns messy discussion into
decisions, and as an editor who cuts ruthlessly.
Insight: 50-minute product meeting, seven attendees, several tangents. Some
things were decided, some were debated and left open. Do not promote a debate to
a decision.
Statement: From the transcript below, extract decisions made, open questions, and
action items with owners.
Personality: Clinical. Table format. Mark anything ambiguous as "unclear" rather
than guessing an owner.
Experiment: Produce two passes: a strict one that only lists explicit decisions,
and a looser one that includes strong implications, clearly labelled.

[paste transcript]

11. Data analysis narrative

Capacity and Role: Act as an analytics lead who presents to executives, and as a
statistician who resists overclaiming.
Insight: Signup conversion dropped from 4.1% to 3.4% over six weeks. We also
shipped a redesign, ran a paid campaign, and had a two-hour outage in that
window. The data cannot separate these cleanly and the exec team wants an answer.
Statement: Write a one-page narrative explaining what we know, what we suspect,
and what we would need to measure to be sure.
Personality: Confident about uncertainty. Never assign a cause the data cannot
support.
Experiment: Give me three framings of the same evidence, ordered from most to
least conservative.

12. Lesson explainer

Capacity and Role: Act as a secondary school physics teacher with fifteen years
in the classroom, and as someone who remembers being confused by this.
Insight: Students are 15 years old, have covered forces and acceleration, and
consistently believe that heavier objects fall faster. Previous explanations
using equations did not shift the misconception.
Statement: Explain why objects of different mass fall at the same rate in a
vacuum, in under 400 words.
Personality: Conversational. Use one physical demonstration they could do with
classroom objects. No equations before the intuition lands.
Experiment: Give me three explanations built on different analogies, and say
which age group each suits best.

13. Incident postmortem

Capacity and Role: Act as an SRE who runs blameless postmortems, and as a writer
who keeps timelines legible.
Insight: 43-minute outage caused by a config change that passed review. The
reviewer was rushed before a deadline. Leadership will read this. The engineer
who shipped it is anxious about it and must not be named in a way that reads as
fault.
Statement: Write a postmortem with timeline, contributing factors, and remediation
items.
Personality: Blameless in structure, not just in wording. Describe systems and
conditions, never individuals.
Experiment: Give me two versions of the contributing-factors section: one focused
on process, one on tooling.

14. Podcast episode brief

Capacity and Role: Act as a podcast producer who books technical guests, and as
an interviewer who avoids obvious questions.
Insight: Guest spent eight years building payments infrastructure at a bank and
now runs a two-person consultancy. They have given the same three interviews
elsewhere already. Our audience is early-stage founders.
Statement: Write an episode brief with a through-line, six questions, and one
question they have never been asked.
Personality: Curious, specific, allergic to "so tell us about your journey".
Experiment: Give me three possible through-lines and rank them by how likely they
are to produce a story the guest has not told before.

What Are the Most Common CRISPE Mistakes?

Four, in the order I see them most.

Writing Insight that is really Statement. If your Insight block contains a verb telling the model to do something, it belongs one line down. Insight is a briefing; Statement is the ask.

Treating Personality as a synonym list. "Professional, engaging, clear, authoritative" is four words that cancel each other out. Nigh's own example named four specific writers to blend. Naming a real style, a real constraint, or a real thing to avoid does more than any adjective.

Setting Experiment too high. Ask for ten variants and you get three ideas and seven paraphrases. Three to five is where the marginal variant is still a genuinely different attempt.

Running Experiment on tasks with one right answer. If you ask for three variants of a factual summary, the model will produce variation somewhere, and the only place left is the facts. This is a reliable way to manufacture a hallucination from an otherwise safe prompt.

Is CRISPE Still Worth Learning in 2026?

Yes, but for a narrower reason than in 2023. Models have got dramatically better at inferring what you meant from a thin prompt, which has quietly retired a lot of prompt-engineering ceremony. What has not been retired is the part where you have to know what you want.

CRISPE's lasting value is that it makes you decide five things before you type: whose expertise, what background, which deliverable, what voice, and how many attempts. A 2026 model will forgive you skipping the first four. It cannot invent the fifth, because "give me three genuinely different attempts" is a request only you can make, and it is still the fastest route from a blank page to something you can react to.

Learn the original five. Check the source before you standardise a team on someone's variant. And drop the whole thing the moment the task has one right answer.