Menu
Use when publishing a new canary-lab version to npm — changelog, version bump, smoke test, publish, tag.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when creating or extending a Canary Lab feature by hand — "create a feature for X", "add test cases to <feature>", "capture the env files", "switch the feature's branch" — through the author MCP tools (create_feature, capture_feature_env_files, write_envset, start/update/apply_external_draft, get_feature_repo_status, checkout_feature_repo_branch). For docs/PRD/coverage use canary-lab-coverage; for full onboarding of a bare repo use canary-lab (flight).
Use when working the Canary Lab semantic coverage ledger — "what's actually tested?", "map coverage for <feature>", "refresh the PRD summary", "close the coverage gaps", "add this plan/spec to the feature docs" — through the coverage MCP tools (write/list/delete_feature_doc, start/submit_external_summary, start/submit_external_coverage, get_feature_coverage, clear_prd_summary). For writing new tests use canary-lab-author.
Use when exporting a Canary Lab run as an evaluation — "export the evaluation", "produce the report for run 7cvh", "give me the evaluation archive", "review what the run proved" — through the export MCP tools (start/submit_external_evaluation_export, get/list/download_evaluation_export). The run must be terminal (passed, failed, or aborted).
Use when making a Canary Lab feature concurrency-ready — "portify <feature>", "make the ports injectable", "why can't these run concurrently", "undo the portification" — through the portify MCP tools (start/submit_external_portify, get_portify, save_portify, cancel_portify, remove_portification, list_portify_status).
Use when running or healing an EXISTING Canary Lab feature locally — "run <feature>", "fix the failing run", "rerun 7cvh", "drive the heal loop" — through the repair MCP tools (start_run, wait_for_heal_task, signal_run, get_heal_context, pause_run, cancel_heal, abort_run). Fix failing runs by editing app/service code, not tests. For end-to-end onboarding of a new repo use canary-lab (flight); for deployed-environment checks use canary-lab-verify.
Use when the user wants Canary Lab to take a product repo end to end — "test this app", "onboard this repo", "run a flight", "evaluate what I just built" — through the flight pipeline (start_flight / get_flight / respond_flight_checkpoint over MCP). One conducted background pipeline goes from bare repo(s) to a green, covered, healed run ending in an evaluation export. For a single capability use the focused skills instead — canary-lab-run (run + heal), canary-lab-verify (deployed-env verification), canary-lab-author (create feature + specs), canary-lab-coverage (PRD summary + coverage ledger), canary-lab-portify (concurrency-readiness), canary-lab-export (evaluation export).
| name | cl_release |
| description | Use when publishing a new canary-lab version to npm — changelog, version bump, smoke test, publish, tag. |
| disable-model-invocation | true |
User-invoked only (/cl_release). Publishing is outward-facing — confirm the version
and changelog with the user before publish:package.
npm run changelog:preview (dry run), then npm run changelog.
Entries are plain-language and area-tagged using the area tags defined in the
docs/CHANGELOG.md header (that header is the source of truth — don't rely on
a memorized list).
If consumers should refresh their workspace (template/sample changes, MCP
re-registration), say so in the release's header line
(e.g. "Run npx canary-lab upgrade …" / "run npx canary-lab setup").version in package.json (the changelog and tag tools read
it).npx vitest run, npx tsc -p tsconfig.build.json --noEmit, then
npm run smoke:pack (builds, packs, scaffolds a temp project, verifies the
scaffold flow).npm run publish:package — refuses a dirty worktree
(--allow-dirty is the escape hatch; prefer committing instead).npm run tag (tag:force only to move a botched tag).| Mistake | Consequence |
|---|---|
Publishing without smoke:pack | A broken scaffold/tarball ships; prepack builds but doesn't verify the scaffold flow |
| Changelog entries in engineer-speak | The changelog promises plain language anyone can follow |
| Forgetting the upgrade/setup note | Consumers keep stale samples or unregistered MCP tools and report "bugs" |