FORGECOURSE ForgeMind AI · Hands-On Portfolio
HO4 · Sample 05 · Delivery-promise checker

The One-Shot Rebuild

Support promises delivery dates that operations cannot hit, and every missed promise is a refund. Rahul asks Claude for a checker that returns the date they can actually commit to. It takes 14 turns — because time rules are where everyone's assumptions quietly differ. Then he writes them down, folds them into one prompt, and rebuilds it in a fresh chat in one message.

THE TOOL The checker he was trying to get — try 5:01pm on a Saturday and watch it compound

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.

Delivery-promise checker working
BUILD 1 The messy way — 14 turns

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.

STEP 2 The corrections log

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.

Working daysWe dispatch Monday to Saturday. Sunday is not a working day.

Cut-off5pm. After 5pm the order dispatches the next working day. 5:00pm exactly still makes the cut — it is 'after 5pm' that slips.

Dispatch ≠ transitThe dispatch day is not a transit day. Transit starts the next working day.

Transit is working days tooSunday never counts — not for dispatch and not for transit. The same rule, and it must be said in both places.

ZonesMetro 2 days · Tier-2 3 days · Rest of India 5 days.

HolidaysNo dispatch, no transit. An order placed on a holiday dispatches the next working day.

Compounding orderApply cut-off → weekend → holiday, in that order, rolling forward until you land on a working day. Each rule was right alone; the order was never stated.

Never promiseNever land a delivery date on a Sunday or a holiday either.

Show the workingDispatch date, why, transit days, delivery date — support has to defend it on a call.

Paste-readyOne line support can paste straight into the customer chat.

STEP 3 The one-shot prompt

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 delivery-promise checker, so support stops promising dates that
operations cannot hit. No login, no backend, one screen.

INPUTS
- Order day of week and time
- Zone: Metro / Tier-2 / Rest of India
- Whether the coming Monday is a public holiday (a checkbox is fine for the demo)

RULES — state them ALL, and state the ORDER they apply in
1. WORKING DAYS: Monday to Saturday. Sunday is NOT a working day.
2. CUT-OFF: 5pm. After 5pm, the order dispatches the NEXT working day.
   5:00pm EXACTLY still makes today's cut. It is "after 5pm" that slips.
3. DISPATCH IS NOT TRANSIT: the dispatch day does not count as a transit day.
   Transit starts the next working day.
4. TRANSIT DAYS ARE WORKING DAYS TOO: Sunday never counts — not for dispatch and not for
   transit. (Yes, this is the same rule as #1. Say it in both places or it will only be
   applied in one.)
5. ZONES: Metro 2 transit days, Tier-2 3, Rest of India 5.
6. HOLIDAYS: no dispatch and no transit. An order placed ON a holiday dispatches the next
   working day.
7. COMPOUND THEM IN THIS ORDER: cut-off, then weekend, then holiday — rolling forward until
   you land on a working day. Each rule is easy alone; it is the ORDER that gets it wrong.
   Worked example: an order at 5:01pm on a SATURDAY, before a MONDAY holiday, dispatches on
   TUESDAY. (After cut-off -> Sunday closed -> Monday is a holiday -> Tuesday.)
8. Never land the delivery date on a Sunday or a holiday either.

OUTPUT
- The dispatch date and WHY (support has to defend it on a call).
- Transit days, and the delivery date.
- One paste-ready line support can drop into the customer chat.
BUILD 2 Fresh chat. One message.

She opened a new chat, pasted that one prompt, and got the same tool — working, first try. Same features, none of the archaeology.

Build 1 — the messy way
14
turns, each one prising a rule out of her head
Build 2 — one-shot
1
one message, in a fresh chat with no history
Feature parity
10/10
every rule survived the rebuild — because every rule was written down
Mon–Sat working days, no Sunday
5pm cut-off
5:00pm exactly still makes the cut
Dispatch day is not a transit day
Sundays excluded from transit too
Zone transit: 2 / 3 / 5 days
Holidays block dispatch and transit
Rules compound in the right order
Never promise a Sunday or holiday
Shows the working + a paste-ready line

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.

Make it your own
Pick a tool with real rules — caps, tiers, gates, rounding, cut-offs. A page with no rules produces no corrections, and the corrections log is the exercise.
Do not tidy up as you go. Build it messily on purpose, and let it be wrong. The wrongness is the data.
When it finally works, ask Claude to list every correction you gave it. That is your log, free.
Rebuild in a genuinely fresh chat. Re-using the old one proves nothing — the context is already in there.
If the rebuild misses a rule, you left it out of the log. Add it and go again. That gap is the most useful thing you will learn all week.