菜单
Use after changing run-loop semantics — collision/queue choices, boot sessions, heal claims, signal/rerun rules, pass-count rules — or when auditing whether MCP instructions, tool results, and the shipped SKILL.md files still agree.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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).
基于 SOC 职业分类
| name | cl_sync-agent-surfaces |
| description | Use after changing run-loop semantics — collision/queue choices, boot sessions, heal claims, signal/rerun rules, pass-count rules — or when auditing whether MCP instructions, tool results, and the shipped SKILL.md files still agree. |
External agents learn the run loop from five surfaces that nothing keeps in sync automatically. A semantic change to one must land on all five, or skill-less clients and skill-carrying clients diverge. Background: docs/ARCHITECTURE.md → Keep-in-Sync Invariants.
| # | Surface | File |
|---|---|---|
| 1 | Profile instructions (INSTRUCTIONS_BY_PROFILE) | apps/web-server/mcp/server.ts |
| 2 | Tool-result steering (healWaitNext, bootSessionValue, collision/queued result shapes) | apps/web-server/mcp/tools.ts |
| 3 | Claude skill (full 14-step run loop + authoring) | agent-integrations/claude/skills/canary-lab/SKILL.md |
| 4 | Codex skill (identical to #3 except client_kind: "codex-cli"/"codex-desktop") | agent-integrations/codex/skills/canary-lab/SKILL.md |
| 5 | Plugin skill (deliberately condensed loop) | agent-integrations/plugin/canary-lab/skills/canary-lab/SKILL.md |
Condensation rule for #5: keep the run-loop steps, guardrails, and pass-count rules; drop authoring/export detail. Do not paste the full Claude skill in.
repo_collision_requires_choice → ask the user → re-call with
isolation: "worktree" or "queue"; never guess.queued: true + queueReason; wait_for_heal_task still blocks.type: "boot_session" / executionType: "boot" → no heal
claim, no waiting, abort_run (confirm) stops services.claimSuppressed: true for CLI clients.wait_for_heal_task; never poll get_run_snapshot/get_run.signal_run (with hypothesis + fixDescription),
never a fresh start_run.result.counts.statusLine / counts.passed; never total - failed;
tests absent from all lists are not run.start_run is the single start/resume/restart entrypoint; omit
run_ref/force_new to continue a healing run.grep -rn '<keyword>' apps/web-server/mcp/server.ts apps/web-server/mcp/tools.ts agent-integrations/
(useful keywords: repo_collision_requires_choice, boot_session, queued,
claimSuppressed, statusLine, wait_for_heal_task, isolation).client_kind values, for #5 apply the
condensation rule.npx vitest run apps/web-server/mcp and read the three SKILL.md diffs
side by side.| Mistake | Consequence |
|---|---|
| Updating instructions but not tool results (or vice versa) | Skill-less clients follow results, skill-carrying clients follow prose — they diverge |
| Copying the Claude skill verbatim into the plugin skill | Plugin skill balloons; the condensation was intentional |
| Forgetting the codex variant "because it's identical" | It's identical except client kinds — a verbatim copy breaks claim detection |