---
name: welltested-verify
description: Verify user-facing changes end to end with Well Tested (real cloud browser, AI triage, proof links) before telling the user the work is done. Use after any change that affects UI, pages, forms, navigation or a user flow, when the welltested_* MCP tools are available.
version: 1.0.0
---

# Verify before done (Well Tested)

Well Tested runs the user's app in a real cloud browser and returns a verdict, AI triage
and a proof link. Unit tests and lint check code; they do not prove that a user can
finish a flow. Use these rules whenever the `welltested_*` tools are connected.

## When to verify

After a change that affects UI or a user flow (a page, form, button, navigation,
sign-up, checkout, anything a user clicks), and before you say the work is done.
Skip it for changes with no user-visible effect (comments, internal refactors with
passing tests, docs).

## The loop

1. **Context first.** Once per session, before your first `welltested_plan`, call
   `welltested_status`. If you have read the app's code, fill `appContext` on that first
   plan: framework, routes (path, purpose, requiresAuth), features (name, userGoal,
   routes, up to 5 acceptance lines), auth kind and login path, and API calls. Put the
   features your current change touches in `changedInThisSession`, and update it for
   each new change. Summaries only: never paste file contents, secrets, tokens,
   passwords or env values.
2. **Reuse kept tests.** Call `welltested_list_scenarios`. If kept tests or a suite cover
   the flow you changed, run them with `welltested_run { scenarioIds }` or
   `{ suiteId }`. Kept tests rerun without new approval.
3. **Otherwise plan.** Call `welltested_plan` with a one- or two-sentence goal in the
   user's words. Show the numbered steps (and any open questions) to the user and ask
   them to approve in chat. Only after they say yes, call
   `welltested_run { planId, userApproved: true }`. Never set `userApproved` yourself
   without the user's yes.
4. **Wait for the result.** Call `welltested_get_run { runId, waitSeconds: 50 }` until
   `status` is `passed` or `failed`. Do not tell the user the work is done while a
   relevant run is queued, running or red.
5. **On failure, read `triage.label`:**
   - `bug`: the app is wrong. Fix the code using `failure.step`, `failure.runtime`
     (console errors, failing requests), `changedSinceLastGreen` and `fixPrompt`,
     then rerun.
   - `test_or_environment`: the test or the environment is the problem. Say so to the
     user, then fix the plan (a clearer goal) or the environment, and rerun.
   - `inconclusive`, or no triage: show the user the proof link and the failing step
     and ask how to proceed before changing code.
6. **Keep what passed.** When a new plan passes, offer to keep it:
   `welltested_save_scenario { runId }`. It joins the app's regression set.
7. **Always link the proof.** Include `links.run` (or `links.share`) in your final
   message, for passed and failed runs alike.

## Limits

- If a run is refused with `TARGET_UNREACHABLE`, `TUNNEL_OFFLINE` or
  `TARGET_HTTP_ERROR`, nothing ran and nothing was charged. Tell the user the
  remediation (for a local app: `npx welltested tunnel --port <port>`), then retry.
- Every tool result has a `next_action`. Follow it.
- Runs count toward the user's monthly runs. Do not loop reruns without a change in
  between.