/verify

argument-hint: [url | path]

Escalatory browser verification - open the app and test it in a real browser.

Browser Verification (Escalatory Command)

**Use this when:** User asks you to "go verify in browser" or "actually test this" after you've shown "READY FOR REVIEW".

**Two modes** (full details in `skills/jat-verify/SKILL.md`):

• **builder-verify** (this doc): prove the feature you just built works.
• **cold-review** (`/jat:verify --cold <url>`): fresh-eyes reviewer pass over a whole surface/site before it's shown to a human — three-questions framework, operate-everything rule, severity-ranked findings, mobile + console sweeps, and the cold-review → fix wave → re-verify loop. Use it before sending any preview/demo/launch to a customer or judge.

**What this does:** 1. Opens browser to the relevant page 2. Tests the specific feature you built 3. Checks console for errors 4. Reports what you see

**This is NOT for:** Static checks (tests, lint, types) - those are in `/jat:complete`.

---

Browser Tools Overview

JAT includes lightweight browser automation tools in `~/.local/bin/`:

| Tool | Purpose | |------|---------| | `browser-start.js` | Launch Chrome with DevTools port | | `browser-nav.js` | Navigate to URL | | `browser-screenshot.js` | Capture screenshot | | `browser-eval.js` | Execute JavaScript in page | | `browser-pick.js` | Click element by selector | | `browser-cookies.js` | Get/set cookies | | `jat-run-workspace.js` | Record this verification session into a durable evidence bundle (see below) |

These tools are **low-token** - they just run commands and return results.

Capture evidence with jat-run-workspace.js

Wrap STEP 2–4 below in a run workspace so the network traffic, console log, and screenshots from this verification session survive past the terminal scrollback into `.jat/runs/<taskId>/` — a directory the overseer/human can open, and that `jat-runtime-verify --task <id>` reads automatically to assert on captured API response status/shape instead of a synthetic GET.

jat-run-workspace.js start --task jat-abc123
# ... STEP 2 (navigate), STEP 3 (interact), STEP 4 (console check) below ...
jat-run-workspace.js stop --task jat-abc123

`stop` prints the evidence dir and a one-line summary (request/console/screenshot counts). Screenshots taken via `jat-run-workspace.js screenshot --task <id> --label <name>` land in `screenshots/` inside that same run dir instead of scattering into `/tmp` — use this instead of `browser-screenshot.js` when a run workspace is active, so all the evidence for this task lives in one place.

**Reference the run dir on your `review` signal** (`needToKnow` or `doNow`) so the overseer/human can open the real evidence instead of trusting a prose report:

jat-signal review '{
  "taskId": "jat-abc123",
  "needToKnow": ["Verification evidence: .jat/runs/jat-abc123/ (network.har, console.jsonl, screenshots/)"]
}'

Need Deeper Testing?

If the basic browser tools aren't enough (complex debugging, network inspection, performance profiling), you can enable the **ChromeDevTools MCP**:

# Enable ChromeDevTools MCP (burns more tokens but gives full DevTools access)
# Add to .mcp.json:
{
  "mcpServers": {
    "chromedevtools": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-chromedevtools"]
    }
  }
}

**When to enable ChromeDevTools MCP:**

• Network waterfall analysis
• Performance profiling
• Complex console debugging
• DOM inspection with full tree
• Memory leak detection

**For most verification, the basic browser tools are sufficient.**

---

Quick Start

# If user says "verify this" - figure out what page to test based on your work
/jat:verify

# If user gives a specific URL
/jat:verify http://localhost:5173/tasks

# If user gives a path hint
/jat:verify /tasks

---

Implementation

STEP 1: Determine What to Test

Based on your recent work, identify:

• **URL**: What page should you open?
• **Feature**: What specific thing should you test?
• **Success criteria**: How do you know it works?

If unclear, ask the user:

I made changes to [files]. Which page should I verify?
- http://localhost:5173/tasks
- http://localhost:5173/work
- Other URL?

STEP 2: Open Browser and Navigate

**Attach to the persistent browser on CDP :9222 — never `browser-start.js --port 9222` (it kills it).** Prefer the chrome-devtools MCP tools (`navigate_page`, `take_screenshot`, `take_snapshot`) when available; the `browser-*.js` CLI tools attach to :9222 by default.

# If capturing evidence for this task, start the run workspace first (see above)
jat-run-workspace.js start --task jat-abc123

# Navigate to the page (attaches to the persistent browser)
browser-nav.js --url "http://localhost:5173/tasks"

# Take initial screenshot — into the run workspace if one is active, else /tmp
jat-run-workspace.js screenshot --task jat-abc123 --label initial
# browser-screenshot.js --output /tmp/verify-initial.png   # when not capturing evidence

# Only for a THROWAWAY instance (auto-picks a free port, never 9222):
# browser-start.js

Show the screenshot to the user: "Here's what I see..."

STEP 3: Test the Feature

Based on what you built, interact with it:

# Click a button
browser-pick.js --selector "button.create-task"

# Fill a form field
browser-eval.js "document.querySelector('input[name=title]').value = 'Test task'"

# Check if element exists
browser-eval.js "!!document.querySelector('.success-message')"

# Wait for something to appear
browser-eval.js "document.body.innerText.includes('Task created')"

Take screenshots after each significant action.

STEP 4: Check Console for Errors

Prefer the chrome-devtools MCP: `list_console_messages` with `types: ["error","warn"]` (add `includePreservedMessages: true` after multi-page flows). Fallback via CLI:

browser-console.js   # capture console logs from the attached page

Do NOT monkeypatch `cons