@rallycry/conveyor-skills weekly downloads statistics

@rallycry/conveyor-skills

Shared Claude Code skills for projects managed with Conveyor. Installing this package and linking it once gives every Claude Code session in your repo the Conveyor lifecycle verbs — /conveyor-plan → /conveyor-start → /conveyor-build → /conveyor-review — plus triage and the local loop. Updates arrive through normal dependency bumps: no git submodules, no manual syncing.

Skills

Skill	Invoke	What it does
conveyor-workflows	auto-triggers on Conveyor questions	The guide: connect/repair the MCP, create and classify cards, packs, builds, the two PR paths, review flows, reliability gotchas
conveyor-triage	/conveyor-triage <card>	Investigate an unverified report to a named root cause, then hand off a planned card
conveyor-plan	/conveyor-plan <idea>	Research an idea into a context-free, immediately-buildable plan on a Conveyor card
conveyor-start	/conveyor-start <card>	Hand a planned card to a cloud pod, confirm the environment came up, report where to watch it (local surface only)
conveyor-build	/conveyor-build <card>	Execute a planned card to a PR — one task or a whole feature-branch pack
conveyor-review	/conveyor-review <card>	Review the PR against its plan and render one verdict, with risk
conveyor-release-review	/conveyor-release-review [release]	Audit everything in a pending release, keep only findings backed by evidence that survive an adversarial pass, and file them by priority as a blocker pack and a suggestions pack (local surface only)
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 the same phase reached two ways — hand it off, or do it in this checkout. Each reads identically in a cloud pod and a local checkout; where the two environments genuinely differ — which verdict tools exist, which log tooling is reachable, whether create_pull_request pushes for you — the skill says so inline rather than assuming.

An incident goes through conveyor-triage before conveyor-plan: planning a fix from a reported symptom is how the wrong thing gets built confidently.

Install (once per repo)

bun add -d @rallycry/conveyor-skills     # or: pnpm add -D / npm i -D
bunx conveyor-skills link                # or: pnpm exec / npx conveyor-skills link

Then make it stick:

1. Add the link step to your root package.json prepare script so every install refreshes the links (new skills in a version bump appear automatically; prepare runs at the end of every bun install — nobody ever runs it by hand):

   { "scripts": { "prepare": "conveyor-skills link" } }
   

   If you already have a prepare script, chain it: "husky && conveyor-skills link".

2. Commit the symlinks it created in .claude/skills/. They point into node_modules, so on a fresh clone they are briefly broken — Claude Code silently ignores broken symlinks — and come alive as soon as the first install finishes. Committing them means CI agents and teammates get the skills with zero extra setup.

How updates flow

Skill content is read live from node_modules, so any dependency bump (bun update @rallycry/conveyor-skills, Renovate/Dependabot, a ^ range refresh) updates the skills with no further action. Re-linking is only needed when a version adds or removes a skill — which the prepare hook already covers.

What link does (and won't do)

conveyor-skills link writes one relative symlink per skill into <repo>/.claude/skills/, pointing at the stable node_modules/@rallycry/conveyor-skills/skills/<name> path. It is idempotent and safe:

• It only ever replaces or prunes symlinks it owns (target contains conveyor-skills/skills/).
• A real directory or a foreign symlink with the same name is left alone with a warning — your local skills always win.
• conveyor-skills link --check verifies the links without changing anything (exit 1 when out of date) — useful in CI.

Taking turns on one checkout

Local agent sessions that share one git checkout take turns on it. /conveyor-build, /conveyor-local-loop and local /conveyor-review fixes hold a checkout claim while they use the working tree; a second session that finds it held says so and waits instead of switching branches underneath the first. Cloud pods have their own checkout and skip this.

The claim is one file in the git dir (.git/conveyor-checkout-claim.json, or the per-worktree git dir), so it is never committed and never shows in git status. The skills drive it through the same bin:

conveyor-skills checkout acquire --card <slug> [--branch <b>]  # take / refresh
conveyor-skills checkout verify  --card <slug>                 # still mine? (heartbeat)
conveyor-skills checkout release --card <slug>                 # give it back
conveyor-skills checkout status                                # who holds it
conveyor-skills checkout wait --timeout 1740                   # block until free
```…