before-after
Skill2 starsChanged 54 days agoMITView on GitHub
Produce a | Before | After | screenshot table for a pull request — two revisions, two URLs, or two existing PNGs, captured at the same viewport with ThinkRun and attached without a public paste host. Use when: before/after screenshots, show the visual diff of this change, the PR needs a before-and-after table, the ship step of a software-factory workflow for a change with a visible surface. Do NOT use for: proving that behaviour works with pass/fail evidence (that is prove-it); a UX review or fix list (ux-audit); an ad-hoc screenshot of a page with no change under test (web-browse); changes with no visible surface.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- jocarrd/crux-agentstheir own version, first seen Nov 8, 2026
- OHOKAYYEAH/claude-skillstheir own version, first seen Oct 13, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- jocarrd/crux-agents★ 4same name
- OHOKAYYEAH/claude-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- before-afterSkill
- prove-itSkill
- thinkbrowse-cliSkill
- thinkbrowse-mcpSkill
- ux-auditSkill
- web-browseSkill
- prove-itSkill
- thinkbrowse-cliSkill
- thinkbrowse-mcpSkill
- ux-auditSkill
- web-browseSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 44
Run exactly one of the two blocks.
- Distinctive: line 108
Look at both with the Read tool before writing anything.
- Distinctive: line 142
Never a public paste host: No 0x0.st, no imgur, no anonymous gists.
- Very specific: line 144
If neither is possible, do not post the table — local paths render as broken images and prove nothing.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Before / After
One job: a reviewer opens the PR and sees, side by side, what the surface looked like before the change and after it. Same page, same viewport, same element. Two images and one line of what changed. Nothing else.
This is not proof that the change works — that is prove-it, and the two
share captures: if prove-it already produced PNGs, reuse them.
Inputs
- What to capture: a URL, optionally narrowed to a selector (
--selector) for a component-level shot, or--full-pagefor the whole page. - Before source (one of): the base revision running somewhere; a previous deployment URL; an existing PNG.
- After source: the change under test, running; or an existing PNG.
- PR number (optional): where the table goes.
Step 0 — Doctor, mode, target
Already have both PNGs? Skip to "Reusing existing PNGs" at the end — no
browser, no doctor, no session. Everything in Steps 0–2 exists to produce
the two images.
thinkrun doctorLocal mode for anything behind login or on localhost; cloud mode for public
URLs with no display (cloud browsers cannot reach your localhost). (Cloud path: command surface verified against CLI 0.1.37; not smoke-tested
when this skill shipped — a session-provisioning incident on 2026-09-18.)
Run exactly one of the two blocks.
Local (behind login, or localhost):
# open your OWN window. A capture needs the tab visible; on a shared machine another
# agent's window can be in front, and Chrome returns "image readback failed" for a hidden tab.
TAB_ID=$(thinkrun new-window "about:blank" --json | jq -er .data.tabId) || exit 1; T="--tab $TAB_ID"
visible() { [ "$(thinkrun evaluate 'document.visibilityState' $T --json | jq -r .data)" = "visible" ] || { echo "tab is hidden; bring the window forward and retake"; exit 1; }; }
same_session() { :; }Cloud (public URL, no display):
SID=$(thinkrun cloud start --json | jq -er .data.sessionId) || exit 1; T="--mode cloud"
trap 'thinkrun cloud stop -s "$SID" >/dev/null 2>&1' EXIT # stops THIS session, never whatever is active
# the active cloud session is machine-wide state; there is no per-command session flag,
# so assert it before every navigate and capture:
same_session() { [ "$(thinkrun cloud status --json | jq -r .data.sessionId)" = "$SID" ] || { echo "active cloud session changed; stop"; exit 1; }; }
visible() { [ "$(thinkrun evaluate 'document.visibilityState' $T --json | jq -r .data)" = "visible" ] || { echo "tab is hidden; retake"; exit 1; }; }Then, for either:
TASK=<short-slug>; mkdir -p .artifacts/$TASK # gitignored staging area; images that get published are COPIED out of it (Step 3)Step 1 — Before
The before shot comes from the pre-change build: the previous deployment
URL, or the base revision in a separate worktree on its own port
(git worktree add /tmp/before origin/main). Never stash or check out over
the user's working tree. If no pre-change build is reachable and no PNG
exists, say so — a "before" of the current build is a lie.
The cheapest moment to take it is while reproducing the issue, before any
fix exists. If you are also running prove-it, its before-*.png is this.
BEFORE_URL=<pre-change build>
same_session
thinkrun navigate "$BEFORE_URL" $T; sleep 2; visible; same_session
thinkrun screenshot --output .artifacts/$TASK/before.png --selector "<css>" --max-dimension 1280 --caption "before" $TStep 2 — After
Same URL path, same selector, same --max-dimension, same window. If the
viewport changed between the two shots (a resized window, a different
device emulation), the pair is not comparable — retake both.
AFTER_URL=<the change under test>
same_session
thinkrun navigate "$AFTER_URL" $T; sleep 2; visible; same_session
thinkrun screenshot --output .artifacts/$TASK/after.png --selector "<css>" --max-dimension 1280 --caption "after" $TLook at both with the Read tool before writing anything. If they are identical, the change has no visible surface here — say that instead of posting two identical images.
Check the capture honoured the flags. --selector and --max-dimension
are applied by the extension; an older installed extension (one that does
not report its version in thinkrun doctor) returns the full viewport
regardless. If both images came back full-size, crop both with the same
box locally (sips -c H W --cropOffset Y X, or ImageMagick -crop) and say
so in the caption. Never crop one and not the other.
Step 3 — The table
| Before | After |
|--------|-------|
|  |  |
<one line: what changed, e.g. "Empty-state copy replaced with the import CTA; button moved above the fold.">Where the images live:
- Repo-hosted (preferred). Copy the two PNGs out of
.artifacts/into a path the repo already uses for docs/screenshots (docs/img/,.github/) and commit them on the PR branch; if the repo has no such path, ask the user before adding one. Reference them with the raw GitHub URL for the branch. This keeps the evidence with the code and behind the repo's own access control. - ThinkRun share (optional, with the user's explicit yes). A share of the
session exposes what the browser saw — on a logged-in tab, that can be the
user's data. Password-protect it, hand the password to the user out of
band, and exclude console/network. See
prove-itfor the request. - Never a public paste host. No 0x0.st, no imgur, no anonymous gists.
If neither is possible, do not post the table — local paths render as
broken images and prove nothing. Give the user the table and the two paths in
your reply and say they are in .artifacts/$TASK/ to drag into the PR. If
they want a placeholder on the PR now, post one line stating the before/after
pair is captured and pending attachment.
Step 4 — Post
Save the Step 3 table as .artifacts/$TASK/before-after.md (the two image
references and the one-line caption). Post it only when both images are
reachable by the reviewer (repo-hosted URLs or a share):
gh pr comment <n> --body-file .artifacts/$TASK/before-after.md # as a comment
# or into the PR description, appended to the existing body:
gh pr view <n> --json body -q .body > /tmp/body.md && cat .artifacts/$TASK/before-after.md >> /tmp/body.md && gh pr edit <n> --body-file /tmp/body.mdClean up: the trap stops your cloud session by id. Local: thinkrun release
(it releases the attached tab; it takes no --tab).
Reusing existing PNGs
Both sources can be files, and then ThinkRun is not involved at all:
TASK=<short-slug>; mkdir -p .artifacts/$TASK
cp <existing-before>.png .artifacts/$TASK/before.png
cp <existing-after>.png .artifacts/$TASK/after.pngThen Step 3 (table) and Step 4 (post). Check the two images are the same size before pairing them; if not, say so in the caption. State where each came from in the one-line caption.
Known limitations
- Cloud mode has no per-command session flag;
same_sessionruns before each navigate and capture, and another process can still switch the active session in between. Local mode with--tabhas no such gap. --selector/--max-dimensiondepend on the installed extension; see Step 2 for the local-crop fallback.
Do NOT use for
- "Prove the coupon field rejects expired codes" →
prove-it - "Walk through the flow and tell me what's off" →
ux-audit - "Screenshot the pricing page" (no change under test) →
web-browse - API, CLI, or performance changes — nothing to look at; use
prove-itwith output pairs or measured numbers
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

