Chain-of-Thought Prompting
Work a full example
A worked project proves the method by showing decisions, failures, corrections, and evidence.
Before you start
Why this matters
Without opening an AI tool, write the acceptance test for this job: make a multi-constraint laptop recommendation auditable without requesting hidden reasoning. Name one fact that must be exact, one judgment a person must make, and one condition that should stop the workflow. Compare your answer with the professional standard below; the gap is what you should practice.
1Learn the idea
Read
Project brief
The project is to build an auditable three-option decision brief with evidence table, formula, sensitivity test, recommendation, and open questions. The user is a college buyer who must verify seller claims. Definition of done: the intended action is clear, the candidate uses approved evidence, blocking safety checks pass, and another person can reproduce the key result.
Stage 1: prepare
Create the job card and collect candidate options, authoritative specifications, weighted criteria, constraints, missing facts, calculation method, and required output format. Remove or replace prohibited material: do not include account details, private purchase history, or personally sensitive constraints unless they are necessary and safe to share. Add one ordinary case, one boundary case, and one hostile or misleading case. Record unknowns instead of filling them with plausible guesses.
Stage 2: draft
Compare three laptops for college using price, measured battery life, weight, and required-software compatibility. First output a short comparison plan and evidence table. Then recommend one in under 150 words with three deciding facts. Finally list unknowns to verify on seller pages. Give concise rationale, not private hidden reasoning.
The first candidate should be A criteria table, explicit unknowns, a short recommendation tied to three inspectable facts, and a verification checklist. In this worked run, imagine it also exhibits one realistic defect from this set: equating longer rationale with truth; post-hoc justification; invented specifications; hidden weighting; arithmetic that cannot be reproduced. Do not hide the defect. Mark the exact criterion it violates and decide whether the cause belongs to context, instruction, model capability, or the surrounding process.
Stage 3: repair narrowly
Issue a targeted revision:
Revise only the failed criterion identified below.
Preserve all verified content and the original output contract.
Do not add facts or assets.
Return the corrected artifact plus a one-line change note.
Failed criterion: [paste criterion and evidence]
A narrow repair keeps the review surface understandable. If the model cannot repair without new authoritative information, pause and obtain that information.
Stage 4: verify and release
Now open authoritative product pages, recalculate weighted scores, check units and model variants, test software requirements, and see whether the recommendation changes under reasonable weights. Record pass/fail evidence for each criterion and have the named reviewer make the release decision. Ask for visible work products—plans, formulas, evidence tables, assumptions, and checks. A model's private reasoning is neither required nor a substitute for proof. Save limitations in language the audience can understand.
Read
Retrospective
The durable deliverable is not only the final result. It is a reasoning audit card containing decomposition, evidence, concise rationale, calculations, assumptions, and independent checks. Write what surprised you, which check found it, what you changed, and which control should become the default. A clean retrospective distinguishes a prompt improvement from a data, tool, or policy change.
Continue learning · glossary & guides
- Can the reviewer see the failed first attempt and why the correction was justified?
- Does the release packet contain evidence, ownership, and known limitations?
- Reference · Related concept
- Previous
- Next