Pull request description prompts should help a reviewer understand the final change without reading the conversation that produced it. The useful opening explains a concrete problem and the resulting behavior. File lists and a chronological diary often bury that point. These prompts turn the final diff and actual validation evidence into a focused description, then check it for unsupported claims and missing review context.
Gather the final diff and observed checks
Provide the repository template, the comparison base and the intended behavior. Include the exact tests or manual checks that ran, with their outcomes and any blocked checks. If the task changed direction, state the final scope before asking for a description. An agent that summarizes every intermediate idea may produce a detailed account of work that is no longer present.
GitHub's pull request reference explains how descriptions, changes and checks support review. The drafting prompts here are original editorial guidance. They should describe evidence the repository already contains, not invent validation or claim a reviewer has approved the work.
Draft around the behavior change
A good description begins at the level of the affected user or caller. For a bug, include a short example of the previous and new result when it makes the fix clearer. Mention implementation details only when they explain a tradeoff or tell the reviewer where to focus. Respect a required template without filling every section with repetition.
Draft a PR title and description for {{final_diff}} against {{base_ref}}.
Use {{repository_template}} and this intended behavior: {{behavior}}.
Lead with the concrete problem and resulting behavior. Include a brief
before/after example if useful. Summarize only implementation details that
a reviewer needs. Validation evidence: {{actual_checks}}.
Do not claim unrun tests, deployment or approval. Match detail to scope.
Separate verified results from remaining checks
A local unit test, a production build and a deployed browser check establish different things. Ask the agent to preserve those distinctions. If a service was unavailable, state what could be checked and what remains. Clear limitations help a reviewer decide the next action without having to decode a blanket tests-pass statement.
Review the validation section of {{pr_draft}} against {{check_evidence}}.
Identify claims that exceed the evidence. Rewrite it with concise actual
results and material gaps. Explain any relevant fixture or environment
limit. Keep commands only when they help reproduction. Do not convert a
proposed check into a completed one or hide a known failing required check.
Rewrite after the implementation changes
The final diff may solve a narrower problem than the original plan, or include an additional necessary change. Ask the agent to reassess the title and description from the result. Keep abandoned approaches only when they explain a real tradeoff. A reviewer should not have to determine which paragraph describes the current implementation.
Rewrite {{existing_pr_description}} using {{final_diff}} and {{final_scope}}.
Remove stale claims, abandoned implementation details and conversational
history. Preserve relevant tradeoffs and verified checks.
Flag any behavior in the diff that the description fails to explain.
Return the final title and body, then a short list of unresolved questions
only if they materially affect review.
Read the draft as someone new to the work
Can the reviewer explain what triggers the change and what happens now? Can they identify a migration, permission change or compatibility concern without searching the chat? Check that the body does not repeat the diff mechanically. For a small fix, remove paragraphs that do not help assess correctness or scope.
Save your preferred PR writing prompt in Kipt with variables for template, final scope and validation. Pair it with the code review prompts when you also want a separate review of the implementation itself.