Pull request descriptions
Write for maintainers who need to understand the change and why it belongs in this repository without reading a second version of the diff.
Drafting
- Read the complete diff against the pull request's base branch. Read linked issues when they explain requirements or decisions that the diff does not.
- Start from .github/PULL_REQUEST_TEMPLATE.md. Keep its required sections and checklist, but delete all instructional comments.
- Open
Description with one or two short sentences that state what changes and why it matters. Do not repeat the title.
- In
Motivation, name the user journey or decision the telemetry supports and cite relevant prior art. Do not use this section to repeat the implementation.
- In
Prototype, point to the reference scenarios or other end-to-end evidence. Explain only gaps or constraints that a reviewer cannot infer from the diff.
- Keep checklist answers accurate. Do not add validation commands, a changed-files list, or extra boilerplate sections.
- Add a concrete example near the top only when it explains a new public convention, compatibility concern, or migration. Keep it to the smallest example that makes the behavior clear.
- Preserve issue-closing references, compatibility notes, risks, and design constraints that reviewers need.
For repository-only changes where a template section does not apply, use one short N/A sentence rather than inventing justification.
Compression pass
Treat the first draft as raw material, then shorten it.
- Remove details visible from the diff, including file names and exhaustive lists of attributes.
- Remove chronological narration, review history, and arguments already settled in a linked issue.
- Remove repeated context across sections.
- Replace long paragraphs with one or two sentences. Use bullets only for genuinely parallel facts.
- Remove generic sections such as
Summary, Changes, Details, Testing, and Validation.
- Keep the body as short as the change allows. There is no target word count.
- Do not hard-wrap prose.
Before creating or updating the pull request:
- Apply the repository's unslop skill to the complete title and body.
- Compare the result with the diff once more. Every sentence must help a reviewer understand the purpose, user-visible behavior, compatibility, risk, or a decision that the diff cannot explain by itself.
1---2name: pr-description3description: Write or edit concise pull request descriptions for this repository. Use whenever drafting, creating, opening, or updating a pull request, or when reviewing whether a pull request description matches its diff.4---56# Pull request descriptions78Write for maintainers who need to understand the change and why it belongs in this repository without reading a second version of the diff.910## Drafting11121. Read the complete diff against the pull request's base branch. Read linked issues when they explain requirements or decisions that the diff does not.132. Start from [.github/PULL_REQUEST_TEMPLATE.md](../../PULL_REQUEST_TEMPLATE.md). Keep its required sections and checklist, but delete all instructional comments.143. Open `Description` with one or two short sentences that state what changes and why it matters. Do not repeat the title.154. In `Motivation`, name the user journey or decision the telemetry supports and cite relevant prior art. Do not use this section to repeat the implementation.165. In `Prototype`, point to the reference scenarios or other end-to-end evidence. Explain only gaps or constraints that a reviewer cannot infer from the diff.176. Keep checklist answers accurate. Do not add validation commands, a changed-files list, or extra boilerplate sections.187. Add a concrete example near the top only when it explains a new public convention, compatibility concern, or migration. Keep it to the smallest example that makes the behavior clear.198. Preserve issue-closing references, compatibility notes, risks, and design constraints that reviewers need.2021For repository-only changes where a template section does not apply, use one short `N/A` sentence rather than inventing justification.2223## Compression pass2425Treat the first draft as raw material, then shorten it.2627- Remove details visible from the diff, including file names and exhaustive lists of attributes.28- Remove chronological narration, review history, and arguments already settled in a linked issue.29- Remove repeated context across sections.30- Replace long paragraphs with one or two sentences. Use bullets only for genuinely parallel facts.31- Remove generic sections such as `Summary`, `Changes`, `Details`, `Testing`, and `Validation`.32- Keep the body as short as the change allows. There is no target word count.33- Do not hard-wrap prose.3435Before creating or updating the pull request:36371. Apply the repository's [unslop skill](../unslop/SKILL.md) to the complete title and body.382. Compare the result with the diff once more. Every sentence must help a reviewer understand the purpose, user-visible behavior, compatibility, risk, or a decision that the diff cannot explain by itself.