القائمة
Use when adding, removing, renaming, or moving an MCP tool between profiles in apps/web-server/mcp/tools.ts, or when the MCP smoke test fails with a tool-count or unknown-tool mismatch.
التثبيت باستخدام 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_add-mcp-tool |
| description | Use when adding, removing, renaming, or moving an MCP tool between profiles in apps/web-server/mcp/tools.ts, or when the MCP smoke test fails with a tool-count or unknown-tool mismatch. |
A tool change touches a sync triangle: the profile arrays in tools.ts, the mirror
arrays in the smoke test, and (sometimes) the agent-facing instructions. The mirror
arrays are the #1 forgotten step. Background: docs/ARCHITECTURE.md → MCP Layer +
Keep-in-Sync Invariants.
apps/web-server/mcp/tools.ts. Reuse the REST
route via app.inject() — never duplicate orchestrator logic. Author-profile
tools call apps/web-server/src/features/config/logic/feature-authoring.ts directly.CanaryLabMcpToolName union (top of tools.ts).REPAIR_TOOLS, VERIFY_TOOLS,
AUTHOR_TOOLS, or FULL_ONLY_TOOLS (tools.ts:240–307). A tool may appear in
several workflow arrays if it genuinely belongs to several workflows
(e.g. list_features). FULL_TOOLS auto-dedupes the union — never edit it.
registerCanaryLabTools throws at registration if a tool is in no profile.apps/web-server/mcp/server.smoke.test.ts — the test
keeps its own copies of the profile arrays so SDK shape changes are caught.
Update every array you touched in step 3.confirm: z.literal(true) in the input schema
(pattern: abort_run, write_envset).nextSteps via healWaitNext so result-driven
agents block on wait_for_heal_task, and handle boot-only runs with
bootSessionValue/isActiveBootRun so they don't dead-wait.cl_sync-agent-surfaces before finishing.npx vitest run apps/web-server/mcp/server.smoke.test.ts, then the
full suite per cl_verify-changes.| Mistake | Consequence |
|---|---|
| Skipping the smoke-test mirror arrays | Smoke test fails with a tool-count mismatch — or silently passes with stale coverage if you also "fixed" the count |
Editing FULL_TOOLS directly | It's computed; the edit is dead code and the next reader is misled |
| Duplicating route logic inside the tool | Drifts from the REST behavior (admission, collision, envset apply all live in the route) |
| New result shape without updating instructions/skills | External agents invent their own loop — that's the bug INSTRUCTIONS_BY_PROFILE exists to prevent |