evidence

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.

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".