Capture ticket proof with Playwright instead of the browser extension

user/agents/skills/ticket/SKILL.md

@@ -61,6 +61,9 @@ watching the page change.
 
 - `~/.agents/skills/ticket/scripts/ticket-page <command> <KEY> ...` — the only writer of the
   ticket page and epic index. See [SITE.md](SITE.md), or `ticket-page help`. Runs under bun.
+- `~/.agents/skills/ticket/scripts/capture-proof` — sharp Playwright screenshots of the
+  running app for proof and spike screenshots. `capture-proof help` lists its options. The
+  first run installs a pinned Playwright into `~/.cache/ticket-page/`.
 - `~/.agents/skills/ticket/scripts/jira-fetch-issue.sh <KEY> <OUT.json>` — fetches one
   issue (`fields=*all`, rendered HTML description, field-name map) via `JIRA_BASE_URL` /
   `JIRA_CREDENTIALS`.
@@ -362,8 +365,8 @@ what was quick to wire up. Ship both, and don't let either stand in for the othe
   than a static mock would, say so in the plan's approach rather than silently scoping it down
   without mentioning the tradeoff.
 - **Screenshot the real thing.** Once it's built and running, use the `run` skill to
-  get the app up and a browser automation tool (e.g. `claude-in-chrome`) to capture
-  the actual screens, instead of drawing a wireframe. Save screenshots under
+  get the app up and capture the actual screens with `capture-proof`, as the proof step
+  in Phase 2 describes, instead of drawing a wireframe. Save screenshots under
   `deliverables/<slug>/screenshots/` and the visual mocks under
   `deliverables/<slug>/mocks/`, and embed both in `<slug>.typ` via `image()` when
   building the mockups deliverable. Label which is which. A reader who can't tell a
@@ -831,7 +834,32 @@ Entered only when the user has confirmed (per Phase 0) that the plan is approved
 
    **Proof first.** Before filling any proof column, capture working feature proof
    yourself wherever possible: run the app (`run` skill) and screenshot the real
-   feature with browser automation, or capture test output for behavior with no UI.
+   feature with `capture-proof`, or capture test output for behavior with no UI.
+
+   **Screenshots come from Playwright, never from a browser-extension screen grab.**
+   Extension captures come out soft and hard to read, and a proof screenshot exists to be
+   read. `capture-proof shot` renders at twice the pixel density with animations frozen,
+   fonts loaded, and dev overlays hidden:
+
+   ```
+   capture-proof shot http://localhost:3000/companies --wait-for "text=Canonical ID" --out <target-dir>/proof/companies-grid-canonical-ids.png
+   ```
+
+   - **Sign-in.** The first `shot` against an app that needs a session stops with a sign-in
+     hint. Ask Gib to run `capture-proof login <origin>` himself: it opens a visible
+     browser, he signs in and closes the window, and every later `shot` against that
+     origin reuses the session. It is saved under `~/.cache/ticket-page/auth/`, never in a
+     repo. The hint only catches a redirect to a sign-in path, so look at every capture
+     before recording it.
+   - **Frame the evidence.** Pass `--wait-for` with the thing the proof is about, so the
+     capture never catches a loading spinner. Crop to the part that matters with
+     `--selector`, or take the whole page with `--full`.
+   - **Interaction first.** For state that takes clicks or typing (an open dialog, a
+     form showing its warning), write a small script,
+     `export default async (page) => { await page.getByLabel("Canonical ID").fill("NIKON"); }`,
+     and pass it with `--script`. Keep scripts in a scratch path, not in `proof/`.
+   - Read every capture with the Read tool before recording it. A crisp picture of the
+     wrong screen is still wrong.
    Save artifacts under `<target-dir>/proof/` with names that match the test-case
    rows they prove, and put each on the page with `ticket-page proof`, naming the
    criteria it proves and the mock it answers. A proof cell references its artifact by filename plus "attached"