---
name: evidence
description: >-
  Produce visual PR evidence — a screenshot or video — whenever a change has
  on-screen impact. Tests are never a substitute; a change can be backend by
  cause and visible by effect. Capture via the project's e2e harness on a pu
  box, or by driving a live kolu with the chrome-devtools MCP; host on a GitHub
  release and post a `## Evidence` comment. Triggers on "post evidence",
  "screenshot the change", "record a video of this", "show it working", "prove
  it", or finishing any change whose effect is visible on screen.
---

# evidence — PR screenshots & video

## The gate — answer this first

> If someone exercised what this change affects, would the screen look
> DIFFERENT — before vs. after?

- **YES → a visual artifact is mandatory.** Static (end-state, single moment,
  before↔after) → **screenshot**. Motion (transition, flow, live update,
  animation) → **video**. A value-over-time element — a running timer, live
  counter, anything whose *job* is to change on its own — is motion: a frozen
  clock and a live one are pixel-identical in one frame, so watch it tick.
  A screenshot is a complete deliverable, not a runner-up to video.
- **NO → skip with one explicit PR line: `No visual impact: <why>.`** Silent
  skips are not allowed; neither is manufacturing a tenuous pixel for a change
  whose screen truly doesn't differ.

Excuses that don't hold (each was tried on a real PR and rejected):

- **"Backend change, no UI surface."** Backend by cause can be visible by
  effect — trace the effect to the screen, not the cause to a layer.
- **"No scenario exercises it."** That decides *how* you capture, never
  *whether*.
- **"It's a CLI/TUI — here's a transcript."** A terminal is an on-screen
  surface, and a pasted transcript is not a visual artifact. Record the real
  binary with vhs/asciinema.
- **"The tests prove it."** Tests accompany the artifact, never replace it.
- **"I reconstructed the output — close enough."** A synthesized artifact
  (formatter output posted as a recording, mocked data, a stub's clip) is a
  fabrication, and it hides the very bug evidence exists to expose. The
  artifact comes from really executing the change end-to-end against real
  data — and read the real output to confirm the feature works before posting.

## Capture

Runs on an ephemeral **pu box** (see the pu skill), never locally, so evidence
reflects a clean CI-like build of the PR's commit.

**Prefer the existing Cucumber + Playwright e2e harness** — `KOLU_EVIDENCE=1`
turns on video recording (see `packages/tests/support/hooks.ts`) and you select
a scenario by name. It's the default because the clip comes from the same code
CI runs. The one thing to avoid building is a *parallel capture harness* that
duplicates the step library; everything else is fair game when the harness
can't reach the state: pull a still from a recorded clip, drive a live kolu
with the chrome-devtools MCP and `take_screenshot`, `vhs` for a TUI, ordinary
shell setup for on-disk preconditions. Never skip for lack of a canned path.

**Delegate capture to a subagent** so the main context stays clear: brief it
with the box, branch, image-or-video, the scenario or live state, a `<slug>`,
the PR number, and the release tag; it returns the markdown it posted.

Commands, harness details, transcode settings, and vhs gotchas:
**[CAPTURE.md](CAPTURE.md)**.

## Host & post

- **`evidence-assets` is the one fixed release tag.** It already exists; verify
  it does, never create another, never derive a tag from the PR number.
- **The local filename IS the asset name** — copy back as `/tmp/<slug>.png`,
  not a decorated name, or every `…/download/evidence-assets/<slug>.png` embed
  404s.
- GIF embeds inline (keep under GitHub's ~10 MB limit); MP4 links via the
  shared player (`juspay.github.io/video-evidence`). PNG embeds like a GIF.
- Use a single-quoted heredoc when posting so backticks and `$` survive.
- **Tear the box down** when finished: `pu destroy "$host"`.