Run It
1
Start from the branch you want described
In Claude Code, with the branch checked out:The issue number is optional. When you supply one, PRFlow adds
Resolves #123 and reads that issue for context.A cloud install also answers a bare /prflow:pr-description comment on the pull request, but that run starts on the default branch, not the pull request’s branch, so it does not update the body. Run the command locally on the branch instead.2
Check the result
If the branch already has a pull request, its body is updated in place. If it does not, the full description is printed for you to paste when you open one. If PRFlow cannot tell whether the branch has a pull request, for example because
gh is not signed in or HEAD is detached, it reports why and leaves the pull request body unchanged.What Gets Written
The generated body uses a fixed set of sections:## Visual Changes and ## Breaking Changes are added when the diff calls for them.
What PRFlow Reads
PRFlow compares the current branch against the base branch and reads the commit history, the diff summary and the detailed diff. When the branch came from an implement run, it also carries that run’s post-merge verification items into the body.Refreshing an Existing Body
Regenerated every run, from the current diff: Summary, Changes, Visual Changes and Breaking Changes. Post-Merge Verification is rebuilt from the implement run’s workpad. When the workpad read fails, the existing section is kept instead of being dropped. The run’s final message reports the lookup outcome:read with its post-merge row count, no-workpad, no-issue or failed.
Deferred Findings is rebuilt from the review deferral manifest, and entries whose manifest is absent are carried forward from the existing body.
Your own content survives:
- Test Plan items you added stay, as long as they still apply. Items for changes that no longer exist are removed.
- Existing issue links stay alongside a newly supplied issue number.
- Custom sections such as Reviewer Notes or Deploy Steps keep their position.
- Anything outside PRFlow’s body markers stays outside them.
- A body with no markers at all is preserved above the newly generated section rather than replaced.
Scope-Acknowledged Findings
A scope-acknowledged finding is a real review finding the team decided not to fix in this pull request. It appears in the## Deferred Findings section as a table: the severity, the file, a one-line summary and the follow-up issue that now owns it.
This is a disclosure, not a dismissal. It exists so a reviewer reading the pull request can see what was consciously left undone, and so a later review can show which current finding each deferral covers. A deferral never lowers a finding’s weight.
One kind of deferral has no follow-up issue: a finding settled by disclosure, where writing the caveat down is the deliverable. Those rows cite the document that carries the disclosure instead of an issue number, and a later review re-checks that the document still says it.
Because a settled-by-disclosure entry has no follow-up issue, the pull request body is its only durable record. PRFlow therefore never wipes an existing Deferred Findings block when it regenerates a body — it merges rather than overwrites.
**Documentation Needed** list already names the file a finding was raised against as a file to edit, that run is already due to edit the file, so PRFlow files no follow-up issue and writes no Deferred Findings row or hidden payload entry for it — and removes one an earlier pass wrote. Every row you read in that table is work genuinely left undone.