cl_verify-the-premise
Use before acting on an unverified code claim, bug report, known gap, or assumption that several implementations behave alike.
- License 许可
- MIT
- 最近更新
- 2026-11-14
- Stars
- ★ 4
- Forks
- 0
01 前言 Front Matter
- name
- cl_verify-the-premise
- description
- Use before acting on an unverified code claim, bug report, known gap, or assumption that several implementations behave alike.
03 SKILL.md 正文
<!-- GENERATED FROM .claude/skills — DO NOT EDIT.
Run npm run gen:skills after editing the source skill (the build does this too). -->
Verify the Premise, Not Just the Mechanism
Plans, follow-ups, and bug reports are hypotheses. Confirm the reported behavior against today's code before changing it.
Check
- Reproduce the observable problem, not only the proposed mechanism.
- Search for existing handlers, events, refetch paths, or alternate names.
- Before treating several implementations alike, open every one and find the lifecycle or ownership differences.
If evidence disproves the premise, stop and report that evidence. Do not build a second path. A plausible, tested fix can still be unnecessary.
Warning signs
- A plan is your only proof that something is missing.
- You verified an internal mechanism but not the user-visible failure.
- You explain an existing solution away as redundant or legacy.
- You assume all instances match without opening them.
Complements [[cl_verify-changes]], which verifies the result after a change.
04 同仓库更多 Skills
off-by-one
暂无简介
multi-failure-cascade
暂无简介
broken-delete-contract
暂无简介
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 / get_flight / 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 /canary-lab.
canary-lab-verify
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/get/create/update_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).
canary-lab-run
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.