Knowing that staged reasoning helps is one thing. Sitting down and actually constructing a prompt that produces reliable results is another. This article is the second kind. It gives you an ordered process you can run start to finish, with each move building on the last.
The process below is deliberately sequential. You can skip steps once you are experienced, but the first several times through, follow them in order. Each one prevents a specific failure that tends to show up later if you rush past it.
Have a real task in mind as you read. The process is far more useful applied to something concrete than read in the abstract, so pick a problem you actually need solved and build along with the steps.
Move One: Write Down What a Good Answer Looks Like
Before you write a single instruction, define success.
Describe the ideal output
In one or two sentences, state what a correct, complete answer would contain. If you cannot describe it, the model cannot produce it. This description becomes your target and, later, your test.
Note the format you need
Decide now whether you need prose, a table, a number, a yes or no, or a structured list. Knowing the shape of the answer shapes every instruction that follows.
Move Two: Identify the Natural Steps
A staged prompt mirrors the steps a careful human would take. Find those steps.
List the sub-problems
Write out, in plain language, the stages required to get from the question to the answer. For a pricing decision that might be: gather the costs, project the usage, compute each option, compare, recommend. You do not need perfect wording yet, just the sequence.
Check the dependencies
Note which steps depend on earlier ones. If step three needs the result of step two, your prompt must preserve that order. Getting the order right is most of the work, a point the framework article develops in detail.
Move Three: Supply the Facts the Model Needs
A model cannot reason correctly from missing information.
Gather inputs explicitly
List every fact, constraint, and number the task requires, and put them in the prompt. Do not assume the model knows your specifics. Vague inputs produce vague reasoning, no matter how well structured the rest of the prompt is.
Mark what is fixed versus flexible
Tell the model which constraints are hard and which are preferences. "Must stay under budget" and "would prefer a shorter timeline" lead to different reasoning, and the model needs to know which is which.
Move Four: Write the Reasoning Instruction
Now you tell the model how to think.
Name the steps you found
Turn your step list from Move Two into explicit instructions: "First do X. Then do Y using the result of X. Then do Z." Named steps produce far more consistent reasoning than a generic "think carefully."
Ask it to reason before concluding
Make clear that the answer comes only after the steps. The whole point is to prevent the model from jumping to a conclusion, so the instruction must put reasoning first and the verdict last.
Move Five: Separate the Answer From the Work
Structure the output so you can use it.
Use a labeled final section
Ask for the conclusion under a clear heading like "Final Answer" or "Recommendation." This lets you or your software grab the answer without parsing the reasoning, and it lets a reader skim.
Keep the reasoning auditable
Even though you separate it, keep the reasoning in the response during development. You will need it to debug, as the examples article shows across several worked cases.
Move Six: Test on Real Cases
A prompt that looks good is not the same as a prompt that works.
Run three to five known examples
Take problems where you already know the right answer and run your prompt on each. Compare the model's output to the truth. This is the step most people skip, and it is the step that separates a prompt you trust from one you merely hope about.
Find the breaking step
When an answer is wrong, read the reasoning and locate the exact step that failed. That tells you precisely what to fix, whether it is a missing input, an ambiguous instruction, or a step in the wrong order.
Move Seven: Tighten and Trim
Your first working version is rarely your best.
Remove what does not help
If a step never changes the outcome, cut it. Every instruction you remove makes the prompt cheaper, faster, and easier to maintain. Lean prompts age better.
Lock in what works
Once a prompt passes your tests reliably, freeze it and document why each part exists. Future you will want to know which instructions are load-bearing before editing, a discipline the checklist reinforces.
Walking the Process on a Real Task
The seven moves are easier to trust once you see them applied to something concrete, so here is a single task carried through all of them.
The task
Suppose you need a prompt that decides whether to approve a discount request from a customer. In Move One you define success: an approve-or-deny verdict with a one-sentence reason. In Move Two you list the steps a manager would take, check the customer's account history, check the size of the requested discount against policy, check whether an exception is justified, then decide. In Move Three you supply the inputs: the account history, the discount policy thresholds, and which thresholds are firm versus negotiable.
The build and the test
In Move Four you name those steps in order, asking for reasoning before the verdict. In Move Five you put the verdict under an "Approval Decision" heading. In Move Six you run ten past requests with known outcomes and find the prompt approves a discount it should have denied, tracing the error to a vague threshold in Move Three. You fix the input, rerun, and it passes. In Move Seven you remove a redundant step that never changed the outcome. The whole pass takes under an hour and produces a prompt you can actually trust, which is the point.
Common Snags and How to Move Past Them
Even with a clear process, a few snags recur often enough to name.
When the steps feel obvious but the answer is still wrong
This usually means an input is missing or ambiguous, not that the steps are flawed. Before reworking the reasoning, recheck Move Three. The examples article shows repeatedly that confident wrong answers trace back to inputs far more often than to logic.
When the prompt works on tests but fails on new cases
Your test set is probably too narrow. Add the failing cases to it and rerun. A prompt is only as trustworthy as the variety of cases it has passed, so expanding coverage when reality surprises you is part of the process, not a sign it failed.
Frequently Asked Questions
How long should this process take the first time?
Plan on twenty to forty minutes for a real task. Most of that is Moves One and Two, defining success and finding the steps. The actual writing is quick once you know what the answer should look like and how to get there.
What if I cannot identify the natural steps?
That usually means you do not yet understand the problem well enough to delegate it. Work a couple of examples by hand first. The steps you take with pen and paper are the steps you put into the prompt.
Do I always need a labeled final answer section?
For anything you will read or process programmatically, yes. It costs nothing and saves you from hunting through reasoning to find the conclusion. The only exception is purely exploratory chats where you want the full thinking.
How many test cases are enough?
Three to five is a reasonable start for a single prompt. If the task is high-stakes or runs at scale, expand to a few dozen covering the tricky edge cases. The goal is enough coverage that a passing prompt genuinely earns your trust.
Can I reuse one prompt structure for different tasks?
The structure transfers well, but the steps and inputs are task-specific. Keep your seven-move skeleton and refill Moves Two and Three for each new problem rather than copying a whole prompt and hoping it fits.
Key Takeaways
- Start by writing down what a good answer looks like, because you cannot produce or test what you cannot describe.
- Identify the natural steps a careful human would take, and preserve their dependencies in your prompt's order.
- Supply every fact and constraint explicitly, marking which are hard requirements and which are preferences.
- Turn your step list into named instructions and put the final answer in a separate, labeled section.
- Test on three to five known cases and locate the exact step that breaks when an answer is wrong.
- Trim steps that never change the outcome, then freeze and document the prompt once it passes reliably.