What it does
pr-description-react-native publishes a React Native 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 simulator screenshot captured with agent-device — 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-react-native— the agent won’t reach for it on its own. - Trigger boundary. Reach for it when a React Native 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 web repos, use pr-description-web instead.
Prerequisites
A booted iOS simulator or Android emulator that agent-device can drive, and the gh CLI authenticated against the repo. Screenshots are captured live from the app, so the branch must actually run.
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 device, same screen, 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 React Native repos specifically; pr-description-web is the same step for web 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.