What you get: the operating loop

/setlist:new is an architecture session you drive, and its first message says so. The session contract names what it decides only with your approval (the stack, the core data model, the scope and every default it writes down) and what it never decides for you (boundaries, data ownership, the repository split and anything with a cost); you can ask it anything at the level you work at.

Its second question is the sizing question: one deployable, several with their own pipelines, or an existing estate, who else builds here, and what already exists. The answers pick one of three depth modes: ordinary for one deployable, deep for several, with one round per topic, and estate for a system that already runs as several repositories.

A deep round ends when its decisions are written or you say enough, never when the session runs out of defaults. The deep rounds take one topic each: boundaries and ownership, contracts between components, data, pipelines and deployment, failure modes and the riskiest integration, and observability last, and every crossing gets a named contract or an open question. /setlist:retrofit starts with the estate inventory: it asks whether the repository is the whole system or one of several, reads each sibling you name without writing to it, shows each role path with its file count for you to confirm, and for an estate writes the system as it found it, every missing piece an open question.

Every decision your idea leaves open is a question or a line in the assumption register: the default taken, why, and the question that would change it, which you keep, change or leave for later. A high-level idea gets its decisions first: when the session cannot name your deployables, users and core data, it derives the open decisions and asks them in order of consequence, three at a time, before proposing anything.

It asks how your system splits into repositories, by pipeline, release cadence and team, and records the repository split with its reason. For a system of several repositories it writes the system spec first, system.md in a system repository with the contracts beside it, and each repository's first spec cites it in a Cites: line that /setlist:validate reads.

Its bootstrap plan lists the repositories in order; the session stamps each one with the system spec's path recorded in .claude/sdd.json, reports a progress line per repository, and stops at the first failure. It stamps the hooks and an AGENTS.md pointer beside CLAUDE.md for other harnesses, and writes your first specs; /scaffold makes the first commit.

The golden rules in your CLAUDE.md tell the model that types to finish the spec and nothing more, to claim a change done only after a real check ran, to give options when asked, and to hand mechanical runs to the delegated tier while planning and the close review stay on the stronger ones. Under Claude Code's opusplan setting the Planner decides in plan mode and the Builder types in execution mode.

The model rule: the edition binds each tier by its alias, never by a version, and records what each alias served as a dated reading. Your part is approvals, answers to parked questions and QA Pass 2; you never type code or Git. Each feature runs one loop, with your stack's commands in the generated RUNBOOK.md:

Plan.
Shift+Tab into plan mode. The Planner re-grounds from STATUS.md, asks the real forks and proposes the next spec. You approve, and the Builder writes it. The spec reader, a read-only agent on the delegated tier, then lists the questions a Builder would still ask, and every assumption the spec rests on that you have not approved (the readers read the register), and the Planner answers them in the spec.
Branch.
/setlist:checkpoint makes the trunk claim first: the ACTIVE flip lands on the trunk and is pushed, after you approve the push, before the branch exists, so every clone that fetches sees the spec is taken.

The claim pushed with it is the empty spec/NNNN-<slug> branch, in the same atomic push, and the re-grounding hook names the remote's other spec branches at every session start, from the last fetch and with its age (or that the age is unknown), making no network call. Then it opens spec/NNNN-<slug>, and it refuses to open a branch whose spec the trunk does not carry at ACTIVE; since 2.15.0 such a branch is also refused at push by pre-push (SLH-CLAIM-NOT-ON-TRUNK).

After this and every other lifecycle flip it prints the visibility block: what landed on the trunk, what was pushed, who can see it now, and what is still only local.
Build.
Small commits with the gates run. Ambiguities are parked in STATUS.md and never improvised. When the Builder loops on a bug, the model-ladder skill says when to escalate.
QA Pass 1.
With gates green, the automated criterion check runs on the delegated tier and its report goes into the spec's Closing report. Delegated work runs through the Agent tool on haiku and never as a fork, which would run on your session's model; the journal line names the model that ran it.

The edition's model table reads each alias per provider: on Claude Platform on AWS and the cloud-provider platforms haiku is a generation behind, and /setlist:validate names the Haiku generation that served it when it is not Haiku 5.
QA Pass 2.
You use the feature and spot-check at least one passed criterion.
Close.
/setlist:checkpoint runs the close review. A second model, on the Opus tier in a fresh context, reads the branch's diff against the spec's criteria and reports every finding with its file and line; a criterion that rests on an assumption you left for later is a MAJOR finding.

Its block records each round's effort line, the level the review ran at. You fix what it finds and it reads again, two rounds at most; the call past them is yours. Then it runs the close checklist and merges --no-ff, and git refuses a close whose review did not pass.

STATUS.md names the next action.
Next.
Shift+Tab, repeat.