What it does
pr-description publishes a pull request whose description is reconstructed from two witnesses: the diff — what changed — and the thread, the session that produced the branch — why it changed, what was decided, what was traded away. Every claim in the body must be traceable to one of the two; the skill runs nothing, drives nothing, and captures nothing to produce it, which is what makes it work in any repo on any stack.
User-visible changes become numbered Before/After scenarios in plain words; internal work goes in a trailing list — or gets promoted to Internal scenarios when the branch has no visible change at all. Each scenario folds its technical details and an honest validation note behind <details>, and “not validated” is a valid note.
When to reach for it
- Invocation mode. You invoke this by typing
/pr-description— the agent won’t reach for it on its own. - Trigger boundary. Reach for it when a branch is done and needs a description, whatever the stack and whether or not the work touches UI. When the changes are visual and a screenshot would prove them, use the variant with evidence capture instead: pr-description-react-native for React Native repos, pr-description-web for web repos.
Prerequisites
The gh CLI must be authenticated against the repo. Nothing else — no dev server, no simulator, no browser tooling.
Two witnesses, no fabrication
The diff can say what changed but never why; the thread can say why but drifts from what actually landed. The skill forces each half to come from the source that can vouch for it, and forbids anything neither can — that’s the whole defence against the confident-but-invented PR description. The Validation block is the sharpest edge of this: it reports only what the thread shows was checked, so it can never claim testing that didn’t happen.
It’s working if
- Every commit on the branch is accounted for — by a scenario or the “Also in this PR” list.
- Each scenario’s why traces to the thread and its Before/After traces to the diff.
- No Validation block claims checking the session didn’t do.
git statusis clean afterwards — the body lives only on GitHub.
Where it fits
This is the ship step of the main flow — the last link, after the work is built — and the stack-agnostic default among three siblings: pr-description-react-native and pr-description-web do the same job where a screenshot can serve as evidence, because they can drive the running app. For the map of the whole set, see ask-eddy.