Finance sends half of Divya's expense claims back, and each round trip costs a week. She asks Claude for a checker that flags a claim before it is submitted. It takes 12 turns — because the policy lives in a PDF nobody reads and in Divya's memory. Then she writes it down, folds it into one prompt, and rebuilds the checker in a fresh chat in one message.
This is what she ended up with. Every rule below it — the slabs, the cap, the order of operations — had to be dragged out of her head one turn at a time. Change the inputs and watch them fire.
Click through it. Notice what each turn actually is: not Claude failing, but a rule arriving late. Every correction is a piece of context that was missing from turn 1.
At the end of the messy chat she asked Claude one question: “list every correction I gave you in this chat.” Claude has the whole conversation in front of it, so the log costs almost nothing to produce — and this log is the context she was carrying in her head all along.
CapsMeals ₹800/day · Travel ₹5,000 · Hotel ₹4,000/night.
Meals — cap and payA meal over the cap is not rejected. We reimburse ₹800 and the employee absorbs the rest.
Hotels — rejectA hotel over ₹4,000/night is rejected outright and needs pre-approval. Same-looking cap, opposite behaviour — this is the rule no model will ever infer.
Travel — sign-offTravel over ₹5,000 is flagged for the manager, not rejected.
ReceiptsAnything over ₹2,000 needs a receipt. ₹2,000 exactly does not — the threshold is exclusive.
DatesEvery line needs a date. No date, no claim.
StalenessClaims older than 60 days are rejected.
Two totalsShow claimed and reimbursable separately. They are different numbers, and the gap is the whole point.
ShortfallState explicitly what the employee is absorbing.
StatesThree states, not one: OK · needs sign-off · rejected. Do not paint them all red.
OutputOne screen, no login, prints for the finance file.
The log, folded into a single message: role, spec, the rules, the order they fire in, the edge cases, the output format. This file is the real deliverable of HO4 — not the tool. The tool is just the proof that the context is complete.
Build a single-file HTML expense-claim checker. It does not just add up a claim — it checks it against policy BEFORE it is submitted, so finance stops sending things back. No login, no backend, one screen, prints cleanly. A claim is a list of lines. Each line has: category, amount, date, receipt attached (yes/no). Categories: Meals, Travel, Hotel, Other. POLICY — the caps look alike but they behave DIFFERENTLY. This is the important part. 1. MEALS — cap Rs 800 per day. Over the cap is NOT rejected: reimburse Rs 800 and the employee absorbs the rest. (Cap and pay.) 2. HOTEL — cap Rs 4,000 per night. Over the cap IS rejected outright and needs pre-approval. (Cap and reject.) 3. TRAVEL — over Rs 5,000 is FLAGGED for the manager's sign-off, but NOT rejected. (Cap and escalate.) Do not collapse these three into one behaviour. They are three different rules that happen to look like the same rule. 4. RECEIPTS — any line OVER Rs 2,000 needs a receipt. Rs 2,000 exactly does not. The threshold is exclusive. 5. DATES — every line needs a date. No date, no claim. 6. STALENESS — any line dated more than 60 days ago is rejected. OUTPUT - Each line with its own state: OK / NEEDS SIGN-OFF / REJECTED. Three states, three colours. Do not paint everything red. - TWO totals, clearly separate: CLAIMED and REIMBURSABLE. They are not the same number. - The SHORTFALL: exactly what the employee is absorbing, stated plainly. Recalculate live as lines are added or changed.
She opened a new chat, pasted that one prompt, and got the same tool — working, first try. Same features, none of the archaeology.
This is the whole lesson. Claude was never the bottleneck. The context was — it just arrived one turn at a time instead of all at once. Say it up front and the fourteen turns collapse into one.