/jat-verify

name: jat-verify
description: Escalatory browser verification - open the app in a real browser and test it. Two modes - builder-verify (test the feature you just built) and cold-review (fresh-eyes reviewer pass over a whole surface or site). Use after "READY FOR REVIEW", before shipping a preview/demo to a human, or when asked to "actually test this" / "review this like a stranger".
metadata:
  author: jat
  version: "2.0"

/skill:jat-verify - Browser Verification

Test work in a real browser. Two modes:

| Mode | When | Output | |------|------|--------| | **builder-verify** | You just built a feature; prove it works end-to-end | pass/fail checklist + screenshots | | **cold-review** | A surface/site is about to be shown to a human (customer preview, demo, contest, launch) | severity-ranked findings report |

/skill:jat-verify                            # builder-verify, auto-detect what to test
/skill:jat-verify /tasks                     # builder-verify a specific path
/skill:jat-verify --cold https://site.tld    # cold-review an entire experience

NOT for static checks (tests, lint, types) — those live in `/skill:jat-complete`.

Browser Tooling (both modes)

**Attach, don't relaunch.** A persistent browser runs on CDP port 9222. NEVER run `browser-start.js --port 9222` (it kills the persistent browser). Preferred, in order:

1. **chrome-devtools MCP tools** (`mcp__chrome-devtools__*`) — available in most sessions; use `new_page`, `navigate_page`, `take_screenshot`, `take_snapshot`, `evaluate_script`, `list_console_messages`, `emulate`. 2. **`browser-*.js` CLI tools** (`~/.local/bin/`) — they attach to :9222 by default. Only use `browser-start.js` (no `--port`) for a throwaway instance.

Key techniques:

• **Fresh state:** `new_page` with `isolatedContext: "review-<id>"` gives clean cookies/storage — mandatory for cold-review, useful for auth flows.
• **Console errors:** `list_console_messages` with `types: ["error","warn"]` (+ `includePreservedMessages: true` after multi-page flows). Do NOT monkeypatch `console.error`.
• **Mobile:** `emulate` with `viewport: "390x844x2,mobile,touch"` (window resize fails on maximized windows). Clear with empty viewport string.
• **Timing:** wrap actions in `evaluate_script` polling loops and record elapsed ms — "felt slow" needs a number.

Mode 1: builder-verify

1. **Determine target** — URL, feature, success criteria from your recent work. Ask only if genuinely ambiguous. 2. **Navigate + screenshot** the initial state. 3. **Operate the feature** — click/fill/submit the real UI (snapshot → click by uid, or `evaluate_script`). Screenshot after each significant action. 4. **Check console** (`list_console_messages`, errors + warnings). Note pre-existing vs new. 5. **Report** pass/fail checklist + screenshot paths. Failed → fix, re-verify, then return to 🔍 READY FOR REVIEW.

Mode 2: cold-review (fresh-eyes reviewer pass)

Role-play the coldest plausible visitor (a customer prospect, a contest judge, a new hire). You are NOT the builder — be a skeptic, try to break it. The value is what a stranger trips on that the builders can no longer see.

**Rules of engagement:**

1. **Blank slate:** isolated browser context, no reading the code first. Discover the experience the way a visitor does. 2. **The three questions, at every surface:** (a) What am I looking at? (b) What am I supposed to do here? (c) After I do it, what happens and where do I go next? Any surface that fails one of these is a finding. 3. **Operate everything.** Every primary CTA gets clicked, every flow completed for real. If it generates, generate. If it uploads, upload. A button that appears to do nothing is a finding even if code says it works. 4. **Follow every outbound link and promised artifact** (docs, GitHub, "read more", download). A 404 on a link the experience depends on is a blocker. (Real case: a contest demo's README link — the judged criterion — 404'd for signed-out visitors.) 5. **Hunt the promised moments.** Anything the copy promises ("watch it refuse", "see X happen") must be reachable by following the on-screen guidance alone. If you need expert knowledge or N extra steps to trigger it, the demo's money moment is buried — major finding. 6. **Adversarial inputs:** bare domains, garbage input, nonexistent resources, double-clicks, back-button. Clean failure = pass; dead spinner/blank = finding. 7. **Time everything** that runs async. Report dead spinners, hangs, and anything > a few seconds with no progress feedback. 8. **Mobile pass** (~390px emulation) over each major surface: horizontal overflow, tap targets, legibility. 9. **Console sweep** on every page visited. 10. **Screenshot the notably good AND the notably broken.**

**Report format:**

COLD REVIEW: <target>
1. First impression — honest 5-second and 30-second reactions
2. Walk-through, surface by surface — three questions answered; what worked; what confused
3. Findings ranked: BLOCKERS (visitor bounces) → MAJOR (money moment lost) → PAPERCUTS
4. Strengths — what specifically lands (so fixes don't break it)
5. Screenshot index

Be blunt; flattery is useless. If it's great, say what specifically lands.

**The loop — cold-review is step 1 of 3:**

cold-review (reviewer) → fix wave (builder) → RE-VERIFY (same reviewer)

The re-verify is not optional: run the same E2E path again and hunt **second-order leaks** — the layer below the fixes. (Real cases: after a theming fix, outtake rows still carried the old vertical; a `{{first_name}}` fallback rendered a literal "there"; stale cache entries from before the fix silently bypassed it.) Fixes introduce their own disconnects; only the same cold path finds them.

**Signals:** in a JAT task session, emit `jat-signal review` with `findings` (ranked) before presenting; blockers/major items go in `doNow`/`suggestedTasks`.

After Verification

• **builder-verify passed** → 🔍 READY FOR REVIEW; user can `/jat:complete`.
• **builder-veri