Loose advice about staged reasoning is useful until you face a genuinely complex task, at which point you need a model you can apply the same way every time. A named framework gives you that. It turns a collection of good habits into a repeatable procedure you can run, teach, and improve.
This article introduces DECIDE, a six-stage model for designing multi-step reasoning prompts. The name is a memory aid for the stages: Define, Enumerate, Collect, Instruct, Divide, Evaluate. Each stage answers one question, and the stages run in order because each depends on the one before it.
A framework is only worth its name if it tells you not just what the stages are but when to apply each and when to skip it. The sections below cover both, so you can scale the model up for hard problems and down for simple ones without losing its logic.
Define: State the Target
Every staged prompt starts by naming what success looks like.
What this stage does
You write a short description of a correct, complete answer and the format it should take. This becomes both the model's target and your eventual test.
When to apply it
Always. Even the simplest prompt benefits from a clear target, and complex ones fail without one. If you cannot complete this stage, you do not yet understand the task well enough to delegate it, a point the step-by-step approach makes early.
Enumerate: Find the Steps
Next you identify the stages a careful human would work through.
What this stage does
You list the sub-problems in plain language and note which depend on which. This is the skeleton the rest of the prompt fills in.
When to apply it
Whenever the task has more than one logical step. For genuine single-step lookups you can skip it, but the moment a problem requires checking conditions, comparing options, or computing intermediate values, enumeration is where reliability is won or lost.
Collect: Gather the Inputs
A model reasons only as well as the facts it is given.
What this stage does
You assemble every fact, number, and constraint the task needs and place them in the prompt, marking which constraints are hard and which are preferences.
When to apply it
Always, and most rigorously when inputs live in your head rather than in the prompt. Skipped or vague inputs are the leading cause of confident wrong answers, as documented in the common mistakes article.
Instruct: Write the Reasoning Steps
Now the skeleton becomes wording.
What this stage does
You convert the enumerated steps into explicit, ordered instructions, sequenced so every step's inputs exist before it runs, and you ask for reasoning before the conclusion.
When to apply it
Whenever you completed the Enumerate stage. The two are paired: enumeration finds the steps, instruction writes them. Named, ordered steps are what give staged prompts their consistency, the core argument of the best practices guide.
Divide: Decide on One Call or Several
Some tasks belong in a single prompt; others should be split.
What this stage does
You judge whether the task should run as one prompt or as a pipeline of separate calls, each handling one stage and feeding the next.
When to apply it
For high-stakes or hard-to-debug tasks, divide. Separate calls are individually testable, so when something breaks you know which stage failed. For low-stakes work, keep it as one prompt to save calls and latency. The case study shows this judgment playing out in practice.
Evaluate: Test, Trim, and Document
The final stage closes the loop.
What this stage does
You run the prompt against known-answer cases, locate the breaking step on any failures, trim steps that do not change outcomes, and document why each surviving step exists.
When to apply it
Always for anything you will reuse. Evaluation is what converts a prompt that looks good into one you can trust, and it is the stage most often skipped under time pressure. Skipping it means shipping a hypothesis you never tested.
Running the Framework End to End
Seeing the stages listed is one thing; watching them flow into each other clarifies why the order is not arbitrary.
A worked pass through DECIDE
Suppose you need a prompt that decides whether an incoming lead is worth a sales call. You Define success: a yes-or-no verdict with a one-line reason. You Enumerate the steps a salesperson would take: check the company size, check the stated budget, check the timeline, then weigh them. You Collect the inputs: the lead's form fields, your qualification thresholds, and which of those thresholds are firm. You Instruct the model with those steps in order, asking for reasoning before the verdict. You Divide and decide a single call is enough here, because the task is short and low-stakes. You Evaluate against twenty past leads whose outcomes you know.
How the stages catch each other's gaps
Notice how a weakness in one stage surfaces in the next. If your Define stage was vague, the Evaluate stage has no clear target to test against. If you skimped on Collect, the Instruct stage produces steps that reference inputs the model does not have. The framework's order is a series of checks, each stage exposing whatever the prior one left unfinished.
Scaling the Framework Up and Down
DECIDE is meant to flex. The same six stages serve a one-line prompt and a multi-call production pipeline, but the effort you spend on each shifts with the stakes.
Lightweight for low stakes
For an exploratory prompt, you might spend thirty seconds on Define, skip Enumerate and Divide entirely, and do a quick eyeball check in place of a formal Evaluate. The framework still ran; it simply ran lean. This is the correct response to a simple task, and over-applying the stages here is the over-engineering trap the common mistakes article warns against.
Heavyweight for high stakes
For a prompt that routes real money or makes customer-facing decisions, every stage gets deliberate attention. Enumerate might involve interviewing a domain expert. Divide might split the task into a tested pipeline. Evaluate might run against a hundred cases with a tracked accuracy number. The framework scales by deepening each stage, not by adding new ones, which is what makes it teachable.
Frequently Asked Questions
Why does the framework run in a fixed order?
Because each stage depends on the previous one. You cannot enumerate steps without a defined target, cannot instruct without enumerated steps, and cannot evaluate without something built to test. The order is the logic, not a convenience.
Can I skip stages for simple tasks?
Yes. Enumerate and Divide are skippable for single-step lookups. Define, Collect, and Evaluate are worth doing for almost any reusable prompt, because they prevent the failures that cost the most. Scale the framework to the task's difficulty.
How is DECIDE different from just following good habits?
The habits are the same; the framework makes them repeatable and teachable. Naming the stages lets you apply them the same way every time, hand them to a teammate, and know exactly which stage to revisit when a prompt misbehaves.
Which stage do people skip most often?
Evaluate. It comes last, it requires building a test set, and it is the easiest to rationalize away when a prompt already looks good. Skipping it is also the leading reason prompts that seem fine fail in production.
Does the framework work for non-reasoning prompts too?
The Define, Collect, and Evaluate stages help almost any prompt. Enumerate, Instruct, and Divide are specific to tasks that benefit from staged reasoning, so for simple generation or lookup prompts you would lean on the general stages and skip the reasoning-specific ones.
Key Takeaways
- DECIDE names six stages, Define, Enumerate, Collect, Instruct, Divide, Evaluate, that turn good habits into a repeatable procedure.
- The stages run in order because each depends on the one before it; the order is the logic, not a convenience.
- Define, Collect, and Evaluate apply to nearly any reusable prompt, while Enumerate, Instruct, and Divide are specific to staged reasoning.
- The Divide stage decides between a single prompt and a testable pipeline of separate calls based on stakes and debuggability.
- Evaluate closes the loop by testing against known answers, trimming dead steps, and documenting why each remains.
- A framework earns its name by telling you when to apply and when to skip each stage, letting you scale it to the task.