[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XCS7FVEG9RRW1FN6TRD6FK":3,"skill-same:01M6XCS7FVEG9RRW1FN6TRD6FK":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6XCS7FVEG9RRW1FN6TRD6FK","canary-lab-verify",null,"Use when verifying a Canary Lab feature against a RUNNING target — a deployed environment (\"verify checkout on staging\", \"run the saved verify config\", \"check the deployed app\") or a locally booted app (\"verify a running app\") — through the verify MCP tools (list\u002Fget\u002Fcreate\u002Fupdate_verification_config, boot_services, execute_verification, get_verification_result). No heal loop. For run + heal use canary-lab-run; for end-to-end onboarding use canary-lab (flight).","ferterahadi\u002Fcanary-lab","ferterahadi","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F148174839?v=4","01M6XCHCY39C7QEF3JZJ3VZGNZ","Fer Terahadi","01M6XCHD1ZE9926NBC97ZMZZRY",4,"MIT","https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fagent-integrations\u002Fclaude\u002Fskills\u002Fcanary-lab-verify\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"canary lab verify","lab","canary","verify","list","running","when","result","checkout","app","end","get","MCP","loop","Tools","verification","update","run","create","config","2026-11-10 10:12:30",false,"---\nname: canary-lab-verify\ndescription: Use when verifying a Canary Lab feature against a RUNNING target — a deployed environment (\"verify checkout on staging\", \"run the saved verify config\", \"check the deployed app\") or a locally booted app (\"verify a running app\") — through the verify MCP tools (list\u002Fget\u002Fcreate\u002Fupdate_verification_config, boot_services, execute_verification, get_verification_result). No heal loop. For run + heal use canary-lab-run; for end-to-end onboarding use canary-lab (flight).\ntype: skill\n---\n\n# Canary Lab — Environment Verification\n\n## User input through MCP 2.0\n\nUse the native Canary connector in the requesting chat so SDK 2.0 elicitation\n(`input_required`) reaches the human there. Do not substitute a shell MCP client,\nanswer a form yourself, or recreate the question in chat. Existing explicit\ninstructions and autopilot choices still apply without another ask.\n\nForm decisions have one shared record. The native form links to the same approval\nin Canary Notifications, also surfaced above the Flight page. On `needs-input`\nwith `approvalId` and `reviewUrl`, show that link and call `wait_for_approval` with\nthe ID; repeat on `still_waiting`. The human answers once in either surface.\nA browser answer resolves the server decision; some clients keep their native\nform visible until the human dismisses it. Dismissal then returns the stored\nresult. Client decline\u002Fcancel alone does not represent a human decision.\n\nWithout an `approvalId`, leave `needs-input` pending after decline\u002Fcancel, stale\ninput, or an unfinished UI action; do not automatically retry or repeat the\nquestion. Setup\u002Freconnection can use chat while MCP is unavailable. Never collect\npasswords, API keys, or access tokens in chat or form elicitation; use the returned\nCanary UI URL for secret entry.\n\n## MCP Invocation\n\nSetup and the plugin expose one public Canary Lab MCP tool: `exec` (usually\nrendered as `mcp__Canary_Lab__exec`). Every\nCanary Lab tool name below is the exact `command` value, not a separate public\ntool. For a feature-scoped command, replace both placeholders in this shape:\n\n```json\n{\"command\":\"\u003Cexact_tool_name>\",\"arguments\":{\"feature\":\"\u003Cfeature_name>\"}}\n```\n\nThis is the envelope shape, not every command's complete schema. Add the\nfields that command declares inside `arguments`; call `describe_tool` when a\nfield is uncertain.\n\nNever invent a wrapper verb such as `learn` or `call`, embed JSON in a command\nstring, or turn arguments into flags. Keep fields such as `confirm: true` inside\n`arguments`. Use `list_tools`, `search_tools`, or `describe_tool` as the\n`command` when discovery is needed. A deliberately selected focused or `full`\nprofile still exposes atomic tools for debugging; the setup-installed path is\n`compact` + `exec`.\n\nThese tools arrive via the Canary Lab MCP server. If this client is already\nconnected (the plugin connects with `compact`), skip this step. To configure\nthe same connection manually: `npx canary-lab mcp --profile compact`. Verification runs the\nfeature's Playwright specs against target URLs — a deployed environment\n(saved config, remote URLs) or a local app you first bring up with\n`boot_services`. There is no heal loop either way.\n\n## Arguments\n\nAn invocation argument (`\u002Fcanary-lab-verify \u003Csuite>`) is a suite (feature) name\nin the connected workspace. Use it directly, then choose the **Local app** or\n**Deployed environment** flow below from the target the user named.\n\n## When to choose Verify\n\nChoose Verify, not `start_run`, whenever the target is a deployed, staging or\nlive host the suite does not boot. A run boots the suite's services from its\nrepos and its repair cycle edits that local code; a remote deployment never\nreads it, so a run there can only \"pass\" by changing the test. If `start_run`\nreturned `type: \"verify_instead\"` or `remote_target_requires_choice`, this is\nthat case: its `targetOrigins` name the deployed hosts. Use a saved config, or\ncreate one and take the target URLs from the user — never copy them in from the\nenvset on your own.\n\n## Workspace Bootstrap\n\n1. Find the LIVE server first: read `~\u002F.canary-lab\u002Factive-servers.json`, which records `projectRoot`, `port` and `pid` for every UI that registered. A stopped server's entry LINGERS — the file is only rewritten when the next server registers — so an entry is a candidate, not proof: the health check below is what confirms it. One entry → that is your server and its `port`. Several → take the one whose `projectRoot` is the workspace the user means. None → fall back to `~\u002F.canary-lab\u002Fworkspaces.json` (Windows: `%USERPROFILE%\\.canary-lab\\workspaces.json`): one workspace → use it, several → ask which, none → ask the user to run `npx canary-lab setup`. Do NOT start from a guessed port.\n2. Then CONFIRM it is the right server: `curl -s http:\u002F\u002F127.0.0.1:\u003Cport>\u002Fmcp\u002Fhealth` and check that `projectRoot` is the workspace you intended. A healthy response does **not** settle the question on its own — a stale UI left behind by a demo or a tarball smoke test answers a port just as convincingly as the right one, and that is how a flight ends up running in someone's throwaway workspace. `projectRoot` matches what you intended → continue and tell the user which workspace. It names a DIFFERENT workspace → this is the wrong server; go back to step 1 rather than adopting it. It is under a temp directory (`\u002Ftmp`, `\u002Fprivate\u002Fvar\u002Ffolders`, `%TEMP%`) → never auto-select it; those are throwaway demo workspaces, so use one only when the user names it explicitly. Only when no live server serves the workspace you want does one need starting.\n3. If the health check fails, start `npx canary-lab ui` from the workspace in a visible long-running terminal; if this client cannot run long-lived commands, ask the user to run `npx canary-lab ui` from the workspace and confirm when it's up.\n4. A healthy `\u002Fmcp\u002Fhealth` means the server is live. On the setup-installed `compact` profile, atomic names such as `get_feature_coverage` are deliberately absent from `tools\u002Flist`; only `exec` is public. Call `exec` with `{\"command\":\"list_tools\",\"arguments\":{}}` before concluding the connection is missing. Only an unknown-tool error for `exec` means this session is not connected — ask the user to run `npx canary-lab setup --force` and reconnect\u002Frestart the client, then retry. Never drive `\u002Fmcp` with a hand-written HTTP\u002FJSON-RPC client (curl included; the health check above is the only direct HTTP use): a custom client bypasses client detection and reconnect handling.\n\n## Verification Loop\n\n**Local app** (\"verify a running app\" — the target is this workspace's own app, not a remote URL):\n\n1. `boot_services(feature)` boots the app's services and HOLDS them (no tests yet). Note the returned `runId` — it is the `bootRunId` everything below needs.\n2. Poll `get_run(bootRunId)` until every `manifest.services[]` entry is `status: \"ready\"` (a `failed`\u002F`timeout` service means the app itself won't start — report it; `abort_run` tears the boot down). Build `targetUrls` from the services: one entry per service, keyed by service name, valued with the **origin** of its `healthUrl` (scheme + host + port, no path).\n3. `execute_verification(feature, { targetUrls, playwrightEnvsetId: \"local\", bootRunId })`. Passing `bootRunId` is required — without it the held boot session itself trips the active-run collision check (409 \"Another execution is running\"); with it, Canary tears the boot down as the verification starts. Then continue at the polling step below.\n\n**Deployed environment** (staging\u002Fproduction URLs):\n\n1. `list_verification_configs` (optionally filtered by feature) shows the saved configs; `get_verification_config` reads one. In the UI, \"Playwright\" names which env file the specs run with and \"Services\" names the health-check targets — keep those domain labels when relaying. A config whose URLs contain `replace.invalid` is a scaffolded placeholder — never execute it as-is; update it with real URLs first (or use the Local app flow above).\n2. Create or adjust a config with `create_verification_config` \u002F `update_verification_config` — a config binds a feature to a target environment (base URLs, env set, health-check expectations). If target URLs are missing, omit `targetUrls` from the create\u002Fupdate call: it requests them through elicitation before saving. Only ask in chat when the tool reports elicitation unavailable. Never invent target URLs.\n3. `execute_verification` starts the verification run. `featureId` is required; pass either a saved `configId`, or ad-hoc `targetUrls` + `playwrightEnvsetId`. It returns an `executionId`.\n\n**Both flows**: if `execute_verification` returns `type: \"getting_started_busy\"`, a Getting Started demo already owns the workspace — follow the active target it returns; do not start another workflow. While the verification runs, the user can watch it live in the Canary Lab UI on the suite's Flight page (Test Run stage, in verify mode) — that view is read-only while this client drives.\n\n**Both flows end the same way**: poll `get_verification_result(executionId)` for the outcome; if it is still running, wait ~10s and call it again — stop once it reaches a terminal status. Report the result's `status`, and on failure the pass\u002Ffail counts in the result (`diagnostics.summary` \u002F `diagnostics.failedTests` — there is no `counts` field on a verify result). There is no heal claim here — a failure is a finding to report (and possibly a `canary-lab-run` follow-up locally), not something to fix against the target environment. Only request `abort_run` for a held boot session when the user asks; its human confirmation form must be accepted (without forms, use Stop in the Run panel) (the `bootRunId` hand-off above tears it down automatically).\n\n## Guardrails\n\n- Keep the same `session_id` for the whole conversation.\n- Never point a verification at production endpoints the user didn't name explicitly.\n- Verification results are evidence about the deployed environment; don't edit app code or tests in response — hand findings to the user (or switch to `canary-lab-run` for a local repair loop if they ask).\n","# Canary Lab — Environment Verification\n\n## User input through MCP 2.0\n\nUse the native Canary connector in the requesting chat so SDK 2.0 elicitation\n(`input_required`) reaches the human there. Do not substitute a shell MCP client,\nanswer a form yourself, or recreate the question in chat. Existing explicit\ninstructions and autopilot choices still apply without another ask.\n\nForm decisions have one shared record. The native form links to the same approval\nin Canary Notifications, also surfaced above the Flight page. On `needs-input`\nwith `approvalId` and `reviewUrl`, show that link and call `wait_for_approval` with\nthe ID; repeat on `still_waiting`. The human answers once in either surface.\nA browser answer resolves the server decision; some clients keep their native\nform visible until the human dismisses it. Dismissal then returns the stored\nresult. Client decline\u002Fcancel alone does not represent a human decision.\n\nWithout an `approvalId`, leave `needs-input` pending after decline\u002Fcancel, stale\ninput, or an unfinished UI action; do not automatically retry or repeat the\nquestion. Setup\u002Freconnection can use chat while MCP is unavailable. Never collect\npasswords, API keys, or access tokens in chat or form elicitation; use the returned\nCanary UI URL for secret entry.\n\n## MCP Invocation\n\nSetup and the plugin expose one public Canary Lab MCP tool: `exec` (usually\nrendered as `mcp__Canary_Lab__exec`). Every\nCanary Lab tool name below is the exact `command` value, not a separate public\ntool. For a feature-scoped command, replace both placeholders in this shape:\n\n```json\n{\"command\":\"\u003Cexact_tool_name>\",\"arguments\":{\"feature\":\"\u003Cfeature_name>\"}}\n```\n\nThis is the envelope shape, not every command's complete schema. Add the\nfields that command declares inside `arguments`; call `describe_tool` when a\nfield is uncertain.\n\nNever invent a wrapper verb such as `learn` or `call`, embed JSON in a command\nstring, or turn arguments into flags. Keep fields such as `confirm: true` inside\n`arguments`. Use `list_tools`, `search_tools`, or `describe_tool` as the\n`command` when discovery is needed. A deliberately selected focused or `full`\nprofile still exposes atomic tools for debugging; the setup-installed path is\n`compact` + `exec`.\n\nThese tools arrive via the Canary Lab MCP server. If this client is already\nconnected (the plugin connects with `compact`), skip this step. To configure\nthe same connection manually: `npx canary-lab mcp --profile compact`. Verification runs the\nfeature's Playwright specs against target URLs — a deployed environment\n(saved config, remote URLs) or a local app you first bring up with\n`boot_services`. There is no heal loop either way.\n\n## Arguments\n\nAn invocation argument (`\u002Fcanary-lab-verify \u003Csuite>`) is a suite (feature) name\nin the connected workspace. Use it directly, then choose the **Local app** or\n**Deployed environment** flow below from the target the user named.\n\n## When to choose Verify\n\nChoose Verify, not `start_run`, whenever the target is a deployed, staging or\nlive host the suite does not boot. A run boots the suite's services from its\nrepos and its repair cycle edits that local code; a remote deployment never\nreads it, so a run there can only \"pass\" by changing the test. If `start_run`\nreturned `type: \"verify_instead\"` or `remote_target_requires_choice`, this is\nthat case: its `targetOrigins` name the deployed hosts. Use a saved config, or\ncreate one and take the target URLs from the user — never copy them in from the\nenvset on your own.\n\n## Workspace Bootstrap\n\n1. Find the LIVE server first: read `~\u002F.canary-lab\u002Factive-servers.json`, which records `projectRoot`, `port` and `pid` for every UI that registered. A stopped server's entry LINGERS — the file is only rewritten when the next server registers — so an entry is a candidate, not proof: the health check below is what confirms it. One entry → that is your server and its `port`. Several → take the one whose `projectRoot` is the workspace the user means. None → fall back to `~\u002F.canary-lab\u002Fworkspaces.json` (Windows: `%USERPROFILE%\\.canary-lab\\workspaces.json`): one workspace → use it, several → ask which, none → ask the user to run `npx canary-lab setup`. Do NOT start from a guessed port.\n2. Then CONFIRM it is the right server: `curl -s http:\u002F\u002F127.0.0.1:\u003Cport>\u002Fmcp\u002Fhealth` and check that `projectRoot` is the workspace you intended. A healthy response does **not** settle the question on its own — a stale UI left behind by a demo or a tarball smoke test answers a port just as convincingly as the right one, and that is how a flight ends up running in someone's throwaway workspace. `projectRoot` matches what you intended → continue and tell the user which workspace. It names a DIFFERENT workspace → this is the wrong server; go back to step 1 rather than adopting it. It is under a temp directory (`\u002Ftmp`, `\u002Fprivate\u002Fvar\u002Ffolders`, `%TEMP%`) → never auto-select it; those are throwaway demo workspaces, so use one only when the user names it explicitly. Only when no live server serves the workspace you want does one need starting.\n3. If the health check fails, start `npx canary-lab ui` from the workspace in a visible long-running terminal; if this client cannot run long-lived commands, ask the user to run `npx canary-lab ui` from the workspace and confirm when it's up.\n4. A healthy `\u002Fmcp\u002Fhealth` means the server is live. On the setup-installed `compact` profile, atomic names such as `get_feature_coverage` are deliberately absent from `tools\u002Flist`; only `exec` is public. Call `exec` with `{\"command\":\"list_tools\",\"arguments\":{}}` before concluding the connection is missing. Only an unknown-tool error for `exec` means this session is not connected — ask the user to run `npx canary-lab setup --force` and reconnect\u002Frestart the client, then retry. Never drive `\u002Fmcp` with a hand-written HTTP\u002FJSON-RPC client (curl included; the health check above is the only direct HTTP use): a custom client bypasses client detection and reconnect handling.\n\n## Verification Loop\n\n**Local app** (\"verify a running app\" — the target is this workspace's own app, not a remote URL):\n\n1. `boot_services(feature)` boots the app's services and HOLDS them (no tests yet). Note the returned `runId` — it is the `bootRunId` everything below needs.\n2. Poll `get_run(bootRunId)` until every `manifest.services[]` entry is `status: \"ready\"` (a `failed`\u002F`timeout` service means the app itself won't start — report it; `abort_run` tears the boot down). Build `targetUrls` from the services: one entry per service, keyed by service name, valued with the **origin** of its `healthUrl` (scheme + host + port, no path).\n3. `execute_verification(feature, { targetUrls, playwrightEnvsetId: \"local\", bootRunId })`. Passing `bootRunId` is required — without it the held boot session itself trips the active-run collision check (409 \"Another execution is running\"); with it, Canary tears the boot down as the verification starts. Then continue at the polling step below.\n\n**Deployed environment** (staging\u002Fproduction URLs):\n\n1. `list_verification_configs` (optionally filtered by feature) shows the saved configs; `get_verification_config` reads one. In the UI, \"Playwright\" names which env file the specs run with and \"Services\" names the health-check targets — keep those domain labels when relaying. A config whose URLs contain `replace.invalid` is a scaffolded placeholder — never execute it as-is; update it with real URLs first (or use the Local app flow above).\n2. Create or adjust a config with `create_verification_config` \u002F `update_verification_config` — a config binds a feature to a target environment (base URLs, env set, health-check expectations). If target URLs are missing, omit `targetUrls` from the create\u002Fupdate call: it requests them through elicitation before saving. Only ask in chat when the tool reports elicitation unavailable. Never invent target URLs.\n3. `execute_verification` starts the verification run. `featureId` is required; pass either a saved `configId`, or ad-hoc `targetUrls` + `playwrightEnvsetId`. It returns an `executionId`.\n\n**Both flows**: if `execute_verification` returns `type: \"getting_started_busy\"`, a Getting Started demo already owns the workspace — follow the active target it returns; do not start another workflow. While the verification runs, the user can watch it live in the Canary Lab UI on the suite's Flight page (Test Run stage, in verify mode) — that view is read-only while this client drives.\n\n**Both flows end the same way**: poll `get_verification_result(executionId)` for the outcome; if it is still running, wait ~10s and call it again — stop once it reaches a terminal status. Report the result's `status`, and on failure the pass\u002Ffail counts in the result (`diagnostics.summary` \u002F `diagnostics.failedTests` — there is no `counts` field on a verify result). There is no heal claim here — a failure is a finding to report (and possibly a `canary-lab-run` follow-up locally), not something to fix against the target environment. Only request `abort_run` for a held boot session when the user asks; its human confirmation form must be accepted (without forms, use Stop in the Run panel) (the `bootRunId` hand-off above tears it down automatically).\n\n## Guardrails\n\n- Keep the same `session_id` for the whole conversation.\n- Never point a verification at production endpoints the user didn't name explicitly.\n- Verification results are evidence about the deployed environment; don't edit app code or tests in response — hand findings to the user (or switch to `canary-lab-run` for a local repair loop if they ask).\n",{"name":5,"type":52,"description":7},"skill","main","2c85305cab69e5f773d59ea79a64a0b049a98345","agent-integrations\u002Fclaude\u002Fskills\u002Fcanary-lab-verify",0,"https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab","https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fcanary-lab","https:\u002F\u002Fgithub.com\u002Fferterahadi","https:\u002F\u002Fgithub.com\u002Fferterahadi-oddle","Shipping well-tested, production-ready, vibe-coded code using today’s latest form of engineering - harness, agentic, loop, graph, or whatever drops next","2026-11-12 23:36:35",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add ferterahadi\u002Fcanary-lab --skill canary-lab-verify",{"tool":69,"command":70},"bunx","bunx skills add ferterahadi\u002Fcanary-lab --skill canary-lab-verify",{"tool":72,"command":73},"pnpm","pnpm dlx skills add ferterahadi\u002Fcanary-lab --skill canary-lab-verify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fagent-integrations\u002Fclaude\u002Fskills\u002Fcanary-lab-verify\u002FSKILL.md",true,[],[78,87,97,114,135,142],{"skillNo":79,"name":80,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":85,"publishedAt":47},"01M6XCWFJ75NNVF0N8C0XGNC17","off-by-one","https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fapps\u002Fweb-server\u002Fprompts\u002Fsabotage-skills\u002Foff-by-one\u002Fskill.md",[83,84],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[86],"off by one",{"skillNo":88,"name":89,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":94,"publishedAt":47},"01M6XCWBYW1QHVFKSDQCCRRRDT","multi-failure-cascade","https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fapps\u002Fweb-server\u002Fprompts\u002Fsabotage-skills\u002Fmulti-failure-cascade\u002Fskill.md",[92,93],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[95,96],"multi","multi failure cascade",{"skillNo":98,"name":99,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":109,"publishedAt":47},"01M6XCW8XA7QY74Q18D9PGFFMD","broken-delete-contract","https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fapps\u002Fweb-server\u002Fprompts\u002Fsabotage-skills\u002Fbroken-delete-contract\u002Fskill.md",[102,103,104],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[110,111,112,113],"delete","broken","contract","broken delete contract",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":122,"publishedAt":47},"01M6XCW439KA486AN2QZACNYTC","canary-lab","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 \u002F get_flight \u002F respond_flight_checkpoint over MCP). One conducted pipeline continues a configured suite or takes bare repo(s) to a green, covered, healed run and publishes a downloadable Report; Parallel setup continues as Canary-owned background work. Use a focused skill only when the user asks for that single capability without asking for a Flight or \u002Fcanary-lab.","https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fagent-integrations\u002Fplugin\u002Fcanary-lab\u002Fskills\u002Fcanary-lab\u002FSKILL.md",[120,121],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[28,29,123,124,125,126,127,128,129,38,37,36,130,131,132,133,33,134,39,44],"canary lab","capability","pipeline","work","only","take","green","respond","suite","product","bare","start",{"skillNo":136,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":141,"publishedAt":47},"01M6XCVYQ31KC4ZXCD5QMRKXEE","https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fagent-integrations\u002Fplugin\u002Fcanary-lab\u002Fskills\u002Fcanary-lab-verify\u002FSKILL.md",[139,140],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[29,30,28,27,123,38,39,46,45,44,43,42,41,40,31,37,36,35,34,33],{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":153,"publishedAt":47},"01M6XCVSWW705CN3C69FQMPZXN","canary-lab-run","Use when running or healing an EXISTING Canary Lab feature locally — \"run \u003Cfeature>\", \"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\u002Fservice code, not tests. For end-to-end onboarding of a new repo use canary-lab (flight); for deployed-environment checks use canary-lab-verify.","https:\u002F\u002Fgithub.com\u002Fferterahadi\u002Fcanary-lab\u002Fblob\u002Fmain\u002Fagent-integrations\u002Fplugin\u002Fcanary-lab\u002Fskills\u002Fcanary-lab-run\u002FSKILL.md",[148,149,150],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":151,"categoryName":152,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000030","开发工程师",[154,123,44,29,28,37,38,155,156,40,41,134,157,39,33,158,159,36,160,161],"canary lab run","fix","context","code","rerun","wait","new repo","failing"]