Guild Stack

Guided route · Illustrative composite

Follow one task from request to verified result.

A sample Stripe request moves through scope, team, plan, specialist lanes, review, and verification. Artifact names match product behavior; sample outcomes remain illustrative.

Begin at the requestInspect the run ledger

Page evidence

Operational mapA loose request becomes a verified route.
  1. Requestbounded task
  2. Specapproved intent
  3. Teamphase specialists
  4. Planlane sequence
  5. Buildhandoff receipts
  6. Reviewchallenge + rework
  7. Verifyfinal evidence
A loose request becomes an inspectable run record.
  1. 01The vague ask

    /guild:guild "..."

  2. 02Approved gates

    spec, team, and plan

  3. 03Execution

    handoffs/

  4. 04Adversarial review

    review/G-lane:frontend-subscription-ui/

  5. 05Verification

    verify.md

  6. 06The run on disk

    provenance.json

Read this first

Sample, not a citable run

The run id, file paths, and review counts below are a representative composite for teaching the shape of a run. They are not sourced from a single committed .guild/runs/ record.

Chapter 01

One loose sentence starts a run.

You do not have to pre-plan the work. Give /guild:guild a plain request and Guild drafts the scope before it edits anything. The first thing it produces is a spec gate, not a diff.

Terminal

/guild:guild "Add Stripe subscriptions to the app."

planned next Guild Stack drafts scope before touching files.

Chapter 02

Three gates before any code.

Guild Stack writes the spec, proposes a phase-specific team, and sequences the lanes. You accept or edit each one; approvals become gate receipts.

Gate receipt

.guild/runs/run-stripe-subscriptions-20260705-1042/

passed spec .guild/spec/stripe-subscriptions.md
passed team .guild/team/stripe-subscriptions.development.yaml
passed plan .guild/plan/stripe-subscriptions.md

Chapter 03

Specialists run focused lanes.

Each lane gets a bounded context bundle and returns a handoff receipt, not a loose summary. Independent lanes run in parallel where the plan allows.

Operational mapIndependent lanes converge through durable handoffs.
Data layer
  1. bounded context
  2. migration + model
  3. handoff receipt
Service
  1. endpoint contract
  2. checkout + webhook
  3. handoff receipt
Interface
  1. approved states
  2. subscription UI
  3. handoff receipt
Quality
  1. acceptance criteria
  2. focused checks
  3. verification input

The plan decides which lanes may run together. Every completed lane returns through the file bus.

Parallel work remains bounded by the approved plan and rejoins through receipts.

Chapter 04

Plausible work gets challenged.

Before the run is trusted, a reviewer challenges the load-bearing work against the spec. Cross-host review is strongest; same-host or skipped review is recorded as weaker.

review/G-lane:frontend-subscription-ui/

Review result

passed Reviewer cross-host
passed Findings 2 raised, 2 resolved after rework
passed Verdict satisfied

Chapter 05

Verification checks the agreed scope.

The final pass checks the original success criteria and the lane receipts. Verification does not replace quality or operations; it answers whether this run is done.

verify.md

Done gate

passed Named tests Tests named in the spec pass.
passed Traceability Every changed file traces to a lane.
passed Success criteria Success criteria are met.
passed Followups No open blocker followups remain.

Chapter 06

The record survives the chat.

The run directory contains the manifest, settings, handoffs, review packets, trace, verification, and provenance needed to reconstruct what happened.

.guild/runs/run-stripe-subscriptions-20260705-1042/

Run on disk

  1. .guild/runs/run-stripe-subscriptions-20260705-1042/run.yaml start manifest: host, lens, phases
  2. resolved-settings.json frozen host, tier, rigor, review posture
  3. handoffs/ one receipt per completed specialist lane
  4. review/G-lane:frontend-subscription-ui/ packet, findings, verdict, independence
  5. verify.md the task-specific verification result
  6. logs/v1.4-events.jsonl the canonical local trace
  7. provenance.json close-shape facts that reconstruct the run

Next

Inspect the proof model behind the demo.

The proof page breaks down each artifact type and points to the docs that define the contracts.
Open proofRead docs