The Forge front-end: 7 steps from rough idea to shipped

You learned the loop already: learn → analyze → execute one bounded unit → verify at the real boundary → decide. The loop is a brilliant engine. But an engine needs fuel of the right grade. The loop's fuel is a measurable done-when — a finish line a machine can check. Hand it "make alerts" and it has no finish line, so it can never stop. Hand it "a user can save a search, and within 60 seconds of a new match an email arrives, proven against a live inbox" and the loop knows the exact moment it is finished.

Most tasks don't arrive with that finish line attached. They arrive as a rough idea. Forge is the front-end that turns the rough idea into the finish line — and then keeps going, all the way to shipped, without you touching the keyboard. It is optional: if your scope is already crisp, you skip Forge and go straight to the loop. If it's fuzzy — which is most of the time — you run Forge first.

Forge is seven steps, and we will give each one its own beat in this lesson:

1. Grill — argue the idea with itself until the scope is sharp. 2. Research (optional) — cache hard exploration into a durable note. 3. Prototype (optional) — throwaway code for real evidence. 4. PRD — write the destination down. 5. Issues — break it into dependency-ordered tickets and compile GOAL.md, the run contract. 6. Implement — an Executor builds each ticket, an independent Validator proves it. 7. Review — AFK QA writes an observability report you read.

Two ideas hold the whole thing together, and they are worth saying once, plainly, before we go further. First: everything runs AFK — away from keyboard. Your only job is observability: you read what happened, you don't execute anything. Second: the step that turns the grill's output into a contract is GOAL.md, and that contract's measurable done-when is the loop's exit condition. Forge refuses to even compile GOAL.md until the done-when is something a machine can check.

Think of it like… a blacksmith's forge. You bring a lump of raw iron — your rough idea. You don't hammer it cold; you heat it, fold it, test its edge, reheat it, fold again. Each fold is a step. What comes out the other side is a finished blade with a tested edge — your shipped feature with a proven done-when. Where the analogy breaks: a real smith does the hammering by hand; here the smith is a crew of agents and you only watch the sparks (read the logs).

The obvious objection: why not just point the agent at the idea and let it go? Because an agent with no finish line behaves exactly like a person with no finish line — it wanders, it gold-plates, it declares victory on the wrong thing, or it loops forever. The cost of a vague start is not paid up front; it is paid later, multiplied, in rework. A front-end pays a small, bounded cost now to avoid a large, unbounded cost later.

Below is a deep-dive on the idea, in the shape of a real feature explainer: a contents list, an interactive simulation you can run, the contract in three views (the rough idea, the hardened scope, the compiled GOAL.md), and an FAQ of the questions people actually ask. Run the simulation — send "dive straight in" runs against "front-end first" runs and watch the wasted-work counter.

Before we walk each step, here is the whole pipeline at a glance. Read it left to right: a rough idea enters at Setup, runs the grill, optionally detours through research and prototype, becomes a PRD, then a board of issues plus a GOAL.md, then the AFK build loop, then the AFK review — and finally converges into the course. The two boxes drawn with dashed borders are the optional steps; the curved arrow underneath shows that you can reach back for grill, research, or prototype at any pass, not only at the start.

The shape to keep: a default order, not rigid phases. Research and Prototype are optional. A crisp, familiar scope skips them and goes straight from grill to PRD. And the moment any step hits an unknown that needs real evidence, you can reach back for the grill, research, or prototype — that is what the feedback loop means.

Now the same seven steps as a deck — one big idea per slide, so you absorb the shape before the detail. Click Next, tap a dot, or use the left / right arrow keys. We come back to each step in depth right after.

The deck gave you the shape; now feel the motion. Pick a starting situation, then press Next to walk the saved-search-alerts idea through the Forge one step at a time. Each path shows a real choice: a fresh idea runs the full pipeline; an already-crisp scope skips the optional steps; and a mid-build unknown reaches back for the grill. Watch which boxes light up — and which get skipped.

Two of the seven steps are optional: Research and Prototype. They are not lesser steps — they are powerful tools you reach for when the situation calls for them, and skip when it doesn't. The deciding question is simple: does this unknown need a paragraph of facts, or a running artifact of evidence?

If the unknown is "what does this library's API actually look like, what is that service's real rate limit" — that is research: cache the facts once into research.md (web facts via the brightdata CLI) so you never re-explore. If the unknown is "will this approach even work, how does this feel" — that needs prototype: throwaway code that produces real evidence, leaving reusable assets behind. And if the scope is already familiar, you skip both.

The grill is where a rough idea becomes a sharp scope. The trick is that it does this without asking you a single question. Instead of interviewing the human, the Orchestrator spawns several perspective sub-agents — one that pushes for user value, one that checks feasibility, one that hunts for risk, one that argues for the simplest thing that could work, and one that probes the hardest input. They ask and answer each other, grounded in the docs you named, and they keep going until they converge on something decision-ready.

For our running example, the rough idea is "let users get notified about new matches." The grill turns that into: email only for v1; "new" means matched since the last alert; delivered in under 60 seconds; save / list / delete one saved search; one matcher; one mailer; digests and push are explicitly out. That is a scope a machine can build against.

Think of it like… a newsroom editorial meeting before a story runs. Nobody publishes the first pitch. The reporter, the skeptic, the lawyer, and the editor all push on it from their angle until what's left is sharp and defensible. Where it breaks: the meeting has people; the grill has agents debating among themselves, and only a genuine user-only fork ever escalates to you.

The grill's job is convergence, not exhaustion. It stops when the scope is decision-ready — sharp enough to build against — not when every possible question has been asked. Grilling too hard is its own anti-pattern.

Sometimes the build will run head-first into territory nobody on the crew knows well: an unfamiliar API, a library you've never used, a domain with its own rules, a large codebase, or prior art worth studying. Exploring that during the build is expensive — you'd re-explore it every time you came back. Research caches that exploration once, into a durable note called research.md, so the knowledge is written down and reused.

For saved-search alerts, the research question might be: does our existing mailer support the headers we need, and what is the search service's real query budget? Those are facts — and facts come from the brightdata CLI (web search, scraping a doc page, or a live browser session), never from a guess. The answers land in research.md and the grill folds them in.

Think of it like… reading the trail map and checking the weather before a hike, then writing the key facts on a card you keep in your pocket. You don't re-check the forecast at every fork — you cached it once. Where it breaks: a trail map is static; research.md is living, and you add to it whenever a new unknown turns out to be fact-shaped.

Some questions can't be answered by reading — only by building. Will this matcher actually fire on the row I expect? Does an email really arrive, end to end? For those, you write a tiny throwaway program that produces real evidence. The code itself is disposable; what you keep is the evidence (which folds back into the grill) and any reusable assets (which carry into the real build).

Prototype is the Proof Gate applied early: instead of assuming an approach works and discovering otherwise after a full build, you prove the risky bit in an afternoon. For saved-search alerts, a prototype might wire a fake search result straight into the mailer and confirm a message lands in a local SMTP sandbox — proof, before a single production line is written.

Think of it like… a chef tasting the sauce from a spoon before plating the whole dish. The spoonful is thrown away, but it told you the seasoning is right. Where it breaks: the spoonful vanishes; a prototype can leave reusable bits — a config, a fixture, a helper — that survive into the kitchen.

Prototype is a tool, not a phase. You can reach for it at any pass — including mid-Implement — the moment an unknown needs a running artifact rather than a paragraph. Feed the evidence back into the grill and continue.

By now the scope is sharp and any unknowns are settled. The PRD writes it all down as the destination: what the feature is, who it's for, the user stories, and the implementation notes. It is the "what and why" that the rest of the run is measured against — broader than a single loop's scope, but not a novel; a tight document, not a wall.

One useful way to read a PRD is as a phased plan you can click through. Below, the saved-search-alerts work is laid out as four phases — each with its goal, its tasks, its risks, and the exit bar that lets it advance. Click a milestone across the top (or focus the bar and use the arrow keys) to open its phase card. Notice that each phase only advances when it clears a measurable exit bar — the same discipline as the loop's done-when, applied at the plan level.

A PRD describes the destination, but an agent doesn't build "a destination" — it builds one bounded ticket at a time. So Forge turns the PRD into individual tickets, each a small, well-specified unit. The crucial part: the tickets carry blocking relationships. You can't send the email before you can match a row; you can't match a row before a search is stored. Those dependencies make the board a dependency-ordered kanban — work flows in the only order that can actually succeed.

Alongside the tickets, Forge compiles GOAL.md — the autonomous-run contract. Its measurable done-when is the loop's exit condition, and it doubles as each ticket's acceptance bar. And here is the guardrail that makes the whole thing trustworthy: Forge refuses to compile GOAL.md until the done-when is measurable. No measurable finish line, no run.

Below is that board, live. A card with unfinished dependencies is blocked — hatched and locked; you literally cannot advance it until what it depends on is done. Clear its blockers and it unlocks. Try to move F (the end-to-end proof) before its dependencies are done and the board won't let you — that is the blocking relationship enforcing the only safe order. Move cards with the arrow, or drag them, and watch the counts and the locks update.

This is where Forge hands the wheel to the core loop you already know — and never takes it back until the work is done. In a loop, a coding agent works the kanban in blocking order. For each ticket, an Executor builds it, and then an independent Validator proves the result against GOAL.md at the real boundary — the Proof Gate, never a claim, never a mock. The one rule that makes this honest: the Validator is never the builder. A different agent grades the work, so nobody marks their own homework.

If a ticket keeps failing the same way, the crew fixes the root cause — and if the plan or the prompt is the root cause, it improves that and re-runs. Every pass is logged to LOOP-LOG.md, which is one of the files you read to observe. The loop continues until every ticket is done and proven.

This is the bridge between this module and the core loop you studied. The diagram below shows exactly where each Forge step lands inside learn → analyze → execute → verify → decide.

Cross-agent and agnostic: the Executor and Validator can be any agent — Claude Code, Grok, Kimi, pi, Council, Codex — dispatched headless via that agent's cli -p. The only invariant is that the Validator is a different agent than the builder.

The build is done and every ticket was proven as it landed. Review is the final, independent sweep: an AFK QA pass that checks every user story and done-when against the real boundary one more time, and writes the result to a file called review.md. Crucially, this is QA you read, not QA you perform. The machine runs the checks; review.md is an observability report for you.

Per criterion, the report says: what was built, the verification result, and a pointer to the evidence. It also lists residual gaps and a "flagged for awareness" set — the taste, UX, and product judgments a machine can't make and wants a human to be aware of. You observe; the loop never blocks on you. (The one exception, as always, is a genuine user-only fork, which is escalated as a decision-ready handoff — never as routine review.)

Think of it like… a flight's post-landing report waiting in your inbox. The aircraft already landed safely; the report tells you how the flight went, what to watch next time, and anything that needs a human's call. You read it — you weren't asked to fly the plane. Where it breaks: a flight report is static; review.md points at live evidence you can re-run.

The human's only role across all seven steps is observability. You read LOOP-LOG.md, review.md, and the run status. You never execute anything — not even the QA. The loop blocks on you only for a true user-only fork, via a decision-ready handoff.

Since your only job is to observe, it helps to see exactly what that looks like. This is a live status board for one Forge run — the saved-search-alerts build. Four headline numbers up top (steps done, tickets proven, wasted work, freshness against the 60s budget), then a row per step with its state and the evidence pointer you'd open to verify. Hit Refresh for a new reading, or turn on Live to watch the run progress — the way you'd glance at it while it runs AFK.

Forge doesn't end at "it works." The last beat is converge: deliver the shipped result and a full visual-teach course — like the one you're reading. This is the unchanged Course Gate from the core skill. The point is that knowledge built during a run shouldn't evaporate when the run ends; it gets distilled into something a person can learn from later.

So the full arc, end to end, is: Setup → Grill → (Research) → (Prototype) → PRD → Issues + GOAL.md → Implement → Review → Converge. A rough sentence went in; a proven feature and a teachable course came out — and you only ever observed.

Everything in this lesson is real and bundled. The Forge methods live self-contained under forge/, each as a METHOD.md in our own words so the loop never depends on an external skill. Here is the map, and how to open it yourself.

Recall beats re-reading. Answer from memory before you peek — each question grades on click, and the feedback names the idea so you can shore up anything fuzzy.