Forge is the route you take when the work has to survive someone checking it. It carries an agreed outcome through five phases: Spec, Plan, Build, Acceptance, and Ship. One accountable builder owns the change, a separate reviewer judges it, and acceptance exercises the real thing, which is why a passing test never counts as acceptance on its own. The one thing to understand: naming a phase names a stopping point. A spec never authorizes a build, and a build never authorizes a ship. Open Bright →

​
Why Forge is the default

Make Forge your first choice for work that ships. It is the only one of the three flows where somebody other than the agent that wrote the code has to sign off before you do.
Start with Forge and narrow later. Naming one phase costs nothing extra: “stop after Plan” is as cheap as any other prompt. You keep the option to carry the same work through Build and Acceptance without restating it.
The other two flows still earn their place. Use the methodical loop when you want to read each step before the next one starts, and one-shot when you own the whole thing and want speed over evidence.

​
Invoke it

  1. Open a session in Agent mode.
  2. Type / and pick forge.
  3. Say what the work is and where you want it to stop, in the same sentence.
That third step carries the page. Forge reads the boundary out of your words, so write the boundary down.
Plain wording works too. “Use Forge to review this branch” reaches the same place.

​
Each phase stops at its boundary

This is the part people trip over. Four rules cover it:
  • Importing a ticket, drafting a spec, or drawing a mockup is not permission to implement.
  • Build includes the independent review. It does not claim acceptance.
  • Acceptance needs a current review of the same candidate. If none exists, Forge gets a bounded one first.
  • Ship performs only the publication you authorized. A pull request is not a merge, and a merge is not a release.
When something consequential conflicts, Forge does not decide it for you. It comes back with the evidence, the options, and a recommendation.

​
What the five phases do

  1. Spec defines accepted intent, including intake and discovery.
  2. Plan defines the smallest useful approach and the delivery breakdown.
  3. Build produces one integrated candidate, simplified, with an independent verdict.
  4. Acceptance exercises the real outcome, in a browser when the work has a UI.
  5. Ship checks the complete candidate once and records concise closure.
Depth, staffing, and paperwork scale to the job. The phases do not disappear. An accepted ticket can satisfy Spec, and a one-sentence note can satisfy Plan, but the phase is still accounted for. Forge reference covers what each one consumes and produces.

​
What lands in the repo

Forge keeps a managed loop in the target repository, as readable Markdown:
Standing specifications live at docs/specs/, and an optional knowledge bundle at docs/knowledge/. The tree shows what is available, not a document stack you owe. Small work writes few of these files.

​
Tips

  • Put the stopping boundary in the same sentence as the request.
  • Give Forge the issue code. An accepted ticket can be the whole spec.
  • Ask for a design study before UI work, so acceptance has an accepted visual to compare against.
  • Say which review dimension to replace or disable if your team owns its own rubric.

​
Good to know

  • Full delivery accounts for exactly five phases. Depth changes; the phases do not.
  • Naming a phase stops at that phase. Spec never authorizes Build, and Build never authorizes Ship.
  • Build always includes an independent review by an engineer who did not write the change.
  • Review and acceptance answer different questions. A review PASS is not acceptance, and neither one means Ship happened.
  • Forge follows your repository’s stack and standards, read from its own instructions, manifests, and code.
  • Five review dimensions apply. Spec and Craft apply to every candidate; the rest follow the outcome.
  • Four work families: Project, Issue, Bug, and Work. Forge infers one unless you name it.
  • After three substantive repair cycles, Forge stops editing and records a rethink instead of patching again.
  • Exploring, drafting a spec, or reviewing writes nothing to your repository.

​
Next step

Look up what each phase consumes, what review covers, and which files land in the repo in Forge reference.