@rallycry/conveyor-skills 1.0.8 → 1.0.10

package/README.md

@@ -19,6 +19,7 @@ normal dependency bumps: no git submodules, no manual syncing.
 | `conveyor-review` | `/conveyor-review <card>` | Review the PR against its plan and render one verdict, with risk |
 | `conveyor-consensus` | `/conveyor-consensus <question>` | Sweep the sources a project actually has, count what happened, score the proposals against those counts, and attach an HTML verdict to the card |
 | `conveyor-local-loop` | `/loop /conveyor-local-loop` | Run this machine as a serial local agent: claim Open cards and packs, build to PR, repeat |
+| `conveyor-prune` | `/conveyor-prune [project\|all]` | Sweep every Planning/Open card, give each one disposition (cancel, park on hold, merge into a pack, keep), apply only the confirmed rows (local surface only) |
 
 **One skill per lifecycle phase:** triage an unverified report → plan the work →
 start it in the cloud *or* build it here → review it. `start` and `build` are

package/package.json

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

@@ -111,7 +111,11 @@ task binding and no user account.
 1. Resolve the card from the argument — slug, id, or URL. **None given → ask
    which card.** Never infer one from the branch you happen to be on.
 2. `mcp__conveyor__get_task` for the full plan and
-   `mcp__conveyor__read_task_chat` for addenda and user answers. Consult
+   `mcp__conveyor__read_task_chat` for addenda and user answers. On a pack
+   child the source documents usually sit on the parent card:
+   `mcp__conveyor__list_task_files` with `task_id` set to the parent (in a pod;
+   the local surface spells it `taskId`) lists them, and
+   `mcp__conveyor__get_attachment` with the same `task_id` reads one. Consult
    `mcp__conveyor__get_tag` on the card's tags before diving in — a tag's
    overview and linked files are the fast path into the subsystem.
 3. Route on the card's shape:
@@ -202,6 +206,15 @@ capture a screenshot (static) or a short recording (interaction) with the host
 repo's own tooling and attach it with `mcp__conveyor__upload_attachment`, then
 embed the returned URL in the PR body. A UI PR without it is incomplete.
 
+**Manual tests are for human eyes, and few.** Before the PR, record with
+`mcp__conveyor__set_manual_tests` only what a person must see in the running
+app to sign the card off: at most 5, usually 1, none for a change with no
+user-visible behavior. One sentence each, in plain language: where to go, what
+to do, what they should see ("Open any card with a PR: the Pull Request slat
+sits directly under Description"). Never record gates, commands, CI, logs, or
+database steps; the server rejects them. A rejected item is a signal to drop
+it, not to rephrase it.
+
 **On a deep pack the gate surface grows, and that is expected.**
 `test:affected` diffs against `origin/dev`, so by the fourth child it also
 covers the three already merged into the pack branch. That is correct
@@ -249,7 +262,10 @@ Instead: post the answer, config, or findings with
 `mcp__conveyor__upload_attachment` (any file type, up to 25MB), and complete
 the card directly with `force_update_task_status("Complete")` — there is no PR
 or review step for a no-code task. Never publish a deliverable as an off-card
-link; the card is where it belongs.
+link; the card is where it belongs. When a revision supersedes an earlier
+upload, remove the old copy with `mcp__conveyor__delete_attachment` (permanent,
+`fileId` from `list_task_files`) so the Files list shows one current version
+of each deliverable.
 
 When unsure, check the diff: a real diff means open a PR, no diff means finish
 in chat and mark it Complete.
@@ -269,17 +285,7 @@ nothing invalidates the verification you just did:
    recorded on the card. That fallback is usually right and is exactly why the
    mistake is invisible — until the card's recorded branch has drifted, and the
    PR opens against `dev`.
-4. **Publish the PR guide** with `mcp__conveyor__publish_review_guide`, right
-   after `create_pull_request` succeeds — it is part of opening a PR, not a
-   follow-up. `sections` is a top-level array argument, not prose stuffed into
-   `overview`; keep `overview` a short intro and order the sections with core
-   behavior first, tests and generated files later. Reference only files this
-   diff actually changed, never context you merely read. Anchors are optional
-   and strict — `{"path": "..."}` alone is the safe form. Republish for the new
-   head SHA after any later push, or the card's Guide tab shows stale. It is
-   best-effort: if it still fails after one corrected retry, carry on — it
-   never blocks opening or updating the PR.
-5. Post a chat summary: what shipped, how it was verified, what a reviewer
+4. Post a chat summary: what shipped, how it was verified, what a reviewer
    should look at, and anything you did NOT do.
 
 Then confirm CI actually started (read-only `gh pr checks`). Do not wait on it.

package/skills/conveyor-consensus/SKILL.md

@@ -21,7 +21,7 @@ The genre: **an uninterested observer pulls every relevant source, counts what a
 1. `get_connection_context` — who and where. Same call in a pod and a local MCP session; it reports the card in a pod and the account/board in an MCP client.
 2. `list_project_integrations` — which of repository, Slack/Discord, email, GCP, Grafana, Google Analytics, Drive, Cloudflare, incidents are configured, plus the registered work channels. Credential-free booleans; this is the map.
 3. `list_project_channels` — the channels an admin registered as agent-reachable, each with a description of what happens there. **The description is the routing signal**: it is how you tell the channel where support complaints land from the one where releases are announced. Only registered channels are reachable at all; an unregistered channel does not exist for this skill regardless of what the bot can see.
-4. **ToolSearch for the optional surfaces** rather than assuming them: `drive_*`, meeting tools, `query_gcp_logs` / `query_grafana_logs`, `get_analytics_summary`. Also probe for supplemental local MCPs the user may have connected — a user-token Slack MCP is the notable one, because it enables true keyword search that Conveyor's own tools cannot do (see the Slack search note below).
+4. **ToolSearch for the optional surfaces** rather than assuming them: `drive_*`, meeting tools, `query_gcp_logs` / `query_grafana_logs`, `get_analytics_summary`, `evaluate_questions` (in a pod the name must be fully qualified: `select:mcp__conveyor__evaluate_questions`). Also probe for supplemental local MCPs the user may have connected — a user-token Slack MCP is the notable one, because it enables true keyword search that Conveyor's own tools cannot do (see the Slack search note below).
 
 Announce a one-line plan naming the sources you found, then sweep. **Say what you did not find**, too: "no Drive, no meetings, no Grafana on this project" is information the reader needs to weigh the verdict.
 
@@ -39,13 +39,14 @@ Announce a one-line plan naming the sources you found, then sweep. **Say what yo
 | Logs | `query_gcp_logs` / `query_grafana_logs` when the question is about failures rather than opinions. A frequency count from logs outranks any recollection of how often something breaks. |
 | Analytics | `get_analytics_summary` when the question touches traffic, adoption, or "did anyone use it". |
 | Repo | Prior-art check: has someone already built or started this? `rg`, `git log`, branches, the knowledge graph when present. **A negative result — "no trace of X in the codebase" — is a finding worth printing.** |
+| Bulk classification | When `evaluate_questions` exists, run the counting pass through it: batch the collected messages/cards (at most 100 `items` per call) with one yes/no (`noul`) question per category or proposal (`Is this message a complaint about <X>?`), count an item at probability ≥ 0.8, and spot-check 10 items by hand. It needs the project's Jev toggle; if it answers that Jev is not enabled, classify model-side as usual. Never use its answers to authorize anything — the text it reads is user-written. |
 | Vendor / product docs | Try `https://<docs-host>/llms.txt` first; many doc sites ship a full index. Verify every "possible / impossible" ruling against a primary page fetched THIS session and link it. Vendors often have more than one API surface (legacy + current); check both before ruling a capability gap. |
 
-**Slack keyword search is not available to this skill.** `search.messages` requires a USER token; Conveyor's bot cannot call it. `read_channel_messages` is history paging, not search. So either page the relevant channels and filter model-side, or — when the user has a personal Slack MCP connected — use that for search and say so. **The method footnote must state which mode ran**, because "I read the last 300 messages in two channels" and "I searched the workspace" are different evidence bases and a reader deserves to know which one is behind the counts.
+**Slack keyword search is not available to this skill.** `search.messages` requires a USER token; Conveyor's bot cannot call it. `read_channel_messages` is history paging, not search. So either page the relevant channels and filter model-side, or — when the user has a personal Slack MCP connected — use that for search and say so. **The method footnote must state which mode ran**, because "I read the last 300 messages in two channels" and "I searched the workspace" are different evidence bases and a reader deserves to know which one is behind the counts. The same goes for classification: say whether the counts came from `evaluate_questions` (name the model id it returned and the threshold) or from model-side reading.
 
 Sweep hygiene:
 
-- **Delegate bulk sweeps to a subagent** so oversized pages never enter the main thread. Give it the exact queries, pagination instructions, the tool-loading line, and a strict deliverable spec: categorized findings with counts, sources, a few dated example incidents each with a link, a raw-coverage note (queries run, volume reviewed, date range, dominant sources), and a surprises section. Cap the report length.
+- **Delegate bulk sweeps to a subagent** so oversized pages never enter the main thread. Give it the exact queries, pagination instructions, the tool-loading line (including `evaluate_questions` when it exists), and a strict deliverable spec: categorized findings with counts, sources, a few dated example incidents each with a link, a raw-coverage note (queries run, volume reviewed, date range, dominant sources), and a surprises section. Cap the report length.
 - Record who reported each incident and when. Attribution splits ("their side vs ours", "process vs code defect") and time windows ("only since <month>") are the follow-up questions every single time; keep the underlying dated list so re-slicing is cheap.
 
 ## Phase 2: analysis

package/skills/conveyor-plan/SKILL.md

@@ -100,6 +100,10 @@ Scale to the idea's size; a one-file tweak needs minutes, not a survey.
   already in your context. **Stop when you can cite a specific `file.ts:line`
   and a symbol name for every step your plan will contain** — that is the
   threshold, and more reading past it buys nothing.
+- **Attachments**: `mcp__conveyor__list_task_files` on the card, and on its
+  parent when the card is a pack child (in a pod pass `task_id`; the local
+  surface takes `taskId`). Source documents, screenshots and worksheets usually
+  live there, and a plan written without reading them plans the wrong work.
 - **Prior art**: `mcp__conveyor__search_tasks` on 2-3 keyword variants
   (`typeFilters` to include incidents/suggestions when relevant), then
   `mcp__conveyor__get_task` on the closest hits. You're looking for duplicates

package/skills/conveyor-plan/references/plan-format.md

@@ -14,7 +14,8 @@ High-level strategy with relevant files/patterns/APIs.
 2. Concrete step.
 
 ## Testing
-- Commands and manual checks.
+- Gates: the scoped lint/typecheck/test commands.
+- Manual tests (0-3): one plain sentence each, user path only; omit when nothing is user-visible.
 - Edge cases.
 
 ## Notes
@@ -49,8 +50,11 @@ The executor treats it as the acceptance criteria, so enumerate:
   affected-test commands — naming the specific package suites the diff will
   touch. A docs-only plan should say plainly that no local gates are needed and
   that CI validates on the PR.
-- Any task-specific end-to-end check: a manual UI walk-through, an API smoke
-  test, a migration dry-run.
+- Manual tests, as a separate list of 0-3 items: one plain sentence each
+  naming where to go, what to do, and what a person should see. User paths
+  only; never a command, a gate, CI, or a log check. Omit the list when the
+  change has nothing user-visible. The builder copies the Manual tests list
+  into `set_manual_tests` and nothing else from this section.
 
 A planner working read-only is not expected to RUN these. Describe them.
 

package/skills/conveyor-prune/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: conveyor-prune
+description: Prune a Conveyor backlog in one confirm-then-apply pass — sweep every Planning and Open card, give each exactly one disposition (cancel stale, park on hold, merge overlapping cards into a pack, touch up the keepers), present the table, and apply only what a human confirms. Use when the user says "/conveyor-prune [project|all]", "prune my backlog", "clean up my open cards", "groom the board", or "what's stale on the board". Local/MCP surface only; inside a pod the skill says so instead of failing. Never mutates before the confirmation reply.
+---
+
+# Conveyor Prune
+
+The recurring "clean up my open backlog" ask, made repeatable. A board full of
+cards nobody has looked at in weeks is not a backlog, it is noise that hides
+the work that matters. This skill reads every unstarted card, decides what
+each one is, shows you the whole table once, and applies exactly the rows you
+confirm.
+
+## Goal and finish line
+
+**Goal:** every Planning and Open card in scope has exactly one recorded
+disposition — cancel, park, merge, or keep — with one line of evidence each.
+
+**Finish line:** the disposition table posted back with what was applied per
+row, and the "deliberately not touched" list.
+
+**A turn may end only when:** (a) the table is presented and you are waiting
+for the confirmation reply, or (b) the confirmed rows are applied and reported.
+Anything else — a half-swept project, a table with rows marked "TBD", a
+mutation applied before the reply — is a stalled run, not a paused one.
+
+> **Environment — this skill does not apply inside a pod.** The sweep needs
+> `list_projects`, `set_task_parent`, `create_task`, and `move_card`, and the
+> on-hold flag on `update_task` — all of which exist only on the external
+> `conveyor-mcp` surface, never on the in-pod agent surface. That is
+> deliberate: a pod acts on its own card, and parking or cancelling other
+> people's cards from inside a build is a human call. If
+> `mcp__conveyor__get_connection_context` reports a task binding and no user
+> account, you are in a pod: say so and stop. Do not hunt for an equivalent.
+
+## Ground rules
+
+- **All Conveyor tools fully-qualified** — `mcp__conveyor__list_tasks`, not
+  `list_tasks`. Bare names fail. Most of them are deferred; reach them via
+  ToolSearch (`select:mcp__conveyor__list_tasks,mcp__conveyor__update_task,…`)
+  rather than expecting them preloaded.
+- **Nothing mutates before the confirmation reply.** Not "I'll cancel the
+  obvious ones while you read". The table is the proposal; the reply is the
+  authority.
+- **One confirmation round per table**, never an item-by-item drip. The human
+  edits rows in one reply ("cancel 3 and 7, park the rest"); "apply all" is a
+  legitimate reply too.
+- **Exactly one disposition per card.** A card that is both "merge into pack
+  X" and "park" is a card you have not decided about.
+- **This skill never deletes a card**, never touches a card at InProgress or
+  beyond, and never starts a build.
+
+## 1 — Scope
+
+1. `mcp__conveyor__get_connection_context` — which project the connection
+   defaults to, and whether you are in a pod (see the banner above).
+2. Resolve the argument. No argument or a project name → that one project.
+   `all` → `mcp__conveyor__list_projects`, then run steps 1–5 per project.
+   The connection's default project may not be the one you mean, so **pass
+   `projectId` explicitly on every call** — a sweep that silently lands on the
+   default project prunes the wrong board.
+3. The sweep, per project:
+   - `mcp__conveyor__list_tasks { status: "Planning", onHold: false, limit: 200 }`
+   - `mcp__conveyor__list_tasks { status: "Open", onHold: false, limit: 200 }`
+
+   `limit` is load-bearing: the default is 50 rows, and a sweep that stops at
+   50 reports a clean board it never finished reading. `onHold: false` is
+   load-bearing too: a card already parked has a disposition; re-triaging it
+   every pass is how "on hold" stops meaning anything. Tasks only unless the
+   user asked for incidents or suggestions (`typeFilters`).
+4. Skip, and list under "deliberately not touched":
+   - rows with `parentTaskId` set — prune the pack parent; its children follow
+     the parent's disposition;
+   - rows with a non-null `codespaceStatus` — something is running on it;
+   - rows with a `githubPRUrl` — work exists; that is a review question, not
+     a prune question.
+5. `mcp__conveyor__list_tags` once — the project's vocabulary, and whether a
+   `duplicate` tag exists (step 3 uses it, and never creates it).
+
+## 2 — Evidence per card, cheapest first
+
+Stop at the first source that settles the disposition; do not read the
+transcript when the title already answers.
+
+1. `mcp__conveyor__get_task` — plan, description, age, the chat tail. A card
+   with no plan and no chat in weeks reads very differently from one with a
+   plan somebody revised last Tuesday.
+2. `mcp__conveyor__search_tasks` — **two or three keyword variants** per
+   card, across ALL statuses (`statusFilters` unset). The point is to find the
+   Complete or ReviewX card that already ships this. One search misses the card
+   that used the other word for it.
+3. `mcp__conveyor__read_task_chat` — only when the overlap lives in the
+   discussion rather than the title, or when a card's chat might record a
+   decision to drop it.
+
+Cluster merge candidates as you go: cards sharing two or more tags, or whose
+plans cite the same files, are usually one unit of work wearing several
+titles.
+
+## 3 — Dispositions
+
+Exactly one per card. The test is the decision; the mechanics are what you
+will run in step 5, written into the table so the human confirms the actual
+mutation, not a summary of it.
+
+| Disposition | Test | Mechanics |
+| --- | --- | --- |
+| **Cancel** | The need is gone, or a Complete/ReviewX card already ships the MVP of it | `mcp__conveyor__post_to_chat` first (the reason, and the owning card's slug when one exists), then `mcp__conveyor__update_task { status: "Cancelled" }`. Add the project's `duplicate` tag via `addTags` when `list_tags` showed one; never create it |
+| **Park on hold** | Still worth doing, not now — there is nothing wrong with it except priority | `mcp__conveyor__update_task { onHold: true }` plus a one-line `post_to_chat` note saying what would make it worth picking up. No tag: the on-hold boolean IS the state, the board reads it, and `list_tasks { onHold: true }` finds it later |
+| **Merge** | Two or more cards share a theme or the same files and would be built as one unit | Prefer **adoption**: `mcp__conveyor__create_task` the parent in Planning with a description naming why these belong together, then `mcp__conveyor__set_task_parent` each existing card under it — that keeps every card's chat, history, and plan. Cancel-and-supersede only when the originals would not stand as independent children. Never `start_task` |
+| **Keep** | Needle-moving and still accurate | Touch up the title or description with `mcp__conveyor__update_task` when they have drifted. If the plan is thin or missing, mark the row **needs `/conveyor-plan`** — this skill does not write plans |
+
+A card whose card type or age alone would decide it is a card you have not
+looked at. Age is evidence for "nobody wanted this"; it is not a disposition.
+
+## 4 — Present and wait
+
+One table for the whole scope (one per project under `all`), numbered rows:
+
+| # | Card | Status | Age | Disposition | Evidence | Mutation |
+| --- | --- | --- | --- | --- | --- | --- |
+
+- **Evidence** is one line and names its source — "`ship-the-thing` is
+  Complete and covers this", "no plan, no chat since 2026-07-02", "same three
+  files as row 4". A row whose evidence you cannot name is a row you inferred;
+  label it as a guess or drop it to Keep.
+- **Mutation** is the exact call you will make, so what gets confirmed is what
+  runs.
+- Below the table, the **deliberately not touched** list from step 1.4, with
+  the reason per card, and any **contradictions** you found (two Open cards
+  arguing opposite directions, a card whose chat says "dropped" but whose
+  status says Open).
+
+Then wait. That is the end of the turn. Do not apply the "obvious" rows early,
+do not ask a second question, do not re-sweep. If the reply edits rows
+("cancel 3 and 7, park the rest"), the edited table is what applies; if it is
+"apply all", the table applies as presented; if it is partial ("just 1 and
+4"), apply exactly those.
+
+## 5 — Apply and report
+
+Confirmed rows only, in this order: **cancel → merge → park → keep**. The
+order matters: a card that gets merged under a new parent is never also
+parked, and a cancelled card is never touched up.
+
+- Run each row's mutation as written in the table, through the ordinary card
+  tools. There is no prune-specific write path, on purpose: a card pruned by
+  this skill is indistinguishable from one a person pruned by hand.
+- Report per row: applied, or the exact error. **On a tool error, stop and
+  report the row rather than retrying it** — a retry storm on a card that
+  refuses a transition is worse than one honest "row 6 failed: <error>".
+- Finish by posting the applied table back — what changed, what did not, and
+  the rows the human struck.
+
+## What this skill is not
+
+- **Not a planner.** A keeper with a thin plan gets flagged for
+  `/conveyor-plan`; this skill never writes a plan.
+- **Not a starter.** It never calls `start_task`; a pruned board is a decision
+  about what exists, not about what runs next.
+- **Not a deleter.** Cancel is the strongest disposition. A cancelled card
+  keeps its chat and history; a deleted one is gone.
+- **Not a review.** InProgress, ReviewPR, ReviewDev, and ReviewLive cards are
+  out of scope, and so is any card with a PR or live compute.
+
+## Environment notes
+
+- All Conveyor tools are **fully qualified** and mostly **deferred** — one
+  ToolSearch `select:` with every name you expect to need, up front.
+- The connection's default project may not be the one you mean; pass
+  `projectId` per project, on every call, especially under `all`.
+- `list_tasks` defaults to 50 rows and `search_tasks` to 20 — pass `limit`.
+- The on-hold flag is a database boolean the board hides on, not a tag.
+  `update_task { onHold: true }` on an InProgress-or-beyond card demotes it to
+  Open as it parks — one more reason those cards are out of scope here.
+
+## 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-triage/SKILL.md

@@ -80,7 +80,9 @@ Find the code path the report implicates and, where you can, reproduce it. A
 diagnosis grounded only in reading is a hypothesis; a reproduction makes it a
 finding. Attach evidence to the card with `mcp__conveyor__upload_attachment` —
 a screenshot, a log excerpt, a short recording — so the Builder inherits proof
-rather than your assertion.
+rather than your assertion. A re-captured version replaces the old one:
+`mcp__conveyor__delete_attachment` (permanent, `fileId` from
+`list_task_files`) keeps the card's Files list to what is current.
 
 ## 5. Decide
 

package/skills/conveyor-workflows/SKILL.md

@@ -90,8 +90,10 @@ labels. Each tag carries a `description` (≤255 — the summary), an `overview`
 (where the code/rules live), and parent/child tags (a sub-type taxonomy).
 
 - **Read**: `mcp__conveyor__list_tags` for the inventory (names, descriptions,
-  hierarchy, `contextPaths`, `hasOverview`) — the context links ship inline, so
-  auditing what the glossary wires up takes one call, not one per tag;
+  hierarchy, `hasOverview`, `contextPathCount`) — a compact summary by default,
+  so the whole glossary fits one tool result. Pass `detail: "full"` to ship the
+  context links inline, so auditing what the glossary wires up takes one call,
+  not one per tag;
   `mcp__conveyor__get_tag` (id or exact name) for one term's full entry —
   overview, linked files, hierarchy, and recent revisions with their reasons. When a card or chat message deep-links a term
   (`@[tag:<id>]` — the web composer offers this when you type a tag name),
@@ -131,6 +133,7 @@ labels. Each tag carries a `description` (≤255 — the summary), an `overview`
   | Do the work here | `conveyor-build` → follows the plan to a PR |
   | Judge the work | `conveyor-review` → one verdict, with risk |
   | Work a whole queue locally | `conveyor-local-loop` → selection and pacing over the above |
+  | Keep the board honest | `conveyor-prune` → one disposition per open card, applied only after confirmation (local surface only — it needs `set_task_parent`, `create_task`, and the on-hold flag) |
 
   `conveyor-start` and `conveyor-build` are the same phase reached two ways —
   hand the card off, or do it in this checkout — so the choice is about where
@@ -180,9 +183,9 @@ sync-spawned duplicate.
   follows repo patterns — it advances the card through the review pipeline
   (and, per project settings, approves/merges the PR). Otherwise
   `mcp__conveyor__request_changes` with specific feedback, which returns the
-  card to the builder. Manual test checklists ride
-  `mcp__conveyor__set_manual_tests` and surface for human sign-off at the
-  review stage.
+  card to the builder. Manual tests (`mcp__conveyor__set_manual_tests`, at
+  most 5 per card, user paths in plain language) surface for human sign-off
+  at the review stage.
 - Don't approve or merge your own PRs unless the project's policy explicitly
   allows it.
 - Remote workspace access (SSH/preview) goes through