Menu
Use when publishing a new canary-lab version to npm — changelog, version bump, smoke test, publish, tag.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
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" |