| name | ui-evidence |
| description | Produce visual proof of a UI change and post it to the pull request — "before" screenshots captured while the code is still untouched, a recorded GIF of the changed flow, matching "after" screenshots, and the private-repo browser-upload dance to attach them as a PR comment. Use whenever a change touches anything a user can see or click (components, pages, styles, client-side behavior) and a reviewer needs visual evidence, or when the user asks to "record a GIF of this change", "take before/after screenshots", or "post the screenshots to the PR". |
UI Evidence — before/after screenshots and a verification GIF
Reviewers weigh a before/after pair far more than a description of what
changed, and the GIF comment is what tells them "this needs your visual
sign-off". For any user-visible change this evidence is mandatory, not
decorative.
Chrome is a single shared resource — never delegate it. All browser
steps here (screenshots, GIF recording, uploads) run in the main agent via
the claude-in-chrome tools; parallel subagents fighting over one browser
serialize badly and corrupt each other's recordings. If several tasks need
Chrome, queue their browser steps and do them one at a time at the end.
1. Before-captures — do this BEFORE touching the code
The only moment the "before" state exists is before implementation — once
the change lands, it's gone. As soon as it's known that a change touches UI:
- Start (or find) the locally running app — check for a
run skill or repo
docs for the start command and local URL/basePath conventions.
- Open the affected screen(s) in Chrome and screenshot each
(
mcp__claude-in-chrome__computer, screenshot action), saved as
issue-<N>-before-<screen>.png (or before-<screen>.png if there's no
issue number).
- If the local app isn't running and starting it is disruptive right now,
note that "before" captures were skipped and why — don't silently drop
them.
2. Verification GIF + after-shots — after implementing
- Drive the changed flow end-to-end in the running app (the
verify skill
covers how to exercise it; this skill covers how to record it).
- Record the drive with
mcp__claude-in-chrome__gif_creator: start capture
before the first action, capture extra frames before and after each
step so playback is smooth, and name the file after the work (e.g.
issue-<N>-verification.gif). Save it somewhere durable and note the
path.
- Take "after" screenshots of the same screens captured in step 1
(
issue-<N>-after-<screen>.png) so the PR can show matched before/after
pairs — same screen, same viewport, ideally same scroll position.
3. Posting to the PR
How the media gets attached depends on repo visibility — check
gh repo view --json isPrivate:
- Private repo: raw file links won't render for other viewers;
attachments must be uploaded as real comment attachments, which only works
through the browser. Open the PR page in Chrome, attach the before shots,
after shots, and GIF in the comment box with
mcp__claude-in-chrome__file_upload, then submit.
- Public repo: embed the images/GIF directly in the PR body or a
gh pr comment markdown body via a hosted path, whichever is simpler —
the browser dance exists only to work around private-repo restrictions.
Comment text, either way: label each image (Before / After / Flow
recording), one or two sentences on what flow the GIF shows, and that the
reviewer should visually verify it before merging. Write it for the
reviewer, in normal full-sentence English.
Fallback
If the Chrome extension isn't available or the upload fails twice, don't
spin: post a text comment saying the verification media exists, and give
the user the local file paths so they can drag-drop the files themselves.
