@rallycry/conveyor-agent 11.0.27 → 11.0.28

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-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