Chain-of-Thought Prompting templates that force step-by-step reasoning, so you stop getting confident but wrong answers from Claude, GPT-4, Gemini, or DeepSeek.
Generic prompts fail because LLMs pattern-match to the most statistically likely response, not the logically correct one. Without explicit scaffolding, the model compresses reasoning into a single token prediction — which works for simple facts but collapses on multi-step problems. Chain-of-Thought Prompting fixes this by externalizing the reasoning process, forcing the model to show its work before committing to an answer.
I've tested these templates across Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro, and DeepSeek-V3. They work consistently because they exploit each model's training on step-by-step problem-solving. Below are three production-ready templates.
Why generic prompts fail at multi-step reasoning
The failure mode is specific: the model generates a plausible-sounding answer that skips intermediate calculations. Ask "What's 17% of 2,340 minus 89?" without prompting, and the model often guesses — the attention mechanism weights recent tokens, so the final number dominates. The intermediate arithmetic gets compressed into a single probability distribution.
Chain-of-Thought Prompting forces the model to allocate tokens to each reasoning step. That token budget is the entire trick. The model can't skip the multiplication step if you explicitly require it to write out the intermediate result. This isn't prompt magic — it's giving the model permission to use more compute on the problem.
Template 1: The Step-by-Step Auditor
Use this for code reviews, bug diagnosis, or any task where you need verifiable reasoning.
You are analyzing a problem step by step. Do not provide a final answer until you have completed all reasoning steps.
Problem: [INSERT YOUR PROBLEM STATEMENT]
Follow this exact structure:
1. RESTATE the problem in your own words. If you cannot restate it precisely, say so.
2. LIST the constraints and assumptions. Mark anything ambiguous.
3. BREAK the problem into 3-5 sub-problems. Label them A, B, C.
4. SOLVE each sub-problem independently. Show all arithmetic or logic.
5. COMBINE the sub-solutions into a final answer.
6. VERIFY the final answer against the original problem. Note any discrepancies.
If you find an error in step 4 or 5, go back and fix it before answering.
Placeholders: [INSERT YOUR PROBLEM STATEMENT] — be explicit. "Why is my API returning 500s?" is too vague. Instead: "Why does my Express route return 500 when the request body contains a nested user.profile object but works with flat objects?" The template works best when the problem has discrete, checkable steps.
Template 2: The Constraint-First Planner
This one's for architecture decisions or anything with trade-offs. It forces the model to rank constraints before proposing solutions.
You are a systems architect. For the following requirement, reason through the design space before recommending anything.
Requirement: [INSERT REQUIREMENT]
Process:
1. ENUMERATE at least 5 constraints (performance, cost, maintainability, team skill, time-to-market).
2. RANK the constraints by importance. Justify the ranking.
3. For each constraint, list what happens if it is violated.
4. PROPOSE 2-3 candidate approaches. For each, walk through:
- How it satisfies the top 3 constraints
- Where it fails the remaining constraints
- The implementation cost in hours
5. SELECT one approach. Write a paragraph explaining why the ranking in step 2 led to this choice.
6. LIST the top 3 risks of your chosen approach and how you'd mitigate them.
Reason explicitly. Do not skip any step.
This works because it converts "what should I build?" into a decision tree. The model can't default to "it depends" — you've forced it to commit to a ranking and defend it.
Template 3: The Recursive Debugger
For edge cases where the first answer is likely wrong. This handles problems with hidden assumptions.
You are debugging a complex issue. Assume your first instinct is wrong.
Symptom: [DESCRIBE THE SYMPTOM]
Context: [PROVIDE RELEVANT CONTEXT]
Follow this protocol:
1. GENERATE a hypothesis for the cause. Write it down.
2. ASSUME the hypothesis is wrong. Generate 3 alternative hypotheses.
3. For each hypothesis, describe what evidence would CONFIRM it and what evidence would REFUTE it.
4. SELECT the hypothesis with the most specific, testable predictions.
5. WALK THROUGH the selected hypothesis step by step, identifying where the failure occurs.
6. PROPOSE a diagnostic test that would isolate the failure point.
7. If the diagnostic test would cost more than 30 minutes, propose a faster but less precise test.
Do not suggest fixes until step 6 is complete.
The key here is step 2 — forcing the model to argue against itself. This catches the classic LLM failure where it latches onto the most common cause (usually "cache invalidation" or "race condition") without checking fit.
How to adapt these for your own codebase
Three concrete adjustments:
-
Inject your stack into the problem statement. Append "This is a Node.js 20 / PostgreSQL 16 / Redis 7 codebase. Consider connection pooling, transaction isolation levels, and cache invalidation patterns." The model will use this context to prune irrelevant hypotheses.
-
Make the verification step explicit about your test suite. Add: "Verify against the existing test suite in
tests/— list which specific test files would catch a regression." This anchors the reasoning to your actual code. -
Set a token budget per step. Add "Keep each step under 50 words" or "Step 4 must include exact numbers, no approximations." Models respect explicit constraints on output length, which prevents rambling.
Do these prompts work with any LLM?
Not equally. Claude 3.5 Sonnet and GPT-4o handle all three templates well — they've been heavily trained on step-by-step reasoning data. Gemini 1.5 Pro works but occasionally skips steps if the problem is long; you may need to add "Repeat: do not skip steps" at the end.
DeepSeek-V3 is the outlier. It follows the structure but produces terser intermediate steps — you'll get correct answers but less insight into the reasoning. If you need the reasoning output for documentation or teaching, stick with Claude or GPT-4. For pure answer accuracy, DeepSeek works fine.
The templates degrade gracefully with older models (GPT-3.5, older Llama versions) — they'll follow the structure but the intermediate reasoning quality drops. You get the format without the depth.
One adjustment improves these prompts more than any other: always specify the output format for the final answer. Add "End with: 'Final Answer: [one-sentence response]'" to every template. It forces the model to separate reasoning from conclusion, making both easier to verify. Without that, models bury the answer in the reasoning, and you're back to parsing prose instead of checking logic.