| name | planr-verify-web |
| description | Live verification for web features. Use when a web map item needs proof it actually runs in a browser before review, including planr-loop step 4. Discovers the host's existing browser capability, runs the changed flow against the dev server, and logs replayable evidence. Ships no browser tooling of its own. |
Planr Verify Web
Prove the feature runs. Planr owns the evidence contract; the host owns the browser tooling. Never install or configure browser infrastructure on behalf of this skill.
Capability Discovery
Check project memory first:
planr context list
If a capability-tagged entry records a web verification tool, use it. Otherwise discover what the host has, strongest first:
- A browser skill the host already provides (for example browser-harness): drive the real flow, screenshot the result.
- A browser MCP already configured (Playwright, chrome-devtools, native browser tools): same.
- The system browser over CDP: launch the installed Chrome/Chromium with
--remote-debugging-port=<port> --user-data-dir=<tmp> and drive it via the DevTools protocol. This is the standard rescue when a browser tool exists but its bundled browser is missing — the tool's download step is not a dependency, the protocol is.
- A scriptable fallback when Node is available: a one-off headless check via
npx playwright whose exit code is the signal.
- HTTP-level checks (
curl against rendered routes or endpoints): weakest tier, only for SSR/API-shaped changes, and the log must say "HTTP-level only, not browser-verified".
If a tier fails for an environmental reason (missing download, sandbox restriction), drop to the next tier and record what actually worked — do not log the environmental failure as item evidence.
Record the decision once so later iterations and other agents reuse it instead of re-discovering:
planr context add "web verification: <tool>, invoke via <how>" --tag capability
A human may pin the capability upfront with the same command; a pinned context always wins over discovery.
Dev Server
Detect a running dev server before anything else and use it. Never start a second instance. Only start one (in the background, and stop it afterwards) when none is running and the loop is unattended.
Run The Verification
Exercise the flow the item changed — not the homepage. Interact, assert on rendered output, capture a screenshot when the tier supports it.
Then log evidence on the item:
planr log add --item <item-id> --kind verification \
--summary "live verification (<tier>): <what was exercised and observed>" \
--cmd "<exact replayable command>"
--kind verification marks the log as live-verify evidence; planr plan audit checks for it when a goal contract exists.
Attach screenshots or traces as artifacts on the item:
planr artifact add "verify-web screenshot" --item <item-id> --path <screenshot-path> --kind screenshot
planr artifact add "verify-web recording" --item <item-id> --path <recording.mp4> --kind video
The replay command is mandatory. The reviewer reruns it instead of trusting this run; a verification that cannot be replayed is not evidence.
When Verification Is Impossible
No capability, no Node, no reachable server: do not fake it and do not downgrade silently.
planr context add "live verification blocked: <missing capability>" --item <item-id> --tag blocker
planr approval request <item-id> --reason "manual live verification required"
Then pause (or let planr-loop pause) until a human resolves it.
Outcome
- Pass: evidence logged, proceed to
planr review request <item-id>.
- Fail: the feature does not work — log the failing command and observed behavior, then fix under the same item before requesting review. A failed live run is a finding against the implementation, never a reason to weaken the check.
