Reasoning plan then execute

Plan Then Execute

What this technique is

This is not a prompt trick, a jailbreak, or a way to make a model "smarter" than it is. It is a discipline: instead of producing an answer in one pass, the model is required to (1) build an explicit plan broken into small, checkable sub-steps, and (2) execute that plan one step at a time, verifying each step before moving to the next. This closes the two most common failure modes of single-pass answers: skipping a step that was actually needed, and silently propagating an early mistake all the way into the final answer.

It does not add knowledge or capability the model doesn't have. It stops the model from wasting the capability it does have on an unstructured, all-at-once guess.

When to use it

Trigger this skill when:

• The task has more than one dependent step (step B needs the result of step A).
• The task is ambiguous enough that jumping to conclusions risks solving the wrong problem.
• The task is high-stakes (numbers, code, legal/financial claims, anything the user will act on) where a wrong intermediate step is expensive.
• The user explicitly asks to "show your reasoning," "think step by step," or "plan before answering."

When to skip it

• Single-fact lookups, trivial rewrites, or one-line questions with no dependent steps — forcing a plan here is pure overhead.
• Purely open-ended creative tasks with no correctness criterion (a light plan can still help structure the piece, but full step-by-step verification does not apply).

Inputs required

Before starting, gather:

1. The task — the exact question or job to do, verbatim.
2. Constraints — format, length, deadline, tools allowed, anything the answer must respect.
3. Success criterion — how you (or the user) will know the final answer is correct. If not given, infer it and state the assumption explicitly.
4. Step budget (optional) — a max number of sub-steps, to stop over-decomposition on simple tasks.

Procedure

1. Restate the task in one sentence, in your own words. If anything is ambiguous, name the assumption you are making instead of silently guessing.
2. Decompose the task into an ordered list of sub-steps. Each sub-step must be:
   • Small enough to verify on its own.
   • Dependent only on outputs of earlier steps, never on steps that come later.
   • Written as an action ("compute X," "check Y holds," "extract Z"), not something vague like "think about X." Aim for 3–7 steps. If you need more than ~7, the task is probably two tasks — say so and split it.
3. Execute steps one at a time, in order. For each step: a. State the step. b. Solve only that step, using only information available so far. c. Check the result against the success criterion for that step (right type/unit/shape, consistent with earlier steps). If the check fails, stop and redo that step before moving on — never carry a suspect result forward.
4. Assemble the final answer from the verified sub-step outputs. Do not re-derive it from scratch in one pass — it must be a direct composition of what was already solved and checked.
5. Final check: re-read the original task and confirm the final answer actually answers it (not a nearby question), respects all stated constraints, and matches the success criterion.

Output format

Always structure the response in three labeled sections, in this order:

## Plan
1. <sub-step 1>
2. <sub-step 2>
...

## Execution
Step 1: <restate> → <result> → check: <pass/fail + why>
Step 2: <restate> → <result> → check: <pass/fail + why>
...

## Final Answer
<the answer, composed from the checked steps above>

If a step fails its check, show the retry inline (Step 2 (retry): ...) rather than silently deleting the failed attempt — this keeps the reasoning auditable.

Worked example

Task: "A bakery sold 45 items today — croissants at $3 and muffins at $2 — for a total of $115. How many of each did they sell?"

## Plan
1. Define variables for the two unknowns.
2. Write the two equations the problem gives us.
3. Solve the system for one variable.
4. Solve for the second variable.
5. Verify both equations hold with the found values.

## Execution
Step 1: Let c = number of croissants, m = number of muffins. → defined → check: two unknowns, matches the two unknowns in the problem — pass.
Step 2: c + m = 45 (total items); 3c + 2m = 115 (total revenue). → two equations → check: units match (items vs. dollars), consistent with the problem statement — pass.
Step 3: From step 2's first equation, m = 45 − c. Substitute into the second: 3c + 2(45 − c) = 115 → 3c + 90 − 2c = 115 → c = 25. → c = 25 → check: integer, ≤ 45 — pass.
Step 4: m = 45 − 25 = 20. → m = 20 → check: c + m = 45 — pass.
Step 5: Verify revenue: 3(25) + 2(20) = 75 + 40 = 115. → matches the given total — pass.

## Final Answer
25 croissants and 20 muffins.

Why this works on a cheap model

A small/cheap model has roughly the same per-token arithmetic and language ability as a large one for short, local reasoning — what it lacks is the tendency to hold a long chain of dependent reasoning together unprompted, so it drifts or skips checks under pressure to just "answer already." Forcing an explicit plan plus a checkpoint after every step gives it externally-imposed structure that substitutes for the implicit self-monitoring a bigger model tends to do on its own. The model is not made more capable — it is stopped from squandering the capability it already has on one unchecked pass.