菜单
Use before claiming any canary-lab change works, when deciding which checks a change needs, or when tests/coverage behave strangely (coverage .tmp ENOENT, template edits not showing up, UI server running stale code).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 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_verify-changes |
| description | Use before claiming any canary-lab change works, when deciding which checks a change needs, or when tests/coverage behave strangely (coverage .tmp ENOENT, template edits not showing up, UI server running stale code). |
Pick the lowest tier that actually exercises the change, then run every tier at or below it. "Tests pass" at the wrong tier proves nothing — template and server changes have failure modes unit tests can't see.
npx vitest run
npx tsc -p tsconfig.build.json --noEmit
*.test.ts; component tests use happy-dom./* v8 ignore */ pragmas — write a real test or use a config-level
exclude.npm run test:coverage) has a known race: intermittent ENOENT on
coverage/.tmp. Recover with rm -rf coverage && npx vitest run --coverage --no-file-parallelism.Changes under templates/, tools/*.mjs, or package.json exports only reach
consumers through the build (templates/project/ → dist/templates/). Run:
npm run smoke:pack
apps/web-server/** or apps/web/**Source edits only take effect in a real workspace after the rebuild + reinstall +
server-restart cycle (canary-apply).
HARD RULE: never run the canary-apply cycle yourself — the user runs it. Stop and
ask the user to run canary-apply and restart the UI. After they confirm, verify the
server picked up the change: read the port from
~/Documents/canary-lab-workspace/canary-lab.config.json (default 7421) and hit
GET /mcp/health, then exercise the changed surface.
Changes to the external run loop (claim, wait, signal, collision, boot sessions) need
an end-to-end pass: drive the MCP loop against the broken_todo_api sample
(start_run with claim_heal → wait_for_heal_task → fix → signal_run → wait).
The old tools/verify-external-heal.sh REST smoke was removed — the MCP loop is the
current path.
| Change touches | Run tiers |
|---|---|
shared/, apps/web-server/src/features/** logic | 1 |
templates/, tools/, packaging | 1 + 2 |
apps/web-server/** / apps/web/** needing live proof | 1 (+2 if templates) + 3 |
| MCP run-loop semantics | 1 + 3 + 4, plus cl_sync-agent-surfaces |
| Mistake | Reality |
|---|---|
Running canary-apply / killing the workspace server yourself | The user controls that cycle — always hand off |
| Verifying a template edit with unit tests only | Consumers get dist/templates/; only smoke:pack proves the copy |
| Adding v8 ignore pragmas to make coverage pass | Forbidden in this repo; write the test |
| Retrying flaky coverage as-is | Known .tmp race — use --no-file-parallelism |