Chain-of-Thought Prompting: When Reasoning Steps Actually Help

A model generates text one chunk at a time, and each chunk is conditioned on everything already written. When it writes its reasoning first, that reasoning becomes context for the final answer. In effect, the model gives itself better inputs.

This is why CoT helps on problems with dependent steps: if step three depends on step two, writing step two down makes step three more reliable. It is also why CoT does nothing for tasks with no dependent steps — there is nothing to condition on.

• Multi-step arithmetic and unit conversion — pricing, margins, scaling recipes, schedules.
• Logic and constraint satisfaction — seating plans, rota conflicts, eligibility rules.
• Diagnosis — debugging code, root-cause analysis, "why is this metric down".
• Planning with trade-offs — sequencing work under a deadline or budget.
• Evaluation against a rubric — scoring content, comparing two options fairly.
• Ambiguity detection — finding conflicting requirements in a spec.

• Factual recall — reasoning does not create knowledge the model lacks.
• Translation and tone rewriting — the transformation is direct, not stepwise.
• Formatting and extraction — converting text to JSON needs precision, not deliberation.
• Creative generation — visible reasoning often flattens voice and produces safer, duller prose.
• Short classification — a one-line label does not need a paragraph of justification unless you need auditability.

On these, CoT costs tokens, adds latency, and buries the answer you wanted.

Weak: "Solve this. Think step by step."

This leaves the shape of the reasoning entirely to the model, which often produces a narrated version of the same shortcut it would have taken anyway.

Structured:

"Work through this in four labelled stages. 1) Restate the problem and list every given constraint. 2) List the unknowns and what each depends on. 3) Solve in order, showing each calculation. 4) State the final answer, then check it against every constraint from stage 1 and say explicitly whether each is satisfied."

The structured version forces a verification pass, which is where most of the real accuracy gain comes from.

1. Calculation with verification

"Compute [task]. Show each step with its numbers. After the result, recompute it by a different method and state whether the two agree. If they disagree, say so and find the error."

2. Diagnosis

"Here is the symptom: [symptom]. Here is the context: [context]. List the five most plausible causes ranked by likelihood. For each, give the evidence for it, the evidence against it, and the cheapest test that would confirm or eliminate it. Then recommend which test to run first."

3. Quiet reasoning, clean answer

"Reason through this carefully in a section titled WORKING. Then, under a section titled ANSWER, give only the final result in three sentences or fewer, with no reasoning. Keep WORKING under 200 words."

The third template is the one most professionals settle on: you keep the accuracy benefit and get a copy-pasteable answer at the bottom.

The research-grade version of CoT runs the same prompt several times and takes the majority answer. That is expensive. A cheaper approximation inside one prompt:

"Solve this twice using two genuinely different approaches. Label them Approach A and Approach B. Compare the two results. If they differ, identify which is wrong and why, then give the final answer."

This catches a large share of single-pass arithmetic and logic errors without multiple API calls.

CoT is not a competitor to CRAFT, RTF, or RACE — it is a modifier you attach to the instruction portion of any of them. Keep your role, context, and format definitions exactly as they are, then add the reasoning stages inside the task section.

A practical rule: define the output format after the reasoning instruction. Models tend to honour whichever formatting constraint appears closest to the end of the prompt.