| name | canary-verify |
| description | Turn a code change into a prioritized browser-QA plan with Canary — read the git diff, infer which user-facing workflows it touches, suggest the concrete flows and the checks that must hold, then optionally record those flows as a session with a report.html. Use when the user has changed code and asks what to test, wants to QA a diff, branch, or PR, or wants a focused regression plan before merging. Trigger phrases — "what should I test for this change", "QA my diff", "verify this PR", "I changed X, what flows might break", "regression plan for this branch", "what should I QA before merging". |
| license | MIT |
| metadata | {"author":"usecanary","version":"0.4.4","category":"workflow","tags":["canary","qa","testing","regression","planning"]} |
Canary verify (change → QA plan)
Read a code change, infer the user-facing workflows it affects, and suggest a prioritized QA
plan — the concrete Canary flows that verify them. Then optionally hand off to canary-session to
record those flows and produce report.html. Use the canary-scripting skill for the step API.
When to use
- The user changed code and asks what to test or what might regress.
- QA-ing a diff, branch, or PR before merging.
- Building a focused regression plan scoped to the change — not a full re-test.
- Only need the suggestion? Stop at the plan. Need evidence? Hand off to canary-session. Driving a
browser once with no plan? Use canary-automate.
Examples
Example 1: verify the working tree
User says: "what should I QA for these changes?" or "verify my diff"
Read the working-tree diff, map changed files to affected routes/flows, and present a ranked plan
(P0/P1/P2). Offer to record the P0 flows as a session.
Example 2: verify a branch or PR before merge
User says: "regression plan for feature/checkout" or "QA this PR"
Diff the branch against its base, group the touched workflows, suggest the steps per flow, and hand
the approved flows to canary-session for a report.
Workflow
- Get the diff. Working tree:
git diff and git diff --staged. A branch/PR:
git diff <base>...HEAD (list files with git diff --name-status <base>...HEAD). Or reason
straight from a prose description ("I changed the login redirect") — skip git.
- Infer affected workflows. For each changed file, decide whether it touches a user-facing
route/page/flow, and group by workflow (sign-up, checkout, …), not by file. File→workflow
heuristics are in
references/REFERENCE.md.
- Suggest a prioritized plan. For each workflow: a one-line intent, a P0/P1/P2 priority, the
entry URL, the checks that must hold (visible text / URL / state / no console error), the likely
phases as a guide — not a pre-written script — and which changed files put it at risk. Use the plan
template in
references/REFERENCE.md.
- Confirm, then hand off. Present the plan and ask which flows to record. For approved flows,
follow canary-session's explore-and-record loop (one session per flow: observe the live page,
small intent-named steps, assertion steps for the checks) →
report.html; offer canary-review
to open it. Don't record flows the user didn't approve.
Hard rules
- Suggest first, record second — the default output is the plan; only record after the user confirms.
- Map to user-facing workflows, not files. Call out non-UI changes (pure refactors, types,
config/build, docs) as no browser QA needed rather than inventing a flow.
- Read-only on the repo — inspect the diff and code; never stage, commit, or modify source.
- Recording reuses canary-session — don't reinvent
session start / run / session end here.
- No diff (or all non-UI)? Say so plainly and stop — don't fabricate a plan.
