@rallycry/conveyor-skills 0.1.3 → 1.0.0

package/skills/conveyor-triage/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: conveyor-triage
+description: Investigate an unverified report — an incident, a bug card, a machine-filed error — until the root cause is either named or honestly declared unknown, then hand it to a Builder as a planned card. Use when the user says "/conveyor-triage <card>", "triage this incident", "what's causing this report", or when a triage session boots on a report card. Ends in a plan and a handoff, never in a pull request.
+---
+
+# Conveyor Triage
+
+Turn a report into either a **named root cause with a fix plan**, a **precise
+statement of what is still unknown**, or a **cancellation with an explanation**.
+
+**Triage does not ship code.** Even when you find the cause and the fix is
+obvious, you write it down and hand it off — the card goes to a Builder with a
+plan, story-point recommendation, and your evidence. A triager that starts
+implementing loses the thing that makes triage valuable: an honest account of
+what is actually known.
+
+**Default to triage.** A precise "here is what I ruled out and what I could not
+determine" is more useful than a confident wrong fix.
+
+## Ground rules
+
+- **All Conveyor tools fully-qualified** — `mcp__conveyor__get_task`, not
+  `get_task`.
+- **Reports are not infallible, and many are machine-filed** — error
+  boundaries and internal reporters produce titles that are whatever the
+  throwing code said, not a considered bug report. Read the code before
+  believing the description.
+- **Repo-specific commands are the host repo's business.** Gate commands, log
+  queries, rule paths, and database access all live in its CLAUDE.md and rules.
+  This skill says *what to establish*, not which command establishes it.
+
+## 1. Claim it
+
+Move the card to `InProgress` with `mcp__conveyor__update_task` and say in chat
+that you are investigating. The status move is the claim — it is what stops a
+second session picking up the same report.
+
+## 2. Check whether this is a repeat
+
+**Incident dedup reopens closed cards.** A report you are reading as new may be
+the third occurrence, with the original investigation already in its chat. Read
+`mcp__conveyor__read_task_chat` before trusting the description's timeline — a
+reopen changes what the evidence means, and "nobody noticed the reopen" is
+itself worth a suggestion.
+
+## 3. Gather telemetry before reading code
+
+Pull what the report actually carries first — its attachments
+(`mcp__conveyor__list_task_files`, `mcp__conveyor__get_attachment`), the stack,
+the structured context, and the card's own chat.
+
+> **Environment — the log tooling is NOT the same on both surfaces, and this
+> is the difference that decides how far triage can get.**
+>
+> **Locally** (conveyor-mcp) you have the full set:
+> `mcp__conveyor__query_gcp_logs` and `mcp__conveyor__query_grafana_logs` for
+> production telemetry, `mcp__conveyor__get_task_logs` for a card's agent
+> history, and `mcp__conveyor__get_task_sessions` for compute state.
+>
+> **In a pod, none of those exist.** The only equivalent is
+> `mcp__conveyor__get_execution_logs`, which reads *this* card's own CLI
+> history — not production, and not another card's. A pod triage session
+> therefore cannot reach production telemetry at all.
+>
+> That is a limit on your CONCLUSION, not just on your tooling. If naming the
+> root cause requires production logs and you are in a pod, the honest outcome
+> is a triage handoff that says exactly which query would settle it — not a
+> guess dressed as a finding.
+
+Note which environment the report came from before querying; asking the wrong
+one produces confident nonsense.
+
+**Write down what the report does NOT contain.** Missing route, missing user,
+missing build revision, missing screenshot — each gap is both a limit on your
+conclusion and a suggestion to file in step 7.
+
+## 4. Locate and reproduce
+
+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.
+
+## 5. Decide
+
+### Hand off for a fix — only if ALL of these hold
+
+- You can name the root cause **in code** — not "something in permissions", not
+  "probably a race".
+- The fix is self-contained: no unverifiable migration, no multi-service
+  redesign.
+- You are confident it will not regress adjacent behavior, checked against the
+  domain's rules.
+- **That confidence is grounded in telemetry or a reproduction, not in code
+  reading alone.** If neither backs the diagnosis, triage instead.
+
+### Triage — if ANY of these hold
+
+- The description is vague: no specific element, action, or expected-vs-actual.
+- No clear cause after a genuine investigation.
+- Intermittent, and telemetry does not explain it.
+- Needs a repro environment, design input, production-data access, or infra
+  changes you cannot make safely.
+
+### Cancel — if ANY of these hold
+
+- The code behaves as designed and the reporter's expectation was wrong.
+- The "bug" describes functionality that does not exist yet — that is a feature
+  request; file it with `mcp__conveyor__create_suggestion`.
+- The reporter appears confused about how the feature works.
+
+Post a clear, non-dismissive explanation **before** cancelling. A cancellation
+with no explanation reads as dismissal and the report will come back.
+
+### Before you call it "already fixed" or "stale pre-fix data" — verify both halves
+
+This verdict needs two facts, each **checked**, never assumed:
+
+1. **Was the fix actually deployed in the code the report ran against?**
+   Establish which environment and which branch, then check whether the fix
+   commit is an ancestor of what was running, and compare its merge time
+   against the card's creation **and any reopen timestamps**.
+2. **Does the data predate the fix?** Look up the subject entity's age; the
+   report does not carry it.
+
+The self-contradiction that signals a bad diagnosis: *"the fix is deployed"*
+and *"the data predates the fix"* cannot both be true for an entity created
+after the deploy. A report filed today, on an environment carrying the fix for
+days, about an entity created today, is a **live bug** — reproduce it on
+current code rather than writing it off. And never inherit a previous
+investigation's "this predates the fix" conclusion without re-running check 1.
+
+## 6. Write the outcome onto the card
+
+**Handing off for a fix:** save a plan with `mcp__conveyor__update_task` that
+names the root cause with `file.ts:line` citations, states the fix and the
+files it touches, lists the verification a Builder should run, and recommends
+story points and risk. Then move the card to `Open` so a Builder can claim it.
+Do **not** cut a branch, and do **not** open a PR.
+
+**Triaging:** post what you established, what you ruled out, and precisely what
+is still unknown — including what evidence would resolve it. Then move it to
+`Open`. "Needs a repro with the console open" is an actionable handoff;
+"couldn't reproduce" is not.
+
+**Cancelling:** explain the actual behavior, then cancel.
+
+## 7. File at least one suggestion — always
+
+Every triage produces at least one `mcp__conveyor__create_suggestion`, in
+parallel with the outcome above. Investigation is the only time the gaps in
+your own reporting pipeline are visible; the moment passes.
+
+| What you observed | What to suggest |
+| --- | --- |
+| The report carried only a message and a stack | Enrich reports with route, user, and build revision |
+| No trace id, so it could not be correlated to server spans | Propagate trace context from client to server |
+| No console output captured | Capture browser console output in reports |
+| Visual bug with no screenshot | Add viewport capture to the report form |
+| A reopened dedup hit that nobody noticed | Surface reopen count and timestamps on the card |
+| A generic title that deduped wrongly | Tune the report fingerprint for that source |
+| No expected-vs-actual in the description | Add structured expected/actual fields to the form |
+| You read five or more files to understand a domain with no rule doc | Add a rule doc for that domain |
+| A test would have caught this | Add coverage for that path — found by report, not CI |
+
+Use `mcp__conveyor__list_tags` to pick real tag names; unknown names come back
+in the result rather than failing the call.
+
+## 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

@@ -52,11 +52,13 @@ and let Conveyor's own automation do the linking.
   repo-relative files and symbols, runnable testing commands, decisions
   already made recorded in Notes. Format and sizing:
   [../conveyor-plan/references/plan-format.md](../conveyor-plan/references/plan-format.md).
-  For research-backed planning that ends in a handoff card, use the
-  `conveyor-plan` skill.
+  For research-backed planning, use the `conveyor-plan` skill — it is the first
+  half of the pair below.
 - **One card per deliverable/PR** (mirror packs below are the documented
   exception). Multi-PR work becomes a pack: children via
-  `mcp__conveyor__create_subtask` (the ONLY way to parent a card) with
+  `mcp__conveyor__create_subtask` (new children) or
+  `mcp__conveyor__set_task_parent` (adopt an existing card into the pack, or
+  detach one with `parentTaskId: null`), with
   `mcp__conveyor__add_dependency` edges. Orchestration packs run children as
   their own builds/PRs; mirror packs (children created with
   `followParentStatus: true` on `create_subtask`) document already-done work
@@ -102,13 +104,37 @@ labels. Each tag carries a `description` (≤255 — the summary), an `overview`
   `status: "InProgress"` plus a chat note saying who/where is working it.
   Never hand-move a card to `ReviewPR` or set its PR link — that transition
   belongs to `create_pull_request` / the PR sync.
+- **One skill per lifecycle phase, and they mean the same thing everywhere.** A
+  cloud pod running a card and a local session working one read the SAME skill
+  text; the handful of genuine environment differences (WIP autosync, whether
+  `create_pull_request` pushes for you, which verdict tools exist, shared vs
+  dedicated dev stack) are called out inline.
+
+  | Phase | Skill |
+  | --- | --- |
+  | Investigate an unverified report | `conveyor-triage` → hands off a planned card, never a PR |
+  | Plan the work | `conveyor-plan` → writes an executable plan onto the card |
+  | Hand it to the cloud | `conveyor-start` → starts a pod and confirms it came up (local surface only — `start_task` does not exist in a pod) |
+  | 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 |
+
+  `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
+  the work runs, not about what happens to the card. `conveyor-build` routes a
+  childless card to its task path and a feature-branch pack to its pack path on
+  its own; you do not pick. And an
+  incident goes to `conveyor-triage` before `conveyor-plan` — planning a fix
+  from a symptom is how the wrong thing gets built confidently.
 - **Cloud or local**: `mcp__conveyor__start_task` boots a cloud agent
   environment for an Open card (that agent run is the card's "build" —
-  `mcp__conveyor__get_build_status` reports it). To execute cards on the
-  local machine instead, use the `conveyor-local-loop` skill. Don't do both —
-  a started task's agent will duplicate local work. That loop idles on
-  `conveyor-wait`, a CLI in `@rallycry/conveyor-mcp` that blocks until a card
-  becomes claimable, so an idle loop wakes on a board event instead of a timer.
+  `mcp__conveyor__get_build_status` reports it), and that agent runs
+  `conveyor-build` itself. To execute cards on the local machine instead, use
+  `conveyor-build` directly for one card, or `conveyor-local-loop` to work a
+  whole queue. Don't do both — a started task's agent will duplicate local
+  work. The loop idles on `conveyor-wait`, a CLI in `@rallycry/conveyor-mcp`
+  that blocks until a card becomes claimable, so an idle loop wakes on a board
+  event instead of a timer.
 - **Reserved-branch trap**: a card with an assigned agent may have a reserved
   `githubBranch`. Check `get_task` before pushing: if set, push to THAT
   branch; a PR from any other branch gets auto-closed and unlinked.

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

@@ -1,223 +0,0 @@
----
-name: conveyor-local-pack
-description: Drive one Conveyor pack (parent card + children) on this machine start to finish — this session is BOTH the pack coordinator and every child's implementer. Work children serially in dependency order, PR each into the pack branch, review + merge locally, sync dev after every merge, then land the whole pack as one final parent PR into dev. The local alternative to pressing Build on a parent card. Use when the user says "/conveyor-local-pack <card>", "drive this pack locally", or "run the whole pack on my machine". One invocation = one step (next child, a merge, or the finale); run continuously with "/loop /conveyor-local-pack <card>" (no interval) and it self-paces until the final PR is green, then stops itself. For a single non-pack card use conveyor-local-task; to work the whole Open queue (packs included) use conveyor-local-loop.
----
-
-# Conveyor Local Pack
-
-The cloud pack runner's autonomous loop (`pack-runner-prompt.ts`), adapted to
-one machine. Two deliberate differences from the pod version:
-
-- **No coordination-only rule.** The cloud runner fires child pods and never
-  writes code; here the same session implements each child itself.
-- **No server-side base sync.** The server merges dev into the pack branch
-  before each cloud child launch; locally that sync is your job, after every
-  child merge.
-
-Everything else carries over: 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 assumes a feature-branch pack — children branch from and PR into the
-pack branch, and the pack lands on dev in ONE final PR. If the parent has no
-feature branch (children PR straight into dev), this skill does not apply:
-run /conveyor-local-loop over the children instead.
-
-## Ground rules
-
-- **The parent card stays PARKED until the final PR.** Never
-  `mcp__conveyor__start_task` the parent and never set it InProgress: the pack
-  watchdog and child-event notifier ignore parked parents, but an ACTIVE
-  parent treats a headless InProgress child as a dead agent environment and
-  "recovers" it onto a cloud pod — duplicate implementation (observed
-  2026-07-28). The final `create_pull_request` is what moves the parent to
-  ReviewPR. Parent already InProgress/ReviewPR at setup → a coordinator is (or
-  was) active; report and stop rather than compete.
-- **Conveyor is the state store.** A pack spans days and the session gets
-  compacted; every iteration re-derives state from `mcp__conveyor__get_task` +
-  `mcp__conveyor__list_subtasks`, never from conversation memory.
-- **All Conveyor tools fully-qualified** (`mcp__conveyor__get_task`; bare
-  names fail).
-- **WIP = 1, strictly serial.** One child at a time, in dependency order. No
-  cloud offload: never `start_task` a child — a pod would duplicate the local
-  work. Want parallel fan-out? Press Build on the parent instead.
-- **You are the reviewer of record for child PRs** — the automated code
-  reviewer skips PRs that target the pack branch. Review each child diff for
-  real before merging; the independent review happens on the pack's final PR
-  into dev (automated reviewer + human).
-- **Never approve or merge the FINAL parent PR.** Finish line = parent in
-  ReviewPR with green CI; the user takes it from there.
-- **Child PRs into the pack branch get NO CI** (Conveyor runs CI on PRs to
-  dev/main only) — the local gate pass is the ONLY verification before a
-  child merges. Mandatory, never skippable. In a repo that does run CI on
-  pack-branch PRs, let it finish before merging.
-- **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, idle — the
-  resolution is the user committing or stashing, not a second checkout.
-- **Push early.** No pod WIP-autosync locally; committed-and-pushed is the
-  only durable state. Push child branches (`-u origin`) as soon as they
-  exist, and the pack branch after every merge/sync.
-
-## Setup (first iteration only)
-
-1. Resolve the parent card from the argument (slug/id/URL — required; without
-   one, ask which pack). `mcp__conveyor__get_task` +
-   `mcp__conveyor__read_task_chat`.
-2. Confirm it is a parked feature-branch pack: has (or will have) children,
-   status not InProgress/ReviewPR, no active agent session.
-3. Ensure the pack branch exists on origin: use the card's branch if set;
-   else cut `ft/<parent-slug>` from `origin/dev`, push `-u`, and IMMEDIATELY
-   record it on the card — `mcp__conveyor__update_task` with
-   `githubBranch: <branch>` (the branch must already be pushed; the API
-   verifies the ref exists). This write is load-bearing, not bookkeeping:
-   identification mints a competing `conveyor/*` branch onto any branchless
-   card it processes, and every pack-child merge handler keys on the card's
-   recorded branch matching the PRs' real base — a drifted record strands
-   externally-merged children in ReviewPR. Name the branch in the claim post
-   too.
-4. No children yet? Break the work down first, exactly as a fresh cloud
-   parent would: explore the codebase, save the parent-level plan on the card
-   (`mcp__conveyor__update_task`), then `mcp__conveyor__create_subtask` each
-   child with a detailed standalone plan (file:line citations, verification
-   steps) and `dependsOn` wherever one blocks on another.
-5. Post to parent chat: `[local-pack] claimed — driving this pack locally on
-   <hostname>, pack branch <branch>`.
-
-## Iteration order
-
-Each invocation re-reads the parent + `list_subtasks`, then does the FIRST
-that applies:
-
-1. **Recover** — a child with my `[local-pack] claimed` marker sitting
-   InProgress without a PR? Resume it. Its branch may exist locally or on
-   origin — audit what already landed before re-implementing anything.
-2. **Merge** — a child in ReviewPR: merge path below.
-3. **Promote** — a Planning child whose plan is solid:
-   `mcp__conveyor__update_subtask` → status Open (+ story points/agent if
-   unset). Genuinely not plannable → escalate to parent chat.
-4. **Implement** — the next Open child with all dependencies met (a
-   dependency counts as met at ReviewDev/Complete — i.e. merged into the
-   pack — or Cancelled; ReviewPR is NOT met). No `dependsOn` set anywhere →
-   ordinal order. Implement path below.
-5. **Finale** — every child ReviewDev/Complete: cross-reference + final PR,
-   below.
-6. **Babysit** — final PR open: red CI or review comments → address directly
-   on the pack branch (never claim or work children once the parent is in
-   ReviewPR); green and quiet → post the wrap-up to parent chat and STOP the
-   loop.
-
-## Implement a child
-
-1. `mcp__conveyor__get_task` on the child — reload the full plan fresh every
-   time — + `read_task_chat` for addenda. Plan too thin for a context-free
-   reader → post what's missing to parent chat, skip it, take the next ready
-   child.
-2. Claim: `mcp__conveyor__update_task` → InProgress, then chat marker
-   `[local-pack] claimed — working locally on <hostname>`.
-3. Branch from the PACK branch, never dev: `git fetch origin <pack> && git
-   checkout -B <feat|fix|chore>/<child-slug> origin/<pack>`. If the child
-   already has a branch with commits on origin, resume THAT branch — audit it
-   first. Reinstall deps if the lockfile changed.
-4. Work the plan. Chat updates at real milestones only, not play-by-play.
-5. Verify per the host CLAUDE.md (scoped gates: `bun run check` +
-   `bun run test:affected`). Note `test:affected` diffs vs origin/dev, so on
-   a deep pack it naturally also covers previously merged children — that is
-   fine, not a bug to fix. UI-visible change → capture evidence and
-   `mcp__conveyor__upload_attachment` before the PR.
-6. Refresh vs the pack branch (`git fetch origin <pack> && git merge
-   origin/<pack> --no-edit && git push`), then
-   `mcp__conveyor__create_pull_request` with `head:` the child branch and —
-   ALWAYS EXPLICITLY — `base:` the pack branch. The default base is dev;
-   omitting `base` opens the child against the wrong branch. Post a summary
-   to the child's chat.
-
-## Merge a child (ReviewPR)
-
-1. Reviewer-of-record pass: re-read the child's plan, then the FULL diff
-   (`git fetch origin <pack> <child> && git diff
-   origin/<pack>...origin/<child>`) with reviewer eyes — plan coverage,
-   stray files, pattern consistency, and that the gate pass actually
-   happened. Found a real problem → fix it on the child branch first (you are
-   also the implementer), re-gate, then continue.
-2. Merge: `mcp__conveyor__approve_and_merge_pr`. Known trap: the merge queue
-   can NEVER auto-merge a zero-check pack-branch PR — if the merge queues
-   without landing, merge locally instead (`git checkout <pack> && git pull
-   && git merge --no-ff <child-branch> && git push`; GitHub then marks the PR
-   merged). Either way CONFIRM the child advanced to ReviewDev
-   (`mcp__conveyor__get_task`; allow ~1 min for the merge webhook). Still
-   ReviewPR after a local-merge fallback is an escalation, not a shrug — it
-   means the parent card's `githubBranch` has drifted from the real pack
-   branch: fix the parent record (`mcp__conveyor__update_task` with
-   `githubBranch: <pack>`), advance the child by hand (`update_task` →
-   ReviewDev), and post the drift to parent chat.
-3. **Sync dev into the pack branch** — the local stand-in for the server-side
-   base sync: `git checkout <pack> && git pull && git fetch origin dev && git
-   merge origin/dev --no-edit && git push`. Merge, never rebase: the pack
-   branch is shared (open child PRs, WIP refs) and rewriting it breaks them.
-   Conflicts are yours to resolve properly — you wrote the code. If the merge
-   drags in unrelated changes or errors, dev may have been rewound
-   (revert/force-push): verify the previous sync point is still an ancestor
-   of `origin/dev` (`git merge-base --is-ancestor`), and if not, abort the
-   merge and escalate instead of chasing the noise.
-4. Report the merge to parent chat in one line. Next iteration begins the
-   next child.
-
-## Finale (all children ReviewDev/Complete)
-
-1. **Cross-reference:** for the parent plan and EVERY child plan, check the
-   pack branch's actual state against the plan's acceptance and verification
-   criteria — a real checklist pass, not a vibe. Small gap → fix directly on
-   the pack branch. Substantial gap → new child card with a plan
-   (`create_subtask`); the loop continues.
-2. Pre-PR protocol on the pack branch, per the host CLAUDE.md: sync
-   `origin/dev` FIRST, then ONE verification pass scoped to the pack's
-   cumulative diff vs dev (cross-package packs → full `bun run test`).
-3. `mcp__conveyor__create_pull_request` on the PARENT: `head:` pack branch,
-   `base:` dev. The parent moves to ReviewPR. Post the pack summary to parent
-   chat: what shipped per child, how it was verified, what reviewers should
-   look at.
-4. Confirm CI actually started (read-only `gh pr checks`); do NOT wait on it
-   — the babysit tier owns it from here.
-
-**Parked protocol** — after 2 genuinely different failed approaches on a
-child, or a decision only the user can make: post `[local-pack] parked:
-<reason + the specific question>` to the child AND the parent chat, set the
-child back to Open, restore the tree, and take the next child whose
-dependency chain doesn't run through the parked one. Everything remaining
-blocked → idle long; the user's chat reply is the un-park signal.
-
-## Pacing (dynamic /loop only)
-
-Under `/loop` with no interval, end EVERY iteration with exactly one
-`ScheduleWakeup` (prompt = the original /loop input verbatim, card argument
-included):
-
-| State | Delay | Reason should say |
-|-------|-------|-------------------|
-| A background gate is in flight — its completion notification is the real wake | 1200–1800s fallback | "fallback while <gate> runs" |
-| Any actionable work: a child to implement/merge/promote, finale pending, red CI or comments on the final PR | 60–90s | which child / which step is next |
-| Blocked on the user: parked children only, or a pack-level question posted | 1200–1800s | what it's waiting on |
-| 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 |
-| Final PR green and quiet, wrap-up posted | `stop: true` | pack done |
-
-Invoked bare (no /loop)? Run one iteration, report, and suggest
-`/loop /conveyor-local-pack <card>` — don't self-schedule.
-
-## What this is not
-
-- Not a cloud coordinator: never `start_task` and never fire pods, for the
-  parent or a child. Serial local execution is the point; for parallel
-  fan-out, press Build on the parent instead of using this skill.
-- Not the final reviewer: `approve_and_merge_pr` is for CHILD PRs into the
-  pack branch only — never the parent's PR into dev.
-- Not a pod: the dev DB and 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.
-
-## 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-local-task/SKILL.md

@@ -1,92 +0,0 @@
----
-name: conveyor-local-task
-description: Complete ONE linked Conveyor card on this machine, start to ReviewPR — claim it, execute its plan in the main workspace, gate, open the PR, report, done. Use when the user says "/conveyor-local-task <card>", "do this card locally", or "complete this task on my machine". One card only, no queue and no loop — for a whole pack use conveyor-local-pack; to work everything Open (packs included) use conveyor-local-loop.
----
-
-# Conveyor Local Task
-
-Execute one Conveyor card exactly as a claudespace agent would, using this
-machine instead of a pod: 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 claiming, routing, and local-machine hygiene. Finish line =
-card in ReviewPR with CI started; the user reviews and merges.
-
-## Ground rules
-
-- **All Conveyor tools fully-qualified** (`mcp__conveyor__get_task`; bare
-  names fail).
-- **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 a hard rule: dirty `git status` →
-  touch nothing and report — the resolution is the user committing or
-  stashing, not a second checkout.
-- **Never `mcp__conveyor__start_task`** — that boots a cloud pod and
-  duplicates the work you're about to do locally.
-- **Never approve or merge your own PR.** ReviewPR with green-or-running CI
-  is where you stop.
-- **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.
-- **Not a pod:** the dev DB and 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.
-
-## Resolve and route
-
-1. Resolve the card from the argument (slug, id, or URL; none given → ask
-   which card). `mcp__conveyor__get_task` for the full plan +
-   `mcp__conveyor__read_task_chat` for addenda and user answers. Consult
-   `mcp__conveyor__get_tag` on the card's tags before diving in — the
-   overview + linked files are the fast path into the subsystem.
-2. Route pack cards away:
-   - Card **has children** → it's a pack coordinator; point the user at
-     `/conveyor-local-pack` and stop. Children that PR straight into dev are
-     not a feature-branch pack — point at `/conveyor-local-loop` instead, or
-     run this skill on one child card.
-   - Card **has a `parentTaskId`** and the parent is InProgress or ReviewPR →
-     decline: an actively-orchestrating parent reads a headless InProgress
-     child as a dead agent environment and "recovers" it onto a cloud pod
-     (duplicate implementation). Parent parked → proceed; the child's base is
-     the parent's feature branch.
-3. Plan missing or failing the context-free-reader bar → don't wing it: post
-   what's missing to chat and stop. The card must stand alone.
-
-## Claim and execute
-
-1. Re-confirm via `mcp__conveyor__get_task` that the card is claimable (Open —
-   or whatever the user explicitly overrode — with no assignee or active
-   session), then `mcp__conveyor__update_task` → `status: "InProgress"` and
-   `mcp__conveyor__post_to_chat`: `[local-task] claimed — working locally on
-   <hostname>`.
-2. Branch from the card's base, never blindly dev: `base` = the card's
-   `baseBranch` (a pack child's base is the PARENT's feature branch). If the
-   card already has a `githubBranch` with commits on origin, resume THAT
-   branch — a prior pod may have landed real work; audit it before
-   re-implementing anything. Else `git fetch origin <base> && git checkout -B
-   <feat|fix|chore>/<slug> origin/<base>`. Reinstall deps if the lockfile
-   changed.
-3. Work the plan. Post chat updates at real milestones only (claim, blocking
-   discovery, gates green, PR) — not play-by-play.
-4. Verify per the host repo's CLAUDE.md policy (scoped gates). UI-visible
-   change → capture screenshot/recording evidence with the repo's tooling and
-   attach via `mcp__conveyor__upload_attachment` before opening the PR.
-5. Refresh against the base (`git fetch origin <base> && git merge
-   origin/<base> --no-edit && git push`), then
-   `mcp__conveyor__create_pull_request` with `head:` your branch and — always
-   explicitly — `base:` the card's base branch. The card moves to ReviewPR.
-   Post a chat summary: what shipped, how verified, what to look at.
-6. Confirm CI actually started (read-only `gh pr checks`); do NOT wait on it.
-   Report the card + PR state to the user — done. No pacing, no loop, no
-   babysitting: follow-up CI fixes are a fresh ask.
-
-**Blocked** — after 2 genuinely different failed approaches, or on a decision
-only the user can make: post to chat the reason + the specific question, set
-the card back to `"Open"`, restore the tree (`git checkout dev`), and report.
-
-## 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.