Prompt Frameworks

A prompt framework is a checklist with an acronym. Its only job is to stop you from leaving out the context, constraints, and success criteria the model would otherwise guess at.

Overview

Most prompts carry exactly one thing: the task. “Write a launch email.” “Summarize this.” That hands the model a blueprint that says “build a house” with no dimensions and no site plan, so it fills the gaps with defaults and you get something generic back. A framework is the named structure that makes you supply the rest — audience, tone, format, examples, what “good” looks like — before you hit enter.

The six below cover the range from three fields to six. Lighter ones (APE, RACE) get you most of the value in a fraction of the effort; heavier ones (CREATE, STOKE) buy finer control when the task demands it. None of them is “best.” The right one is the lightest framework that still forces you to specify what your task actually needs. This is a complement to prompt engineering and context engineering, not a replacement — the framework structures the input; the technique structures the reasoning.

Framework	Components	Reach for it when	Weight
APE	Action, Purpose, Expectation	You want a fast, one-shot answer you’ll refine anyway	Very light
RACE	Role, Action, Context, Expect	You need structure in 30 seconds for a daily task	Light
CO-STAR	Context, Objective, Style, Tone, Audience, Response	The output has to sound a specific way — content, copy, email	Medium
RISEN	Role, Instructions, Steps, End Goal, Narrowing	The task has a real order of operations to follow	Medium-heavy
STOKE	Situation, Task, Objective, Knowledge, Examples	Accuracy depends on domain knowledge the model lacks	Medium-heavy
CREATE	Character, Request, Examples, Adjustments, Type, Extras	Output must match a specific reference or style guide	Heavy

Supplying Essential Context

These frameworks make you fill every field up front — but you can’t specify a constraint you forgot you had, and the model can’t read what’s in your head. So it guesses. The move the acronyms skip: tell it to ask.

[Any framework prompt below]

Before you answer: if anything you need is missing — audience, constraints,
the real data, what "good" looks like — ask me for it first. Don't guess.
Ask your questions, wait for my answers, then produce the output.

That turns a one-shot into a short interview. Skip it on throwaway tasks; reach for it when a wrong guess is expensive. The strongest prompt isn’t the one with every field filled — it’s the one that knows to ask.

The Six

APE — Action, Purpose, Expectation

The lightest structure on the list. Three questions: what should the model do, why, and what should the result look like? The Purpose field is the differentiator — it keeps the output aimed at an outcome instead of producing something technically responsive but useless. Reach for APE on brainstorming, rapid iteration, and simple one-shot tasks. It’s also the mental floor under every heavier framework: when in doubt, you’re always answering the APE questions.

Action: List the early warning signs that a platform team is over capacity.
Purpose: I want to make a staffing case in next week's planning review.
Expectation: 8-10 observable signals, grouped by where they show up
  (delivery, on-call, team health), each phrased as something a manager
  could actually spot — not a feeling.

RACE — Role, Action, Context, Expect

Four fields, each a sentence. The minimalist structured prompt you reach for when speed beats fine-tuning. The Expect field does most of the work — defining what “good” looks like up front sharpens the output more than any other single addition. RACE is also the right starting point when you don’t yet know how complex the prompt needs to be: start here, and upgrade to a heavier framework only if the result isn’t specific enough.

Role: You're an engineering manager closing out a sprint retro.
Action: Turn the raw retro notes below into action items.
Context:
  - CI was red for two days and nobody owned getting it green.
  - The Acme migration slipped again; unclear who's blocked on whom.
  - Standups run 25+ minutes and turn into status theater.
  - Two people didn't know the sprint goal until mid-week.
  - On-call got paged nine times for the same flaky webhook.
Expect: Exactly 3 items, ranked by effort-to-impact, each with a named
  owner and a one-line "done looks like." No restating the complaints.

CO-STAR — Context, Objective, Style, Tone, Audience, Response

The content-and-copy default. Its explicit Style, Tone, and Audience fields prevent the most common content failure: the right message in the wrong voice for the reader. Reach for CO-STAR when the output has to land a certain way — marketing copy, announcements, anything where how it sounds shapes whether it works. The gap it leaves is process: there’s no field for multi-step reasoning, and no slot for examples.

Context: We're merging two teams into one stream-aligned team next month.
  People are anxious about reporting lines and whether roles change.
Objective: Announce the change and cut the uncertainty.
Style: Plain and specific. No corporate euphemism.
Tone: Calm and direct — honest about what's changing, clear about what isn't.
Audience: The 14 engineers across both teams.
Response: A ~200-word message I can post in Slack, ending with where to
  bring questions.

RISEN — Role, Instructions, Steps, End Goal, Narrowing

Built for tasks with a sequence. The Steps component is the point — defining the process explicitly stops the model from skipping or reordering operations in ways that lose information, the same instinct behind chain-of-thought prompting. End Goal anchors the output to a measurable result; Narrowing lets you add constraints after the broad task is defined, which matches how people actually think. Reach for RISEN on audits, technical documentation, code reviews, and any process-driven workflow.

Role: You're an org-design consultant working from Team Topologies.
  Interaction modes are defined here:
  https://nerdnoir.ai/concepts/teaming/team-topologies
Instructions: Audit the cross-team dependencies of the team described below.
Steps:
  1. List every dependency the team has on other teams.
  2. Classify each as collaboration, X-as-a-Service, or facilitating.
  3. Flag the ones creating wait states or hand-offs.
  4. Recommend a target interaction mode for each flagged dependency.
End Goal: A dependency map showing where flow is blocked and what to change.
Narrowing: Cross-team dependencies only — ignore intra-team coordination.
  Assume no headcount changes.
Team: The Checkout squad (6 engineers) owns the payment flow. They wait on
  the Platform team for every schema change, file tickets with a separate
  Fraud team for rule updates, and can't ship without the central Release
  team's sign-off. A shared QA pool tests their releases once a week.

STOKE — Situation, Task, Objective, Knowledge, Examples

The framework for when the model’s default training isn’t enough. The Knowledge component is what sets it apart — it’s where you inject the domain context, constraints, and specialized facts the model wouldn’t otherwise have. STOKE also splits Task (“what to do”) from Objective (“what the output needs to achieve in the real world”), which pushes the model toward outputs that are useful, not just correct. The cost: you have to know the domain well enough to fill the K field.

Situation: Our team's cycle time crept from 4 days to 11 over two quarters.
Task: Diagnose the most likely bottleneck.
Objective: A short, defensible explanation I can take to the team without
  hand-waving — something we can act on this week.
Knowledge: Apply Little's Law (WIP = throughput x cycle time). Our flow-metrics
  approach is here: https://nerdnoir.ai/resources/playbooks/flow-metrics-guide
  Our numbers: average WIP 23 items, throughput 7 items/week, 6 engineers,
  no WIP limits, and all code review funnels through the same two senior engineers.
Examples: Match the depth of these —
  "Review is the constraint: WIP sits at ~3x weekly throughput, so items queue
   behind the two reviewers. Cycle time tracks the review queue, not coding."
  "A cross-team dependency on the data platform adds a ~5-day wait per item;
   our cycle time is really their lead time in disguise."

CREATE — Character, Request, Examples, Adjustments, Type, Extras

The heaviest structure, and the only one with a dedicated Examples field. That’s its leverage — showing the model what good output looks like beats any volume of instruction, and CREATE bakes that few-shot move in. Reach for it when the output must match a specific reference: brand copy, documentation following a style guide, code matching existing patterns. The price is setup — finding or writing good examples takes time, and Adjustments versus Extras can blur on simpler tasks.

Character: You're a product coach who writes outcomes, not feature lists.
  What good looks like:
  https://nerdnoir.ai/concepts/product/impact-outcome-model/outcomes-over-outputs
Request: Rewrite each roadmap item below as an outcome statement.
Examples: Good outcomes look like —
  "New users complete a real task in their first session without contacting support."
  "Sales reps configure and send a quote in under 5 minutes, down from ~30."
  "On-call engineers resolve P2 incidents without escalating to the author."
  (Each is observable, behavioral, and testable.)
Adjustments: If an item can't be tied to a behavior change, flag it
  instead of inventing one.
Type: A two-column table — original output | reframed outcome.
Extras: Our current roadmap —
  - Ship SSO / SAML login
  - Launch the redesigned analytics dashboard
  - Add bulk CSV export
  - Migrate billing to the new provider

The Decision Matrix

Pick by task type and complexity, not by which framework is fashionable.

Task type	Simple / quick	Medium	High complexity
Content and copy	APE	CO-STAR	CREATE
Technical / analytical	RACE	RISEN	STOKE
Creative / brainstorming	APE	CO-STAR	CREATE
Process-driven	RACE	RISEN	RISEN
Domain-expert	RACE	STOKE	STOKE
Code generation	APE	RISEN	STOKE
Data analysis	RACE	RISEN	STOKE

Rules of thumb: need tone and audience control, use CO-STAR or CREATE. Need to define a process, use RISEN. Need to inject domain expertise, use STOKE. Need examples, use CREATE or STOKE. Need it fast, use APE or RACE. Not sure, start with RACE and upgrade if the output isn’t specific enough.

Don’t Worship the Acronym

Frameworks are mental models, not templates to obey. Experienced practitioners cherry-pick: add a Steps section to a RACE prompt when the task has a sequence, bolt STOKE’s Knowledge onto RISEN when a process needs domain context, drop examples into CO-STAR when format consistency matters. The goal is never framework purity — it’s information completeness. When a prompt gives the model everything it needs to produce exactly the output you want, the framework has done its job. Catch yourself reaching for fields from another framework, and you’ve already outgrown the one you started with. Use them long enough and you stop needing the acronyms at all.

Resources

• Prompt Engineering — the underlying practice these frameworks structure
• Context Engineering — supplying the right background, which several frameworks (STOKE’s Knowledge, CO-STAR’s Context) make explicit
• Meta-prompt Engineering — the other side of the conversation: have the model critique and sharpen the prompt itself
• Few-Shot Example Integration — the library-scale version of the Examples field in CREATE and STOKE: selecting the right exemplars per task instead of pasting one in by hand
• Effective AI — where these frameworks get applied to real work in Session 2