@rallycry/conveyor-agent 10.13.71 → 11.0.0

package/skills/conveyor-consensus/references/doc-template.html

@@ -0,0 +1,204 @@
+<!-- Consensus doc skeleton. Proven treatment: observer-memo, banker-blue accent.
+     Swap palette/type ONLY if the subject demands a different identity.
+     Replace every UPPERCASE placeholder. Delete sections that don't apply; keep the order.
+
+     SELF-CONTAINED ON PURPOSE — do not add external references.
+     This file is uploaded to a card and served by the API under a sandbox CSP
+     ("sandbox; default-src 'none'; style-src 'unsafe-inline'; img-src data:").
+     That blocks webfont stylesheets, external CSS/JS, and remote images. The
+     upstream grimoire template linked Google Fonts; it is replaced here with a
+     system stack, because under this CSP the link fails silently and the doc
+     renders in a fallback font with no error. Same rule for charts: the div/CSS
+     bars below work, a JS charting library cannot run at all.
+
+     Images, if you truly need one, must be data: URIs. -->
+<title>DOC NAME</title>
+<style>
+  :root {
+    --bg: #f7f9fb; --surface: #ffffff;
+    --ink: #16222e; --ink-2: #48596a; --ink-3: #74838f;
+    --line: #d9e0e7; --line-soft: #e8edf1;
+    --accent: #20618f; --accent-soft: #dcebf5;
+    --bar: #2e6f9e; --bar-hover: #20618f;
+    --good-ink: #176a44; --good-bg: #ddf0e5;
+    --warn-ink: #8a5d00; --warn-bg: #f6ecd2;
+    --miss-ink: #a13529; --miss-bg: #f9e2de;
+    --neutral-ink: #55606b; --neutral-bg: #e8ecf0;
+    --quote-rail: #c3d5e2;
+  }
+  /* Three-state theming: bare :root = light; media block guarded against explicit light; data-theme block wins for the toggle. */
+  @media (prefers-color-scheme: dark) {
+    :root:not([data-theme="light"]) {
+      --bg: #101720; --surface: #161f2a;
+      --ink: #e4ebf2; --ink-2: #a4b3c1; --ink-3: #7d8c9a;
+      --line: #2b3947; --line-soft: #223040;
+      --accent: #6fadd9; --accent-soft: #1d3346;
+      --bar: #4c88b4; --bar-hover: #6fadd9;
+      --good-ink: #57c48f; --good-bg: #16311f;
+      --warn-ink: #d9a94a; --warn-bg: #34290f;
+      --miss-ink: #e2857a; --miss-bg: #3a1d18;
+      --neutral-ink: #a4b3c1; --neutral-bg: #222d38;
+      --quote-rail: #33506a;
+    }
+  }
+  :root[data-theme="dark"] {
+    --bg: #101720; --surface: #161f2a;
+    --ink: #e4ebf2; --ink-2: #a4b3c1; --ink-3: #7d8c9a;
+    --line: #2b3947; --line-soft: #223040;
+    --accent: #6fadd9; --accent-soft: #1d3346;
+    --bar: #4c88b4; --bar-hover: #6fadd9;
+    --good-ink: #57c48f; --good-bg: #16311f;
+    --warn-ink: #d9a94a; --warn-bg: #34290f;
+    --miss-ink: #e2857a; --miss-bg: #3a1d18;
+    --neutral-ink: #a4b3c1; --neutral-bg: #222d38;
+    --quote-rail: #33506a;
+  }
+
+  body { background: var(--bg); color: var(--ink); font-family: ui-sans-serif, system-ui, "Segoe UI", "Helvetica Neue", Arial, sans-serif; font-size: 16px; line-height: 1.6; margin: 0; padding: 3rem 1.25rem 5rem; }
+  .doc { max-width: 46rem; margin: 0 auto; }
+
+  .eyebrow { font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: 0.72rem; letter-spacing: 0.14em; text-transform: uppercase; color: var(--ink-3); margin: 0 0 0.75rem; }
+  h1 { font-family: ui-serif, Georgia, "Times New Roman", serif; font-weight: 700; font-size: 2.3rem; line-height: 1.15; margin: 0 0 0.5rem; text-wrap: balance; }
+  .dek { color: var(--ink-2); font-size: 1.05rem; max-width: 40rem; margin: 0 0 0.75rem; }
+  .meta { font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: 0.75rem; color: var(--ink-3); margin: 0 0 2.5rem; }
+
+  h2 { font-family: ui-serif, Georgia, "Times New Roman", serif; font-weight: 600; font-size: 1.45rem; line-height: 1.25; margin: 3rem 0 0.9rem; text-wrap: balance; }
+  h2 .sec { font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-weight: 500; font-size: 0.78rem; color: var(--accent); display: block; letter-spacing: 0.12em; margin-bottom: 0.35rem; }
+  p { margin: 0 0 1rem; max-width: 42rem; }
+  a { color: var(--accent); text-decoration-thickness: 1px; text-underline-offset: 2px; }
+  strong { font-weight: 600; }
+
+  .tldr { background: var(--surface); border: 1px solid var(--line); border-left: 3px solid var(--accent); border-radius: 6px; padding: 1.15rem 1.35rem; margin: 0 0 1rem; }
+  .tldr p { margin: 0 0 0.7rem; }
+  .tldr p:last-child { margin: 0; }
+
+  figure { background: var(--surface); border: 1px solid var(--line); border-radius: 6px; margin: 1.5rem 0; padding: 1.25rem 1.35rem 1.1rem; }
+  figcaption { font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: 0.72rem; letter-spacing: 0.1em; text-transform: uppercase; color: var(--ink-3); margin-bottom: 1rem; }
+  .fignote { font-size: 0.78rem; color: var(--ink-3); margin-top: 0.9rem; }
+
+  /* Frequency bar chart: single hue (one series = no legend), direct value labels, hover emphasis + title tooltips. */
+  .barchart { display: flex; flex-direction: column; gap: 7px; }
+  .barrow { display: grid; grid-template-columns: 13.5rem 1fr 2rem; gap: 0.7rem; align-items: center; font-size: 0.85rem; }
+  .barrow .lbl { color: var(--ink-2); text-align: right; line-height: 1.25; }
+  .track { background: var(--line-soft); border-radius: 3px; height: 16px; }
+  .fill { background: var(--bar); border-radius: 3px 4px 4px 3px; height: 100%; transition: background 120ms ease; }
+  .barrow:hover .fill { background: var(--bar-hover); }
+  .barrow .val { font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-variant-numeric: tabular-nums; font-size: 0.8rem; color: var(--ink-2); }
+  .barrow:hover .lbl, .barrow:hover .val { color: var(--ink); }
+
+  /* Head-to-head stacked coverage bars, one row per proposal (+ a Merged row). */
+  .compare { display: flex; flex-direction: column; gap: 10px; }
+  .cmprow { display: grid; grid-template-columns: 8.5rem 1fr; gap: 0.8rem; align-items: center; }
+  .cmprow .who { font-size: 0.85rem; font-weight: 600; text-align: right; color: var(--ink-2); }
+  .scoreboard { display: flex; height: 26px; border-radius: 5px; overflow: hidden; gap: 2px; }
+  .scoreboard div { display: flex; align-items: center; justify-content: center; font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: 0.76rem; font-weight: 500; min-width: 1.4rem; }
+  .sc-good { background: var(--good-bg); color: var(--good-ink); }
+  .sc-warn { background: var(--warn-bg); color: var(--warn-ink); }
+  .sc-miss { background: var(--miss-bg); color: var(--miss-ink); }
+  .sc-legend { display: flex; gap: 1.4rem; margin-top: 0.8rem; font-size: 0.78rem; color: var(--ink-2); flex-wrap: wrap; }
+  .sc-legend span { display: inline-flex; align-items: center; gap: 0.4rem; }
+  .swatch { width: 10px; height: 10px; border-radius: 2px; display: inline-block; }
+
+  /* Verdict + feasibility chips: text always, never color alone. */
+  .chip { display: inline-block; font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: 0.68rem; font-weight: 500; letter-spacing: 0.06em; padding: 0.15rem 0.5rem; border-radius: 999px; white-space: nowrap; }
+  .chip-good { background: var(--good-bg); color: var(--good-ink); }     /* COVERED / API &check; */
+  .chip-warn { background: var(--warn-bg); color: var(--warn-ink); }     /* PARTIAL */
+  .chip-miss { background: var(--miss-bg); color: var(--miss-ink); }     /* MISSED / NOT POSSIBLE */
+  .chip-api  { background: var(--accent-soft); color: var(--accent); }   /* vendor-supported rulings */
+  .chip-ours { background: var(--neutral-bg); color: var(--neutral-ink); } /* OUR BUILD / CONFIG */
+
+  .tablewrap { overflow-x: auto; margin: 1.5rem 0; border: 1px solid var(--line); border-radius: 6px; background: var(--surface); }
+  table { border-collapse: collapse; width: 100%; font-size: 0.86rem; }
+  th { font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: 0.68rem; letter-spacing: 0.1em; text-transform: uppercase; color: var(--ink-3); font-weight: 500; text-align: left; padding: 0.7rem 1rem; border-bottom: 1px solid var(--line); }
+  td { padding: 0.6rem 1rem; border-bottom: 1px solid var(--line-soft); vertical-align: top; color: var(--ink-2); }
+  td:first-child { color: var(--ink); font-weight: 600; }
+  tr:last-child td { border-bottom: none; }
+  td.nowrap { white-space: nowrap; }
+
+  blockquote { border-left: 3px solid var(--quote-rail); margin: 1.1rem 0; padding: 0.1rem 0 0.1rem 1.1rem; color: var(--ink-2); font-style: italic; max-width: 40rem; }
+  blockquote cite { display: block; font-style: normal; font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; font-size: 0.72rem; color: var(--ink-3); margin-top: 0.35rem; }
+
+  ol.twocents { padding-left: 1.3rem; max-width: 42rem; }
+  ol.twocents li { margin-bottom: 0.85rem; }
+  ol.twocents li::marker { font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; color: var(--accent); font-size: 0.85rem; }
+
+  .method { border-top: 1px solid var(--line); margin-top: 3.5rem; padding-top: 1.25rem; font-size: 0.8rem; color: var(--ink-3); max-width: 42rem; }
+</style>
+
+<div class="doc">
+  <p class="eyebrow">Outside read &middot; No stake in the outcome</p>
+  <h1>DOC NAME</h1>
+  <p class="dek">ONE-SENTENCE FRAME: who pulled what, and what this doc rules on.</p>
+  <p class="meta">~N messages &middot; DATE &rarr; DATE &middot; N channels/sources &middot; input to DECISION/CARD</p>
+
+  <div class="tldr">
+    <p><strong>VERDICT SENTENCE.</strong> Two to three bold-led paragraphs; a reader who stops here can act.</p>
+  </div>
+
+  <h2><span class="sec">01</span>What the evidence says</h2>
+  <p>How findings were binned; what a count means.</p>
+  <figure>
+    <figcaption>FINDINGS BY INCIDENT COUNT, RANGE</figcaption>
+    <div class="barchart">
+      <!-- width = count / max * 100%. title attr = one-line version for hover. -->
+      <div class="barrow" title="ONE-LINER"><span class="lbl">CATEGORY</span><div class="track"><div class="fill" style="width:100%"></div></div><span class="val">15</span></div>
+      <div class="barrow" title="ONE-LINER"><span class="lbl">CATEGORY</span><div class="track"><div class="fill" style="width:60%"></div></div><span class="val">9</span></div>
+    </div>
+    <div class="fignote">Dominant sources; hover note.</div>
+  </figure>
+  <blockquote>"VERBATIM QUOTE"<cite>WHO &middot; #channel &middot; DATE</cite></blockquote>
+
+  <h2><span class="sec">02</span>What already exists</h2>
+  <p>Incumbent system, prior art, negative results ("no payout code in the repo").</p>
+
+  <h2><span class="sec">03</span>PROPOSAL A, scored</h2>
+  <div class="tablewrap">
+    <table>
+      <thead><tr><th>Pain / need</th><th>Verdict</th><th>Why</th></tr></thead>
+      <tbody>
+        <tr><td>ITEM</td><td class="nowrap"><span class="chip chip-good">COVERED</span></td><td>ONE SENTENCE.</td></tr>
+        <tr><td>ITEM</td><td class="nowrap"><span class="chip chip-warn">PARTIAL</span></td><td>Symptom yes, root cause no.</td></tr>
+        <tr><td>ITEM</td><td class="nowrap"><span class="chip chip-miss">MISSED</span></td><td>ONE SENTENCE.</td></tr>
+      </tbody>
+    </table>
+  </div>
+
+  <!-- Repeat 03 per proposal, then head-to-head: -->
+  <figure>
+    <figcaption>Head to head: N items each</figcaption>
+    <div class="compare">
+      <div class="cmprow"><span class="who">Proposal A</span>
+        <div class="scoreboard"><div class="sc-good" style="flex:3">3</div><div class="sc-warn" style="flex:5">5</div><div class="sc-miss" style="flex:3">3</div></div>
+      </div>
+      <div class="cmprow"><span class="who">Merged</span>
+        <div class="scoreboard"><div class="sc-good" style="flex:10">10</div><div class="sc-warn" style="flex:1">1</div></div>
+      </div>
+    </div>
+    <div class="sc-legend">
+      <span><span class="swatch" style="background:var(--good-bg);border:1px solid var(--good-ink)"></span>covered</span>
+      <span><span class="swatch" style="background:var(--warn-bg);border:1px solid var(--warn-ink)"></span>symptom yes, root cause no</span>
+      <span><span class="swatch" style="background:var(--miss-bg);border:1px solid var(--miss-ink)"></span>not in the plan</span>
+    </div>
+  </figure>
+
+  <h2><span class="sec">04</span>The merged plan, with rulings</h2>
+  <div class="tablewrap">
+    <table>
+      <thead><tr><th>Blueprint item</th><th>Feasibility</th><th>Detail</th></tr></thead>
+      <tbody>
+        <tr><td>ITEM</td><td class="nowrap"><span class="chip chip-api">API &check;</span></td><td>Ruling + <a href="ENDPOINT-DOC-URL">endpoint link</a>.</td></tr>
+        <tr><td>ITEM</td><td class="nowrap"><span class="chip chip-ours">OUR BUILD</span></td><td>Ruling.</td></tr>
+        <tr><td>ITEM</td><td class="nowrap"><span class="chip chip-miss">NOT POSSIBLE</span></td><td>Why, and whether the impossibility is desirable.</td></tr>
+      </tbody>
+    </table>
+  </div>
+
+  <h2><span class="sec">05</span>The two cents</h2>
+  <ol class="twocents">
+    <li><strong>RECOMMENDATION.</strong> The argument for it.</li>
+  </ol>
+
+  <div class="method">
+    <p><strong>Method.</strong> Queries run, counts, date range, what was reviewed in full, what was verified against primary sources, and what was NOT done.</p>
+  </div>
+</div>

package/skills/conveyor-local-loop/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: conveyor-local-loop
+description: Run this machine as a serial local claudespace — pick the session owner's highest-priority Open Conveyor card, claim it, execute its plan to the PR finish line, repeat. Handles single cards AND whole packs (an Open pack parent is driven end-to-end per conveyor-build's pack path, then the loop moves on once the pack's final PR is open). One invocation = one iteration; run continuously with "/loop /conveyor-local-loop" (no interval) and it self-paces (~1-2 min between cards while the queue has work; when the queue is empty it blocks on live board events via conveyor-wait and wakes seconds after a card becomes claimable, with a ~25 min fallback poll). Use when the user says "/conveyor-local-loop", "start the local loop", "work my open cards locally", or wants planned cards executed with full local CPU/RAM instead of spawning claudespaces. For exactly one card, or one pack and nothing else, use conveyor-build.
+---
+
+# Conveyor Local Loop
+
+Turn a queue of researched Open cards (usually authored via `/conveyor-plan`)
+into review-ready PRs using this machine, one card at a time. Behave exactly as
+a claudespace agent would: the card IS the spec, task chat is the log, and the
+host repo's CLAUDE.md governs gates, verification, and PR mechanics. This skill
+adds only selection, claiming, cadence, and local-machine hygiene.
+
+## Ground rules
+
+- **Conveyor is the state store.** The loop session spans days and gets
+  compacted; at each iteration re-derive state from MCP reads, never from
+  conversation memory.
+- **All Conveyor tools fully-qualified** (`mcp__conveyor__get_task`; bare names
+  fail).
+- **WIP = 1.** At most one card claimed by this loop at a time.
+- **Never `start_task`** — that boots a cloud pod and duplicates the work. Only
+  exception: the opt-in offload valve below.
+- **Never approve or merge your own PRs.** Finish line = card in ReviewPR with
+  green CI; the user takes it from there.
+- **Only cards created by the session owner** (match against
+  `mcp__conveyor__get_connection_context`), status Open, unassigned. Teammates'
+  cards and pod-claimed cards are off limits.
+- **Pack cards: claim the whole pack; the parent card stays parked.** An Open
+  feature-branch pack parent that passes the claiming filters is claimable as
+  a PACK: enter pack mode (below) and drive every child to the final parent
+  PR per [conveyor-build's pack path](../conveyor-build/references/pack-path.md). Throughout,
+  the parent card itself stays PARKED — never Build/`start_task` it, never
+  set it InProgress; the finale `create_pull_request` is what moves it to
+  ReviewPR. A parent already InProgress/ReviewPR has (or had) an active
+  coordinator — hands off it AND its children: an actively-orchestrating
+  parent reads a headless InProgress child as a dead agent environment and
+  "recovers" it onto a cloud pod (observed 2026-07-28 — duplicate
+  implementation). A NON-feature-branch pack — children PR straight into dev,
+  so there is no pack branch to coordinate — is never claimed as a pack:
+  conveyor-build's pack path explicitly does not apply to it. Claim those children
+  individually, one per iteration, and only while the parent is parked.
+- **Run in the main workspace checkout — never a git worktree.** The fully
+  provisioned main workspace (installed `node_modules`, `.env`/direnv auth
+  wiring, the running dev stack) is the whole value of local execution;
+  worktrees miss all of it and have consistently degraded agent sessions.
+  Clean tree before any branch switch is still a hard rule: dirty
+  `git status` at iteration start → touch nothing, report, and idle — the
+  resolution is the user committing or stashing, not a second checkout.
+- **Push early.** There is no pod WIP-autosync locally; committed-and-pushed is
+  the only durable state. Push the branch (`-u origin`) as soon as it exists.
+
+## Iteration order
+
+Each invocation does the FIRST of these that produces work, then paces:
+
+1. **Recover** — a card with my `[local-loop] claimed` chat marker still
+   InProgress without a PR? Resume it. The branch may already exist locally or
+   on origin — check both before re-implementing anything. A pack parent
+   whose chat carries my `[local-loop] claimed — driving this pack` marker
+   and isn't yet in ReviewPR? Resume pack mode — re-derive where it left off
+   from `mcp__conveyor__list_subtasks`, never from session memory. Skip a
+   parent whose LATEST marker is `[local-loop] parked:` with no human reply
+   after it — that pack yielded the WIP slot and stays yielded until the user
+   replies; fall through to the next tier.
+2. **Babysit** — my loop-opened PRs (ReviewPR cards, pack finale PRs
+   included): red CI → fix now (on a pack finale, directly on the pack
+   branch); request-changes or unanswered review comments → address now;
+   green and quiet → leave alone.
+3. **Claim** the next card (below).
+4. **Idle** — nothing claimable: arm the board-event wake (below), then pace long.
+
+## Claiming
+
+1. `mcp__conveyor__list_tasks` with `status: "Open"` — results are already
+   priority-then-newest ordered; board priority IS the intelligence, don't
+   invent your own ranking. Walk top-down, `mcp__conveyor__get_task` each until
+   one passes: created by me, no assignee or active session, an executable
+   plan (a pack parent that still needs breakdown is fine — breakdown is
+   pack-mode work), all `mcp__conveyor__get_dependencies` blockers Complete,
+   no `[local-loop] parked:` chat marker without a later human reply (a reply
+   un-parks), and the pack rules hold: a FEATURE-BRANCH pack parent (children
+   branch from and PR into a pack branch — including one planned as a pack
+   that has no children yet) is claimed as a PACK → pack mode below; a
+   non-feature-branch parent, whose children PR straight into dev, is never
+   claimable — take its children one at a time instead; a card with a
+   `parentTaskId` only while the parent's status is neither InProgress nor
+   ReviewPR (see ground rules).
+   Skip `followParentStatus` mirror children. A blocker counts as met only
+   when merged-or-beyond (ReviewDev/ReviewLive/Complete) or Cancelled — a
+   blocker sitting in ReviewPR is NOT met until its PR merges.
+2. Claim: re-confirm via `get_task` it is still Open, then
+   `mcp__conveyor__update_task` → `status: "InProgress"`, then
+   `mcp__conveyor__post_to_chat`: `[local-loop] claimed — working locally on
+   <hostname>`. Claiming a PACK is different — never set the parent
+   InProgress: leave it Open and post the pack claim marker instead (see Pack
+   mode). Status changed under you → someone else took it; next
+   candidate.
+3. Plan missing or failing the context-free-reader bar → don't wing it: post
+   what's missing to chat, leave the card Open, skip it.
+
+## Execute and finish
+
+**Execution is [conveyor-build](../conveyor-build/SKILL.md)** — resolving the
+card, branching from its base, working the plan, gating, and opening the PR
+with an explicit `base:`. That skill is the source of truth; do not re-derive
+its procedure here. It routes a childless card to its task path and a
+feature-branch pack to its pack path automatically.
+
+This section adds only what the LOOP changes:
+
+- **Chat markers carry the loop's prefix**, `[local-loop]` rather than
+  `[build]`, because the Recover tier greps for them to find its own work.
+- **A pack child yields to a live coordinator.** Before opening a child's PR,
+  re-check the parent's status; if it went InProgress or ReviewPR, post
+  `[local-loop] parked: pack coordinator active — yielding`, leave the branch
+  pushed, and let the coordinator take over.
+- **Do not wait on CI.** Confirm it started (read-only `gh pr checks`) and end
+  the iteration — the Babysit tier owns it from there. This is the loop's one
+  real departure from a standalone build, which stays with its PR.
+
+**Parked protocol** — after 2 genuinely different failed approaches, or on a
+decision only the user can make: post `[local-loop] parked: <reason + the
+specific question>`, set status back to `"Open"`, restore the tree
+(`git checkout dev`), move on. The user's next chat reply is the un-park
+signal.
+
+## Pack mode
+
+Claiming an Open pack parent means driving the ENTIRE pack, exactly per
+[conveyor-build's pack path](../conveyor-build/references/pack-path.md) —
+setup (pack branch on origin, the `githubBranch` write-through, child breakdown
+if the parent has none yet), children serially in dependency order,
+reviewer-of-record review + merge of each child PR into the pack branch,
+dev→pack sync after every merge, cross-reference, then the finale parent PR
+into dev. That reference is the source of truth for the procedure; this section
+only defines how it embeds in the loop:
+
+- The pack occupies the loop's single WIP slot from claim until the finale PR
+  opens. Do not interleave unrelated cards mid-pack — that thrashes branch
+  state.
+- Claim marker goes to the PARENT chat: `[local-loop] claimed — driving this
+  pack locally on <hostname>, pack branch <branch>`. The parent's status
+  stays Open (parked); the marker is the claim.
+- Once the finale PR is open (parent in ReviewPR), the pack leaves the WIP
+  slot: its PR joins the Babysit tier like any other loop-opened PR, and the
+  loop resumes claiming other cards. This is the one difference from
+  a standalone conveyor-build pack run, which stops when the pack is done.
+- Parked children follow the pack path's parked protocol. If every
+  remaining child is blocked on the user, the pack yields the WIP slot: post
+  `[local-loop] parked: <what it is waiting on>` to the PARENT chat — that
+  marker is what makes the Recover tier skip the pack — and the loop claims
+  other cards. The user's chat reply un-parks it, and the next Recover tier
+  retakes the slot.
+
+## Waking on board events
+
+An empty queue is not a quiet board. Rather than sleeping blind for 25 minutes,
+arm `conveyor-wait`: a CLI in `@rallycry/conveyor-mcp` that subscribes to the
+project's live card stream and exits the moment a card ENTERS a claimable
+state. A card created Open, a Cancelled card reopened, and a card reassigned to
+you all count; an edit to a card that already matched does not.
+
+Arm it on an idle iteration only (tier 4), and only when no wait from an earlier
+iteration is still running:
+
+```bash
+node_modules/.bin/conveyor-wait --scope mine,unclaimed --timeout 1740
+```
+
+Launch it with Bash `run_in_background: true` and end the turn. Its completion
+notification is the wake. The `ScheduleWakeup` you still arm is the fallback for
+the case where the wait dies silently — use the pacing table's background-gate
+row (1200–1800s), not a second, shorter timer.
+
+- Prefer `node_modules/.bin/conveyor-wait`. If it is absent, use
+  `npx -y -p @rallycry/conveyor-mcp@latest conveyor-wait`. The `-p` form
+  matters: inside the conveyor monorepo a bare
+  `npx @rallycry/conveyor-mcp` misresolves.
+- Narrow `--types` to whatever focus the user gave the loop invocation —
+  "focus on incidents" → `--types incident`. The default watches tasks,
+  incidents, and suggestions.
+- `--scope mine,unclaimed` mirrors the claiming filter: cards assigned to the
+  session owner plus unassigned cards. Use `--scope all` only when the user
+  asked the loop to watch the whole board.
+- `--statuses` defaults to `Open`, which is the claimable lane. Leave it alone
+  unless the user asked for something else.
+- Credentials come from the environment, then any `.mcp.json` from the working
+  directory up, then `~/.claude.json`. An agent Bash shell does not inherit the
+  MCP server's environment, so that file fallback is what makes this work at
+  all. Exit 1 means the wait could not run: no credentials, a rejected token, or
+  a project it cannot read. Read the stderr line, report it once, fall back to
+  plain timed polling, and do not re-arm it every iteration.
+
+**The result is advisory — the queue is still the source of truth.** The CLI
+prints one line of JSON and exits 0 in every non-error case:
+
+```
+{"reason":"event","card":{"id":…,"slug":…,"title":…,"type":…,"status":…,"assignedUserId":…}}
+{"reason":"timeout"}
+{"reason":"interrupted"}
+```
+
+On wake, run a normal iteration and re-enumerate with
+`mcp__conveyor__list_tasks`. By then the card may be claimed, cancelled, or
+blocked by a dependency — never claim straight from the wait payload.
+
+**Never arm a second wait.** On a wake where a wait process is still in flight
+and the queue is still empty, re-arm the fallback `ScheduleWakeup` and end the
+turn.
+
+## Pacing (dynamic /loop only)
+
+Under `/loop` with no interval, end EVERY iteration with exactly one
+`ScheduleWakeup` (prompt = the original /loop input verbatim):
+
+| State | Delay | Reason should say |
+|-------|-------|-------------------|
+| A background gate/agent/conveyor-wait is in flight — its completion notification is the real wake | 1200–1800s fallback | "fallback while <gate> runs — its notification wakes me sooner" |
+| ANY actionable work exists: claimable cards or packs, a pack child to implement/merge, a PR still to open, red/pending CI, review comments | 60–90s | queue depth / which item is next |
+| Queue enumerated as empty THIS iteration, all loop PRs green and quiet | 1200–1800s | queue empty; conveyor-wait armed, so this is only the fallback |
+| Loop-fatal: MCP dead after 2 tries, dirty tree, broken repo | notify the user (PushNotification if available), then 1800s — or `stop: true` if continuing is unsafe | what is wrong |
+
+The long idle tier is EARNED, never defaulted: it requires having enumerated
+the queue this very iteration and found zero actionable work. When unsure
+which tier applies, take the short one — a wasted 60s wake costs less than a
+30-minute stall on live work.
+
+Invoked bare (no /loop)? Run one iteration, report, and suggest
+`/loop /conveyor-local-loop` — don't self-schedule.
+
+## Offload valve (opt-in)
+
+Only with an explicit `offload=N` argument: when 4+ claimable cards queue up,
+`mcp__conveyor__start_task` up to N of the smallest into claudespaces and say
+so in the iteration summary. Without the argument, never — just report backlog
+depth each iteration so the user can offload manually.
+
+## What this is not
+
+- Not a reviewer of anything headed for `dev`: never `approve_task`,
+  `request_changes`, or `approve_and_merge_pr` on a PR into `dev` — including
+  a pack's final parent PR. **The one exception is a pack's CHILD PRs into the
+  pack branch**, where you are the reviewer of record because the automated
+  reviewer skips that target; the pack path spells out that duty.
+- Not a pod: no sandbox, no WIP snapshots, and the dev DB + dev-server ports
+  are shared with the user's interactive sessions — no destructive
+  experiments, never reset the dev DB, reuse a running dev stack rather than
+  fighting over ports.
+- Not a parallel executor: one card (or one pack) at a time is the point (the
+  full machine per gate). Backlogged? That is what claudespaces — or the
+  offload valve — are for.
+
+## Improve This Skill
+
+If this skill was insufficient or slowed the work down, file it with
+`mcp__conveyor__create_suggestion` on the Conveyor project: the issue,
+evidence, and proposed fix.

package/skills/conveyor-meeting-review/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: conveyor-meeting-review
+description: Turn a Conveyor meeting into confirmed cards, packs, and glossary updates — read the meeting and its transcript, cross-reference what already exists, draft proposals at the plan-quality bar, and create only what a human confirms item by item. Use when the user says "/conveyor-meeting-review <meeting>", "turn that meeting into cards", "what should we do about yesterday's call", or asks for the follow-ups from a meeting. Never creates anything unasked.
+---
+
+# Conveyor Meeting Review
+
+A meeting becomes work only when a person says which parts should. This skill does the reading, the cross-referencing, and the drafting — and then **stops and asks**.
+
+## The one rule
+
+**Never create, edit, or tag anything before a human confirms that specific item.** Not "shall I proceed?" and then everything — item by item, so "create 1 and 3, skip 2" is a normal answer.
+
+This is not caution for its own sake. A meeting transcript is full of things that *sound* like decisions: someone thinking out loud, an idea that was argued down two minutes later, a "we should probably…" that nobody agreed to. An agent that creates cards from those is manufacturing work the team never chose, on a board they have to clean up. The summary's `## Proposed Next Steps` is a **starting point, not a mandate** — it was written by a model reading the same ambiguous transcript.
+
+## 1 — Read
+
+1. `mcp__conveyor__get_connection_context` — where you are. Same call in a pod and a local MCP session.
+2. `mcp__conveyor__get_meeting` — the overview, the decisions, the proposed next steps, and the participants. **This usually answers the question.** It costs a fraction of the transcript.
+3. `mcp__conveyor__read_meeting_transcript` — only when you need exact wording: a quote, a caveat, the reasoning behind a decision the summary merely states, or a check on whether something was actually agreed. Page with `offset`/`nextOffset` rather than pulling the whole thing.
+
+If `status` is `processing` the summary is still being written — read the transcript, or say so and offer to come back. If `status` is `failed`, `summaryError` says why; the transcript is still complete and readable.
+
+## 2 — Cross-reference before drafting anything
+
+Skipping this is how a meeting review produces four cards that duplicate work already in flight.
+
+- `mcp__conveyor__list_tags` — the project's vocabulary. Use its words in your proposals; a card that names the same thing differently is a card nobody finds.
+- `mcp__conveyor__search_tasks` — **two or three keyword variants per proposed topic**, across `task`, `incident` and `suggestion`. One search misses the card that used the other word for it.
+- `mcp__conveyor__read_task_chat` on anything that looks close. The overlap is usually in the discussion, not the title.
+
+Then say what you found, including the negatives: "this one already exists as `fix-the-thing`", "nothing on the board covers this", "there is a suggestion arguing the opposite".
+
+## 3 — Draft at the plan-quality bar
+
+Each proposal a context-free reader could execute: what changes, where (file paths where you know them), and how it is verified. The `/conveyor-plan` skill's `references/plan-format.md` is the bar. A one-line card that says "improve onboarding" is not a proposal, it is a note.
+
+Classify honestly:
+
+- **A card** — one coherent piece of work.
+- **A pack** — a parent plus children, when the work has real internal ordering. Do not inflate a card into a pack for ceremony.
+- **An edit to an existing card** — usually better than a new one when something is already in flight. Say which card and what changes.
+- **A tag update** — the glossary learned a word.
+- **A suggestion** — the meeting raised something worth recording that nobody has decided to do. This is the honest home for "we should look into X someday", and it keeps the board clean.
+- **Nothing** — some meetings produce no work. Say so rather than finding something.
+
+## 4 — Present and wait
+
+Number the proposals. For each: the type, the title, one sentence of what it is, and — critically — **what in the meeting supports it**, with a speaker and roughly when. A proposal whose evidence you cannot name is one you inferred, and it should be labelled as such or dropped.
+
+Flag separately:
+
+- **Decisions that need a human**, which a card cannot settle.
+- **Contradictions** — where the meeting disagreed with itself, or with a card already on the board.
+- **Things you deliberately did not propose**, and why. That is often the most useful part.
+
+Then wait. If the reply is partial ("1 and 3"), create exactly those.
+
+## 5 — Create, and stamp the provenance
+
+Only the confirmed items, through the normal card tools — `create_task`, `create_subtask`, `add_dependency`, `update_task`, `manage_tags`, `create_suggestion`. There is no meeting-specific write path, on purpose: a card born from a meeting should be indistinguishable from any other card, and reviewable the same way.
+
+**Stamp every created card with the meeting link** from `get_meeting`'s `url` field, in the description or the plan. Six weeks later "why does this card exist" is a real question, and the answer should be one click away.
+
+Report back with what was created and what was skipped.
+
+## Environment notes
+
+- All Conveyor tools are **fully qualified** (`mcp__conveyor__get_meeting`); bare names fail.
+- The meeting tools are **deferred** — reach them via ToolSearch rather than expecting them preloaded.
+- They appear only for a project that HAS meetings. If they are absent, the project has none; say so instead of hunting.
+- A pod and a local MCP session run this identically. The only difference is where you report: in a pod, card chat.