@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 | Investigate an unverified report to a named root cause, then hand off a planned card | | conveyor-plan | /conveyor-plan | Research an idea into a context-free, immediately-buildable plan on a Conveyor card | | conveyor-start | /conveyor-start | 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 | Execute a planned card to a PR — one task or a whole feature-branch pack | | conveyor-review | /conveyor-review | 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 | 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)

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

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 /.claude/skills/, pointing at the stable node_modules/@rallycry/conveyor-skills/skills/ 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:

Each command prints one JSON line. A claim goes stale when its holder's process is dead, when the same process started a new session, or when its heartbeat is older than two hours (CONVEYOR_CHECKOUT_CLAIM_TTL_SECONDS). conveyor-skills checkout release --force is the human override for a wedged claim. The full protocol lives in skills/conveyor-build/references/checkout-claim.md.

Versioning

Versions are cut automatically from git tags on the Conveyor repo's main branch (conveyor-skills-v); every shipped-source change publishes a patch release. Consume with a ^ range and bump like any other dependency.

Description from the npm listing.