## 🤖 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`.

<details>
<summary>ℹ️ How this works</summary>

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.

</details>

### 🧩 Phases — ticked ones run

- [ ] brainstorming
- [ ] brainstorm-approval
- [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.

<details>
<summary>ℹ️ How a skipped phase is recorded</summary>

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.

</details>

### ⚙️ 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 a **pull request** — already ticked. Untick the box to keep it here, on this work item.

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

<details>
<summary>ℹ️ What this means</summary>

Not a phase — it is where the requirements, design, testing plan and task list are iterated with you. Leave it ticked (the default) and they happen on a **pull request**. Untick it and they happen **on this work item**, here, 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.

</details>

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

**Default:** yes — already ticked. Untick it for the markdown files only. Only the `claude` harness can publish one.

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

<details>
<summary>ℹ️ What this means</summary>

Not a phase, and on unless you untick 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.

</details>

#### 🎓 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.

<details>
<summary>ℹ️ What this means</summary>

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.

</details>

#### 🧵 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.

<details>
<summary>ℹ️ What this means</summary>

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`.

</details>

#### 💬 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.

<details>
<summary>ℹ️ What this means</summary>

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.

</details>

### ✅ 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 -->
