Beginner users
Start with one change you can name.
Install Guild Stack, describe one testable change, then approve the proposed scope, team, and plan when the run reaches those decisions.
Page evidence
First run · route 01
map / active One bounded task, five inspectable stops
- RequestName the task/guild:guild “one bounded change”
- GateApprove scopeSpec, team, and lane plan stay visible.
- DispatchRun the laneFocused context and explicit authority.
- ReviewChallenge + verifyFindings must resolve before the route closes.
- TerminusOpen the receiptThe final message is not the source of truth..guild/runs/<run-id>/
First jobs
Keep the first task legible.
- Run one bounded task
Give Guild Stack one change you can name and verify.
- Review three decisions
Approve or edit the proposed scope, team, and plan.
- Reopen the result
Find the record under .guild/ after the chat is over.
Guided path
A five-step route with visible gates.
The action is simple. The decisions are not hidden: pause at each gate, review the proposed artifact, and only then move on.
$ /guild:guild "Add input validation and cover it with a test."- 01
Install
Install the plugin for a supported host.
- 02
Restart
Start a fresh host session so the command surface loads.
- 03
Run
Describe one testable change with /guild:guild.
- 04
Approve decisions
Review scope, team, and plan at the visible gates.
- 05
Inspect evidence
Reopen the run files after work reaches completion.
Evidence
The folder tells you where to look next.
The spec captures the approved boundary. The team and plan show who was chosen and in what order. The run directory collects the later receipts.
.guild/runs/run-<id>/
A first run leaves a readable trail
-
.guild/spec/<task>.mdapproved task boundary -
.guild/team/<task>.yamlphase specialists chosen at the gate -
.guild/plan/<task>.mdlane order you approved -
.guild/runs/<id>/receipts and verification after completion
Continue
