What it does
pr-description-web publishes a web pull request whose description proves every user-visible change instead of describing it. Each change becomes a numbered scenario that reads as evidence first — a browser screenshot of the running app — then Before and After in plain words, with the technical details and an honest testing method collapsed behind <details> blocks for whoever wants them.
The description and its images live only on GitHub: screenshots upload as user-attachments and the body goes straight onto the PR, so the repo and branch stay screenshot-free.
When to reach for it
- Invocation mode. You invoke this by typing
/pr-description-web— the agent won’t reach for it on its own. - Trigger boundary. Reach for it when a web branch is done and contains changes a user can see. A PR with only internal changes (config, tests, tooling) doesn’t need it — those go in a plain description. For React Native repos, use pr-description-react-native instead.
Prerequisites
The app must run locally (a dev server the agent can start or reach), and the gh CLI must be authenticated against the repo. Screenshots are captured live from the browser with whatever browser-automation tooling the session has — a Playwright or Chrome DevTools MCP, or similar; when none is available the skill recommends agent-browser.
Scenarios, not summaries
The unit of the description is the scenario: one numbered section per user-visible change, classified as Bugfix, Behavior change, or Improvement. Every commit on the branch must be accounted for — by a scenario or by the trailing “Also in this PR” list — and no Testing method may claim validation that didn’t happen. The reviewer gets evidence, not assertions.
A screenshot is evidence, not decoration
A scenario carries an image only when the image proves something: a value, label, or state a reviewer can read off the screen and match against the After text, framed so it’s legible. A change a still can’t show — timing, a crash that no longer happens, a network call, an animation — is carried by words alone. The format leaves room for a screenshot; that room is not a reason to produce one.
Screenshots sit in a centred table with a one-line caption underneath, so an image is always labelled with what it’s showing. When the before state is still reachable and looks visibly different, the table gets two columns and the pair goes side by side — same browser, same viewport size, same data, so the only difference on show is the change itself.
It’s working if
- Every user-visible change on the branch has its own numbered scenario: captioned screenshot, Before, After, then technical details and testing method folded away.
- The screenshot count on the published PR matches the number of scenarios a still could actually prove — no filler images.
git statusis clean afterwards — no description files or screenshots left in the working tree.
Where it fits
This is the ship step of the main flow — the last link, after the work is built and verified, for web repos; pr-description-react-native is the same step for React Native repos. It leans on github-image-upload to turn each screenshot into a user-attachments URL the PR body can reference. For the map of the whole set, see ask-eddy.