@rallycry/conveyor-skills 1.0.2 → 1.0.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rallycry/conveyor-skills",
-  "version": "1.0.2",
+  "version": "1.0.4",
   "description": "Shared Claude Code skills for Conveyor consumer repos, linked into .claude/skills via the conveyor-skills CLI",
   "keywords": [
     "claude",

package/skills/conveyor-build/SKILL.md

@@ -122,7 +122,10 @@ parked and the chat marker IS the claim.
 
 Post to chat at real milestones only — claim, a blocking discovery, gates
 green, PR — never play-by-play. Your turn output is not visible to the team;
-chat is.
+chat is. Post a blocking discovery with `milestone: "blocked"` only if you are
+actually parked and cannot continue until a human acts — it is a quiet parking
+note that pages nobody. When you need an answer, ask with AskUserQuestion; that
+is what pages a person.
 
 **Saving the plan and card fields:** `mcp__conveyor__update_task` handles
 title, description, plan, status, and `githubBranch` on both surfaces. Story
@@ -233,13 +236,14 @@ the merged base.
 
 The card is in ReviewPR. What happens next depends on who is driving:
 
-> **Environment — a pod is woken; a standalone local run is not.** In a **pod**
-> you stay wake-able: the system wakes you on CI results and review comments,
-> so go idle rather than polling. In a **standalone local run** there is no
-> wake mechanism — report the card and PR state to the user and STOP. No
-> pacing, no loop, no babysitting; a follow-up CI fix is a fresh ask. Under
-> `conveyor-local-loop` the loop's own Babysit tier owns aftercare instead, and
-> its pacing rules govern.
+> **Environment — a pod is woken; a standalone local run is not.** In a
+> **pod** you stay wake-able: the system wakes you on CI results and review
+> comments, so go idle rather than polling. That holds only once the PR exists
+> — mid-pack, nothing wakes either environment (see the pack path's pacing
+> rule). In a **standalone local run** there is no wake mechanism — report the
+> card and PR state to the user and STOP. No pacing, no loop, no babysitting;
+> a follow-up CI fix is a fresh ask. Under `conveyor-local-loop` the loop's
+> own Babysit tier owns aftercare instead, and its pacing rules govern.
 
 When you are the one handling it:
 

package/skills/conveyor-build/references/pack-path.md

@@ -82,23 +82,44 @@ session memory for pack state.
 
 Work children **one at a time**. Interleaving them thrashes branch state.
 
-## Pacing — a pack is many turns, not one
-
-A pack of any size will not fit in a single turn, and there is no partial
-credit for a tree left mid-child. Treat **one iteration = one step** (implement
-one child, or merge one, or the finale) and end the turn on a committed,
-pushed state.
-
-- Driven by `/loop` (locally) or woken by events (in a pod): do one step, then
-  end the turn. Under `/loop` with no interval, arm the next wake before
-  ending — short (60–90s) while there is a child ready to work, long
-  (1200–1800s) while waiting on something external, and **stop the loop** once
-  the finale PR is open and quiet.
-- Invoked bare with no loop: do one step, report where the pack stands and what
-  the next step is, and stop. Do not self-schedule.
+## Pacing — a pack is many steps, not many turns
+
+A child boundary is not a turn boundary. Keep driving the pack in the same
+turn: merge, implement the next child, merge, cross-reference, finale. Nothing
+wakes a pack session between children — not locally, and not in a pod, where
+children have no PRs, no builds, and no CI to generate an event. A turn that
+ends with a child still ready is a stalled pack, not a paused one: locally it
+sits until a human re-runs the skill; in a pod it idles out, sleeps, and waits
+on the pack watchdog — roughly an hour lost per occurrence.
+
+End a turn with children remaining ONLY when a wake is guaranteed:
+
+- **A background gate is in flight.** Its completion notification re-invokes
+  you. (Launch it with the harness's `run_in_background`; hand-rolled
+  backgrounding wakes nothing.)
+- **You are blocked on a human** — the parked protocol below. The user's chat
+  reply is the wake.
+- **The finale PR is open and quiet** — the Babysit tier. Green and quiet is
+  the end.
+
+Any other end-of-turn must arm `ScheduleWakeup` first: 60–90s, prompt
+restating which child comes next. That is the pod-sanctioned mechanism (the
+pod prompt allows `ScheduleWakeup` exactly when nothing else will notify you),
+and it is a rare exception, not the cadence. Never end a turn "to report
+progress" — chat is where progress goes, and posting there does not end the
+pack.
+
+**Pre-exit invariant.** Before ending ANY turn, re-run
+`mcp__conveyor__list_subtasks`. A child that is `Open` with its dependencies
+met, or `InProgress` under your claim, plus no background job in flight and no
+parked question outstanding, means you are not done: continue, or arm the
+wake. Ending a turn in that state without a wake is the bug this section
+exists to prevent.
 
 `conveyor-local-loop` supplies its own pacing table and its own claim-marker
-prefix; when running under it, those govern.
+prefix; when running under it, those govern. Under `/loop` the invariant above
+still holds — the loop's re-invocation is a fallback for a dropped wake, never
+a reason to stop after one child.
 
 ## Implement a child
 

package/skills/conveyor-plan/SKILL.md

@@ -134,8 +134,11 @@ touching Conveyor, unless they asked you to just ship it.
 > create a NEW card, which is the local/MCP shape; `mcp__conveyor__create_task`
 > does not exist in a pod. In a pod, the card exists and you are on it: save
 > the plan with `mcp__conveyor__update_task` (`plan`, and `description` if it
-> needs sharpening), post the same recommendation message to chat, and stop —
-> a pod does not promote its own card to Open. If the pod also has to leave
+> needs sharpening), post the same recommendation message to chat with
+> `milestone: "plan_ready"`, and stop — a pod does not promote its own card to
+> Open. A parked plan is never `blocked`: that milestone means you cannot
+> continue until a human acts, and it pages nobody. To page a person, ask them
+> with AskUserQuestion. If the pod also has to leave
 > plan mode, note that `update_task` carries no story points or risk; those go
 > through `mcp__conveyor__update_task_properties`. Everything in Phases 1-3 is
 > identical in both environments. To break a large pod card into a pack, use