A Loop gives you a structured way to move from an idea to an approved plan, and then to reviewed code, with the whole decision trail kept in the repository.

When to use a Loop

Three roles

Two agents do the work. You make the decisions.

The Architect, the Draftor and the Reviewer At the top, "Architect: you", with an arrow down to a central box labelled "Gator Loop: checks every step and records it", marked "watches, steers, decides". On the left, "Draftor: writes the plan or the code". On the right, "Reviewer: approves or asks for changes". Two-way arrows join the Draftor and the Reviewer to the central box; they never talk to each other directly. Under the central box, an arrow leads to a wide box: "Everything is recorded in the repository: plans, reviews, decisions". Architect you Draftor writes the plan or the code Gator Loop checks every step, records it Reviewer approves or asks for changes Everything is recorded in the repository: plans, reviews, decisions watches · steers · decides
Figure 1 — the agents never talk to each other directly. Every step goes through Gator, which checks whose turn it is and keeps the record.

From an idea to an approved plan

The planning path Four boxes from left to right: "Sketch: your idea", "Draft: the Draftor writes a plan", "Review: the Reviewer checks it", and "Approved plan", marked with a check. An arrow from Review goes down to "Revision: the Draftor answers the review", and an arrow leads back up to Review. Sketch your idea Draft Draftor writes a plan Review Reviewer checks it Approved ✓ the plan Revision Draftor answers changes requested resubmitted
Figure 2 — the plan goes back and forth until the Reviewer approves it, or until you step in.
  1. Write a sketch. Describe what you want, what is out of scope, and any decision you have already made. A few paragraphs are enough.
  2. The Draftor drafts a plan. It reads the repository's charters, then turns your sketch into a concrete plan.
  3. The Reviewer reviews it. It approves the plan, or it lists what must change.
  4. The Draftor revises. The plan goes back to review. This repeats until the plan is approved.
  5. The plan is approved. It is now a fixed, reviewed record of what will be built.

From an approved plan to reviewed code

The coding path, one checkpoint at a time Three checkpoint boxes in a row, then a commit box. Checkpoint 1 and checkpoint 2 are marked approved with a check. Checkpoint 3 is marked "in review". The last box, "You commit", is the end of the path. Checkpoint 1 ✓ approved Checkpoint 2 ✓ approved Checkpoint 3 ● in review You commit the approved code
Figure 3 — the code is built and reviewed in steps. Nothing is committed until you commit it.
  1. Start a coding Loop from the approved plan. The plan can divide the work into checkpoints.
  2. The Draftor builds one checkpoint. It makes the changes and stages them for review.
  3. The Reviewer reviews the exact code. The approval covers the code that was submitted, not a description of it. Each checkpoint is approved before the next one starts.
  4. You commit. After the last approval, you make one normal commit. The Loop then confirms that the committed code is the code that was approved.

In the Dashboard

You stay in charge

The agents propose and check. You decide.