canary-verify

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

1. 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.
2. 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.
3. 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.
4. 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.