@rallycry/conveyor-skills 1.0.5 → 1.0.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rallycry/conveyor-skills",
-  "version": "1.0.5",
+  "version": "1.0.6",
   "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

@@ -33,10 +33,9 @@ out in an **Environment** note — never assume; check which one you are in.
 - **Never boot another environment for work you are doing.** Locally that
   means never `mcp__conveyor__start_task` (it exists only on the local/MCP
   surface, and it spawns a cloud pod that duplicates you). In a pod driving a
-  pack it means never `mcp__conveyor__start_child_cloud_build` /
-  `mcp__conveyor__stop_child_build` — you implement the children yourself,
-  serially. Parallel fan-out is a deliberate choice the user makes by pressing
-  Build on the parent, not something a build session opts into.
+  pack there is no tool that fires a child build at all — you implement the
+  children yourself, serially. A pack has one execution model in both
+  environments: one session owns all the state.
 
 ## Goal and finish line
 

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

@@ -19,7 +19,8 @@ alternative is where pack incidents come from.
    parent already InProgress/ReviewPR has a coordinator — report and stop
    rather than compete.
 2. **Ensure the pack branch exists on origin.** Use the card's `githubBranch`
-   if set; otherwise cut `ft/<parent-slug>` from `origin/dev`, push `-u`, and
+   if set; otherwise cut `ft/<parent-slug>` from `origin/<base>` (the card's base
+   branch — usually `dev`), push `-u`, and
    IMMEDIATELY record it: `mcp__conveyor__update_task` with
    `githubBranch: <branch>`.
 
@@ -162,6 +163,12 @@ spell the argument differently (`base:` locally, `baseBranch:` in a pod).
 > always opens the PR for the card the session is bound to, so mid-pack it would
 > open the PARENT's PR early and strand every remaining child. One commit per
 > child keeps the single final PR reviewable child by child.
+>
+> Every child status write carries the child's id: claim with
+> `mcp__conveyor__update_task(task_id: <child>, status: "InProgress")` and land
+> with `update_task(task_id: <child>, status: "ReviewDev")`. Without `task_id`
+> the write targets the PARENT card you are bound to. No per-child build fires
+> in a pod, so a status you do not write is a board that silently lies.
 
 Before opening the child's PR, re-check the parent's status. If it went
 InProgress or ReviewPR, a coordinator took over: post that you are yielding,
@@ -224,12 +231,11 @@ leave the branch pushed, and stop.
    `githubBranch: <pack>`), advance the child by hand (`update_task` →
    `ReviewDev`), and post the drift to parent chat so it is visible.
 3. **Sync `dev` into the pack branch — yours to do, in either environment.**
-   (The fan-out cloud path had the server do this before each child launch; a
-   session driving the pack itself gets no such help and resolves conflicts
-   in-session.)
+   Nothing server-side syncs the pack branch for you; a session driving the
+   pack resolves conflicts in-session.
 
    ```bash
-   git checkout <pack> && git pull && git fetch origin dev && git merge origin/dev --no-edit && git push
+   git checkout <pack> && git pull && git fetch origin <base> && git merge origin/<base> --no-edit && git push
    ```
 
    **Merge, never rebase** — the pack branch is shared with open child PRs and
@@ -238,7 +244,7 @@ leave the branch pushed, and stop.
 
    If the merge drags in unrelated changes or errors, `dev` may have been
    rewound (a revert or force-push). Verify the previous sync point is still an
-   ancestor of `origin/dev` (`git merge-base --is-ancestor`); if it is not,
+   ancestor of `origin/<base>` (`git merge-base --is-ancestor`); if it is not,
    abort the merge and escalate rather than chasing the noise.
 4. Report the merge to parent chat in a line or two.
 
@@ -248,7 +254,7 @@ leave the branch pushed, and stop.
    pack branch's actual state against the acceptance and verification criteria
    — a real checklist pass, not a vibe. Small gap → fix on the pack branch.
    Substantial gap → a new child card with a plan, and the loop continues.
-2. Pre-PR protocol on the pack branch: sync `origin/dev` FIRST, then ONE
+2. Pre-PR protocol on the pack branch: sync `origin/<base>` FIRST, then ONE
    verification pass scoped to the pack's cumulative diff against `dev`
    (cross-package packs earn the full suite).
 3. `mcp__conveyor__create_pull_request` on the PARENT: `head:` the pack branch,

package/skills/conveyor-review/SKILL.md

@@ -151,8 +151,8 @@ which no pod reviewer could follow. Same defect the story-points paragraph below
 already records.
 
 Story points are deliberately NOT yours to change. `update_task`'s agent
-surface omits `storyPointValue` on purpose, and a pod review session has no
-tool that carries it — so this used to be an instruction no reviewer could
+surface omits `storyPointValue` on purpose, and no pod tool carries the card's
+OWN story points — so this used to be an instruction no reviewer could
 follow. It is also a gate you sit behind rather than above: story points set
 the card's graduated merge minimum, so a reviewer that could lower them would
 be lowering the bar for merging the very PR under review. Flag a mis-sized
@@ -173,6 +173,19 @@ is the reviewer, and the independent review happens later on the pack's PR into
 - You wrote this code, which makes self-review the weak point. An independent
   reviewer with the diff and no memory of writing it catches what you cannot.
 
+## Reviewing a pack's finale PR
+
+A pack parent's PR into the base branch is an ordinary review of the pack's
+cumulative diff — there is no coordination job. The parent's own session
+implemented every child, so read the whole diff against the base and render one
+verdict as above. Child cards have no merge gate of their own, so correcting a
+CHILD's story points with `mcp__conveyor__update_subtask` (`storyPointValue`)
+when the actual work diverged from the estimate is legitimate here, in either
+direction — where the tool exists: a pod's review runner and a local session
+carry it, a task session flipped to review does not (flag the mis-size in the
+verdict instead). The parent card's own story points stay off-limits per the
+note above.
+
 ## Blocked
 
 If the PR cannot be reviewed as it stands — the plan is missing, the diff is