multithread

Files (1)

• SKILL.md

SKILL.md (first lines)

<!-- introduction-gate: If introduction.md exists in this skill's directory AND
     the marker file /tmp/.skill-intro-multithread does NOT exist, read introduction.md,
     present its contents to the user, then create the marker: touch /tmp/.skill-intro-multithread
     Do NOT delete introduction.md — it lives in a protected directory.
     Do this BEFORE executing any skill logic below. -->

# Multithread — Parallel Discussion Over Independent Items

Convert a serial walk through N independent questions, design holes, or review
comments into a concurrent discussion that converges in ≈ log(N) round-trips
instead of N.

**See Also:** `docs/executor-model-devspec.md` (Plan #822 §8 Story 3.1 — the
executor model: `/multithread` is the dialogue-facing companion to the
`/lazyriver` goal-seek loop and the `/wavemachine` plan-execution driver).

**Wave taxonomy position:** multithread is wave-pool for dialogue. The unit is
a discussion thread; the convergence checkpoint ("sorted / still open") is the
inter-wave barrier; the loop-until-dry is the same tail-catching discipline
wave-pool workflows use.

---

## Invocation

```
/multithread <source>
```

`<source>` is anything that enumerates to a list of independent items:

| Source type | Example |
|-------------|---------|
| Doc section | `/multithread docs/agent-smith-devspec.md §5.N` |
| Open-questions list | `/multithread the open questions` |
| PR review comments | `/multithread PR #813 review comments` |
| Ad-hoc list | `/multithread these: [a, b, c, …]` |
| No arg | Infer from the most recent open-questions block or list in conversation |

---

## Procedure

### Step 0 — Enumerate and label

Resolve `<source>` to a concrete list. Assign each item a **stable label**
(`T1 … TN`, or short slugs when N is small and slugs are more memorable).

Apply these normalizations before labeling:

- If an item is really two questions, split it into two threads — and say so.
- If two items are really one, merge them into one thread — and say so.
- If the source has zero items, report that and stop.

### Step 1 — Independence pass

Walk the list and annotate couplings: `T3 depends: T1`. This is a cheap
single-pass scan — no fan-out, no sub-agents. The goal is to make dependencies
**visible on turn one** rather than discovered by accident on turn six.

Flag tightly-coupled pairs (resolving A would rewrite what B even asks) — see
"When not to use" below for how to handle them.

### Step 2 — Present all threads at once

Lay out every thread in a single message. The canonical format is a compact
table:

```
| Label | Thread | Proposed take | Notes |
|-------|--------|---------------|-------|
| T1    | …      | …             | —     |
| T2    | …      | …             | depends: T1 |
```

**The take is mandatory.** Reacting is faster than authoring; a blank thread
is just a survey. Propose a disposition the user can accept, reject, or amend.
If genuinely uncertain, say so in the take — that is still a take.

For longer items (multi-sentence threads), use per-thread blocks instead of a
table:

```
**T1** — <thread title>
Take: <proposed disposition>

**T2** — <thread title>  (depends: T1)
Take: <proposed disposition, or "pending T1 — best guess: …">
```

Pick table vs. blocks based on item length; be consistent within a run.

### Step 3 — Human batch-answers

Accept the user's responses in any order and any subset. Silence on a thread
means **still open** — never assume-resolve.

A user response may be:

- A direct accept/reject/amend for one or more threads.
- A dependency note ("T3 depends on T1 — let's sort T1 first").
- A split or merge ("T5 and T6 are really the same").
- A question back (rare; answer it inline if quick, or open a new thread).

### Step 4 — Converge (the barrier)

After each batch-answer, explicitly report the convergence state before
re-presenting open threads:

```
Sorted: T1, T3, T7
Still open: T2, T5, T6
```

This is the inter-wave barrier — the "which ones do we still need to discuss?"
checkpoint. It prevents re-litigating sorted threads and makes progress visible.

### Step 5 — Iterate

From Wave-Engineering/claudecode-workflow, MIT.

More from Wave-Engineering/claudecode-workflow