Brainstorm Queue Aware

---
name: brainstorm-queue-aware
description:
  "Use when running as a brainstormer that a Brainstorm Steward is managing —
  redirect every Q-by-Q question to the Steward as a NEED message and block for
  the ANSWER instead of asking the human directly. Fires when your briefing
  names a steward."
# source: claude-plugin/skills/brainstorm-queue-aware/SKILL.md
---

## Brainstorm: Queue-Aware Mode

### When this fires

You are a brainstormer running the normal `brainstorming` skill, and your
briefing names a `steward: @<name>` (or otherwise tells you a Brainstorm Steward
is managing your slot in a queue of parallel brainstorms). That one fact is the
whole trigger. If no steward was named, ignore this skill entirely and run
`brainstorming` exactly as documented — ask the human directly, the ordinary
way.

Every `@<steward>` placeholder below stands for that same name from your
briefing — substitute the real agent name, not the literal text `<steward>`.

This is a **thin overlay, not a replacement**. Everything about how you
research, propose options, and converge to a locked design is still owned by the
`brainstorming` skill. The only thing this skill changes is **where a question
goes when you would otherwise have asked the human.**

### The redirect

Wherever `brainstorming` says "ask the user" or "pause for the human's answer,"
do this instead:

1. Compose the question exactly as you would have asked the human — one clear
   question, plus 2-3 concrete options (A/B/C) so the Steward has something to
   decide between, not an open-ended essay prompt.
2. Send it as a `NEED` to your steward, per the NEED/ANSWER convention (first
   line `NEED [<topic>]:`; the steward replies with an `ANSWER`):

   ```bash
   thrum send --to @<steward> --stdin <<'EOF'
   NEED [<topic>]: <one clear question>
   A) <option>
   B) <option>
   C) <option>
   EOF
   ```

3. Block on `thrum wait` rather than polling or continuing speculatively:

   ```bash
   thrum wait
   ```

4. When `thrum wait` returns, read the reply from your inbox the normal way. The
   Steward answers by replying directly to your NEED message (threaded,
   automatic), with a body starting `ANSWER:`. Treat that `ANSWER:` line exactly
   as if the human had just said it to you — fold it into the design and
   continue the brainstorm from there.

Nothing about the NEED/ANSWER convention is a new subcommand or a structured
payload — it's plain `thrum send` / `thrum reply` / `thrum wait` with a one-line
prose convention on top. Don't invent a schema, a JSON body, or a `thrum need`
command; none exists.

### One question at a time, still

The `brainstorming` skill's Q-by-Q discipline doesn't change: send **one** NEED,
block, get the **one** ANSWER, then decide whether the next question is needed
before sending it. Do not queue up three NEEDs in a row hoping to save a round
trip — the Steward may be juggling several brainstormers at once, and batching
on your end doesn't help it; it just makes your own inbox harder to reason about
when replies come back out of order. Batching NEEDs across brainstormers so the
human sees fewer round trips is the **Steward's** job, not yours — that's the
whole point of putting a Steward in the loop.

### If the Steward doesn't answer

`thrum wait` blocking indefinitely is normal and expected — the Steward may be
waiting on the human, or working through other brainstormers first. Don't treat
a long wait as a signal to guess.

If the wait genuinely exceeds a reasonable bound for your situation (you've been
blocked far longer than the Steward's other visible turnarounds, or you have
independent reason to think the NEED never arrived):

1. **Re-send the NEED once** — a fresh `thrum send` with the same question, not
   a new phrasing, so the Steward isn't left reconciling two versions of the
   same ask. Note in the resend that this is a repeat:

   ```bash
   thrum send --to @<steward> --stdin <<'EOF'
   NEED [<topic>]: <one clear question> (resend — no answer yet)
   A) <option>
   B) <option>
   C) <option>
   EOF
   ```

2. If that still doesn't produce an ANSWER, **escalate to your `parent`** (the
   Steward, or whichever agent your briefing names as parent) with a plain
   status message — do not decide the content yourself:

   ```bash
   thrum send --to @<parent> --stdin <<'EOF'
   Blocked on NEED [<topic>] — resent once, still no ANSWER. Need a decision
   to keep moving; not proceeding on a guess.
   EOF
   ```

Never fill in the owner's decision from your own judgment because the Steward is
slow. A wrong guess here isn't a small correction later — it's a design-lock
built on a decision the owner never actually made.

### Design-lock discipline still belongs to you

The Steward is a **relay**, not a decider. It exists to keep your questions
moving through a queue when the human is juggling several brainstormers — it is
not delegated authority to choose between your options on the owner's behalf,
and an `ANSWER:` it relays is the owner's answer passed through, not the
Steward's own opinion. Nothing about a Steward being in the loop loosens the
standing brainstorm discipline: you still hold the RESOLVED-CHOICES record for
the owner (per the `interactive-brainstorm` role rule / the standing brainstorm
design-lock convention), and every locked decision still needs to trace back to
a real `ANSWER:` line, not to an inference you made because the Steward's
presence made the human feel one step further away. If an `ANSWER:` is ambiguous
or doesn't actually resolve the question you asked, send a follow-up NEED rather
than picking the reading that's convenient.

### Announce handoffs, so the Steward can keep things moving

When you send finished work to another agent and then sit waiting on them — for
example, a brainstorm or plan sent to a coordinator for dual review — send the
Steward a brief, plain-prose heads-up so it can notice if you stall and prompt a
nudge. This is **not** a new convention; it's the same unstructured-message
style as NEED, just without the `NEED:` prefix (the Steward isn't being asked to
decide anything, only to keep an eye out):

```bash
thrum send --to @<steward> --stdin <<'EOF'
WAITING [<topic>]: sent the brainstorm to @<coordinator> for dual review.
EOF
```

You are **not** expected to poll for a response yourself while in this state —
that's the Steward's job, the same way batching NEEDs is. When the response you
were waiting on actually arrives, send a short close-out so the Steward's
picture of the queue stays current:

```bash
thrum send --to @<steward> --stdin <<'EOF'
UNBLOCKED [<topic>]: review came back, resuming.
EOF
```

Keep both messages short — one line of status, not a narrative. The Steward
reads these the same way it reads a NEED: as a judgment agent scanning its
inbox, not a parser expecting a fixed shape.

### Why this is safe to layer on

Nothing here adds a new delivery mechanism, a new command, or a schema — every
example above is `thrum send --stdin <<'EOF' ... EOF`, `thrum reply`, or
`thrum wait`, exactly as documented in the NEED/ANSWER convention. Using a
**quoted** heredoc delimiter (`<<'EOF'`, never bare `<<EOF`) is deliberate: an
unquoted heredoc runs command substitution on backticks and `$()` inside your
message body before it's ever sent, which can silently execute something you
only meant as text. Always quote the delimiter.