## 🤖 the-loop — which phases does this work item need?

> **⚡ Quick start:** reply `the-loop execute` with the boxes untouched to run the full process — every phase that is already ticked, and none of the optional ones.
>
> **✏️ To tailor it:** untick anything this work item does not need, tick anything optional it does want, then reply `the-loop execute`.

**ℹ️ How this works**

Nothing runs until an authorized user replies `the-loop execute`. The tick state at that moment is frozen and becomes the graph this item walks.

A doc fix usually needs little more than implementation and verification; a feature usually needs every phase.

You can also put the list in the reply itself — a checklist in the `the-loop execute` comment wins over the boxes here. Either way the **authorization is your reply**: the tick state is a proposal, and saying the keyword is what makes it yours.

Only the boxes under **Phases** change what work is done. Everything under **Settings** is about how and where it is done, and each has a default.

### 🧩 Phases — ticked ones run

- [x] brainstorming
- [x] requirements-definition
- [x] requirements-approval
- [x] design
- [x] test-planning
- [x] design-approval
- [x] tasks-breakdown
- [x] implementation
- [x] verification
- [x] self-review
- [x] critic-review
- [x] security-review
- [x] evidence
- [x] capability-docs
- [x] reviewer-briefing
- [x] human-approval

#### ➕ Optional phases — off unless you tick them

- [ ] design-critic-review — a different model/harness reviews the completed design.md against the requirements, before the testing plan and the task DAG are derived from it (the design is locked later, at design-approval — issue-281)

⚠️ **Every phase of this loop is selectable — including the reviews, the security review and the approval gate.** Nothing but this question is mandatory.

**ℹ️ How a skipped phase is recorded**

The phases this item skips are recorded as its own declared choice — in its work-item state, in a confirmation comment here, and in every `the-loop check` from now on — so a lighter run is always a visible one.

### ⚙️ Settings — not phases; each has a default

These decide how and where the work happens, not what work is done. Leave alone any you do not care about.

#### 📍 Where should the outer loop happen?

**Default:** on **this work item**, here. Tick the box to move it to a pull request.

- [ ] `outer-loop-on-pull-request` — on a pull request in this repository.

**ℹ️ What this means**

Not a phase — it is where the requirements, design, testing plan and task list are iterated with you. Leave it unticked (the default) and they happen **on this work item**, here. Tick it and they happen on a pull request instead.

Either way the artifacts are committed files linked from here, and each repository this work item contributes code to gets its own pull request for the inner loop.

#### 📄 Publish the spec chain as a Claude artifact too?

**Default:** no — the markdown files only. Only the `claude` harness can publish one.

- [ ] `claude-artifact` — one Claude artifact for this work item (`claude` harness only).

**ℹ️ What this means**

Not a phase, and off unless you tick it. The requirements, design, testing plan and task list become one page with a tab per file, which you can read and comment on in Claude.

On any other harness the-loop ignores this box. The markdown files stay the source of truth either way, and every gate still reads them.

#### 🎓 Explain the change and quiz the author?

**Default:** yes — already ticked. Untick it to skip all three.

- [x] `explainer` — a spec explainer and quiz before code generation, an explainer of the change for the reviewer, and a code quiz before review is requested.

**ℹ️ What this means**

The author reads a plain-language explainer of the approved spec and takes a short quiz before any code is generated, then the same for the finished change before review is requested — each time by ticking one box on the-loop's comment. The reviewer starts from the explainer of the change.

Unticked, the four nodes behind it (`spec-explainer`, `spec-quiz`, `code-explainer`, `code-quiz`) are declared skipped in your name, like any phase.

#### 🧵 How many sessions should this work item's pull requests get?

**Default:** `cross-repository`, already ticked. **Tick exactly one** to change it.

- [ ] `pr-sessions-never` — every pull request's events land in **this** work item's one session.
- [x] `pr-sessions-cross-repository` — only a pull request in **another** repository gets its own session; one in this repository is this work item's own delivery.
- [ ] `pr-sessions-always` — **every** pull request delivering this work item gets its own session, this repository's included.

**ℹ️ What this means**

Not a phase — it is how many harness conversations run for this item.

Leave them alone and `cross-repository` stands — the operator's `routing.tmux.sessionPerPr`. Ticking none, or more than one, means the same thing.

A pull request only ever gets a session when it can get a **working tree of its own**, in every mode: where it cannot, the event is delivered into this work item's session and recorded as `session.pr_session_declined`.

#### 💬 Is this work item worked in a channel of its own?

**Default:** none declared — this item's updates go to the operator's central channel.

Reply `the-loop add-channel slack@C0123ABCD` (its conversation id, not `#name`) to give it a room of its own.

**ℹ️ What this means**

Not a phase — it is where the-loop posts this item's updates, and where messages from authorized users reach it.

Declare it in a comment of its own, before or after this gate — the order does not matter, and a comment may carry only one keyword.

#### 🛠️ Which harness should this work item run on?

**Default:** `claude`, this deployment's default. **Tick at most one** to change it.

- [ ] `harness-claude`
- [ ] `harness-codex`

**ℹ️ What this means**

Not a phase — it is the agent CLI its session is. A model or effort ticked below is kept only if the harness it ends up on can run it.

Leave them alone and the default stands. Ticking more than one means the same thing — two ticks are not a choice, and guessing which one you meant is how a work item ends up somewhere nobody asked for.

#### 🧠 Which model should this work item run on?

**Default:** `sonnet`, the `claude` harness's default model. **Tick at most one** to change it.

- [ ] `model-opus` — deepest
- [ ] `model-sonnet`

**ℹ️ What this means**

Not a phase — it is what the session is.

Leave them alone and the default stands. Ticking more than one means the same thing — two ticks are not a choice, and guessing which one you meant is how a work item ends up somewhere nobody asked for.

#### 🎚️ How hard should it think?

**Default:** the harness's own default effort. **Tick at most one** to change it.

- [ ] `effort-low`
- [ ] `effort-high`

**ℹ️ What this means**

Not a phase, and independent of the model above.

Leave them alone and the default stands. Ticking more than one means the same thing — two ticks are not a choice, and guessing which one you meant is how a work item ends up somewhere nobody asked for.

### ✅ Ready?

Reply `the-loop execute`. The boxes as they stand at that moment are frozen as this work item's selection.

<!-- the-loop:phase-selection -->

🤖 the-loop, autonomous comment · [the-loop:agent-comment]
