FORGECOURSE
ForgeMind AI · Hands-On Portfolio
Done when
A single prompt rebuilds, in one shot and in a fresh chat, what first took you a dozen messy turns — and you can show the turn count that proves it.
What this is

Build a small tool in a Claude chat the way everyone actually does it: one vague prompt, then fix, fix, fix. It'll take you a dozen turns or more. Those turns were not Claude being slow. Every one of them was a rule you already knew — a cap, an edge case, the order things apply in — arriving late, one drip at a time. So write them all down, fold them into one prompt, open a fresh chat, and build the same thing in a single message. That collapse, from fourteen turns to one, is the whole of Module 7 in a number you produced yourself. Context is the lever.

Pick a problem statement

Each one is a small tool with real rules — slabs, caps, gates, rounding, cut-offs. That is deliberate: a tool with no rules produces no corrections, and the corrections are the exercise. These five are starting points — feel free to use any other tool of your own, as long as it has rules that live in your head. To see the finished shape, open its sample using the link on each card.

1Quote calculator
You quote by hand and it eats an evening a week. The pricing rules are all in your head — the slabs, the discount cap, what gets rounded — and they only come out when something is wrong.
Your task
  1. Build a quote calculator in a normal chat — pick services, set quantities, out comes the total with tax and terms.
  2. Build it the messy way. Let it be wrong. Fix it turn by turn until it actually works, and count your turns.
  3. Ask Claude to list every correction you gave it. That list is the context you were carrying in your head.
  4. Fold the list into one prompt, open a fresh chat, and rebuild it in a single message.
Open Sample 1
2Interview scorecard
Your panel scores candidates in their heads and the bar moves with the mood of the room. The rules that make it fair — weights, must-have gates, a threshold — have never been written down.
Your task
  1. Build an interview scorecard in a normal chat — rate each criterion, weight them, out comes a verdict.
  2. Build it the messy way and let it be unfair at first. Fix it turn by turn, and count your turns.
  3. Ask Claude to list every correction you gave it — the weights, the gates, the thresholds.
  4. Fold the list into one prompt, open a fresh chat, and rebuild it in a single message.
Open Sample 2
3Expense-claim checker
Finance sends half your claims back and each round trip costs a week. The policy lives in a PDF nobody reads — and in the head of the one person who knows which caps reject and which just pay less.
Your task
  1. Build an expense-claim checker in a normal chat — it flags what breaks policy before you submit.
  2. Build it the messy way. Let it flag the wrong things. Fix it turn by turn, and count your turns.
  3. Ask Claude to list every correction you gave it — the caps, the thresholds, the exceptions.
  4. Fold the list into one prompt, open a fresh chat, and rebuild it in a single message.
Open Sample 3
4Ad-budget planner
Every month you re-derive the same budget maths in a spreadsheet, and every month the blended cost per lead comes out subtly wrong — because the obvious way to calculate it is the wrong way.
Your task
  1. Build an ad-budget planner in a normal chat — split the budget, project the leads, show the blended cost.
  2. Build it the messy way and let the maths be wrong. Fix it turn by turn, and count your turns.
  3. Ask Claude to list every correction you gave it — the floors, the rounding, the real formula.
  4. Fold the list into one prompt, open a fresh chat, and rebuild it in a single message.
Open Sample 4
5Delivery-promise checker
Support promises dates that operations cannot hit, and every missed promise is a refund. Time rules are where everyone's assumptions quietly differ — the cut-off, the weekend, the holiday, and the order they apply in.
Your task
  1. Build a delivery-promise checker in a normal chat — order time in, the date you can actually commit to out.
  2. Build it the messy way and let it promise Sundays. Fix it turn by turn, and count your turns.
  3. Ask Claude to list every correction you gave it — the cut-off, the holidays, the compounding order.
  4. Fold the list into one prompt, open a fresh chat, and rebuild it in a single message.
Open Sample 5
How it works

Build it the messy way. One vague prompt, then fix it turn by turn until it really works. Do not tidy up as you go — let it be wrong. The wrongness is your data. Count your turns.

Get the corrections log. When it finally works, ask Claude — in that same chat — to list every correction you gave it. It has the whole conversation in front of it, so the log costs almost nothing.

Read the log honestly. Almost every line is something you already knew before you started. That is the uncomfortable bit, and it is the point.

Fold it into one prompt — role, the spec, the rules, the order they apply in, the edge cases, the output format.

Fresh chat. One message. Not the old chat — the context is already in there and it would prove nothing. Paste, and watch it come out right first time.

Push both builds, the log, the prompt and your turn count to ho4-context-template. The number is the deliverable.

If the rebuild misses a rule — that is the most valuable thing here
  • It does not mean the model forgot. It means you left that rule out of the log — you fixed it in chat and never wrote it down, so it never reached the prompt.
  • Add it, and go again. The gap between "what I told Claude" and "what I think I told Claude" is exactly what context engineering is about.
The three prompts

You only need three, and the middle one is the trick most people never think of: Claude can write your corrections log for you, because it was there for the whole conversation.

1 · Start the messy build
Deliberately thin. That is the point — you want it to be wrong, so you can watch what you have to add.
Build me a single-file HTML <your tool>. No login, no backend, one screen.
Resist the urge to be thorough here. If you write a good prompt now, you will have nothing to learn. Be as vague as you normally are.
2 · Make Claude write your corrections log
Paste this in the same chat, the moment the tool finally works.
The tool works now. Go back over this entire chat and list EVERY correction I had to
give you — every rule, cap, threshold, edge case, order of operations and formatting
decision that was not in my first message.

Give it to me as a numbered list. For each one, name the kind of rule it is
(pricing rule / gate / rounding / order of operations / edge case / output format).

Do not rebuild anything. Just the list.
This is nearly free — Claude already has the whole conversation in context, so it is reading, not thinking from scratch. And the list it hands back is the context that was in your head the whole time. That is your raw material.
3 · Distil it into the one-shot prompt
Still in the same chat. Then take what it gives you to a brand-new one.
Now write me ONE prompt that would have produced this tool correctly on the first try,
in a chat with no history.

It must carry everything from that list: the role, the spec, every rule, the ORDER the
rules apply in, the edge cases, and the output format. Be explicit about anything you
got wrong the first time — especially the rules that look obvious but aren't.

Write it as a prompt I can paste, not as a description of a prompt.

Do NOT rebuild the tool.
The last line matters. Without it, Claude will helpfully re-print the entire tool — the most expensive thing you can ask for, and you already have it. Then open a genuinely fresh chat and paste the prompt it wrote. Reusing the old chat proves nothing: the context is already in there.
Ship it to GitHub

Your deliverable is the evidence, not just the tool. Anyone can show a working page; you are showing that you know why it worked the second time.

ho4-context-template/
├─ v1-iterated/index.html   ← the messy build, exactly as it ended up
├─ corrections.md           ← every correction you had to give Claude
├─ one-shot-prompt.md       ← the distilled context — THE REAL DELIVERABLE
├─ v2-oneshot/index.html    ← built from that prompt, one message, fresh chat
├─ scorecard.md             ← turns before → after, and feature parity
└─ README.md

Save the messy build as v1-iterated/index.html and the one-shot build as v2-oneshot/index.html. Keep both. The comparison is the work.

Paste Claude's corrections list into corrections.md, and the distilled prompt into one-shot-prompt.md.

Write scorecard.md: turns before → after, and tick off every feature that survived the rebuild. If one didn't, say so — an honest miss is worth more than a clean sheet.

Create the repo, then push. git branch -M main matters — older Git still calls the first branch master and the push would fail.

Push it
git init
git add .
git commit -m "HO4: the one-shot rebuild"
git branch -M main
git remote add origin https://github.com/<your-username>/ho4-context-template.git
git push -u origin main
scorecard.md — the shape
This file is the punchline. Keep it short and keep it honest.
# Scorecard — <your tool>

| | Turns | Chat |
|---|---|---|
| Build 1 — the messy way | 14 | one long chat |
| Build 2 — one-shot      |  1 | a fresh chat, no history |

## Feature parity — did the rebuild keep everything?

- [x] <rule>
- [x] <rule>
- [ ] <rule it missed — and the line I left out of corrections.md>

## What I actually learned

<One honest paragraph. Which correction surprised you? Which rule did you not
realise you were carrying in your head until Claude got it wrong?>