PR Description

Write a pull request description for a reviewer who knows the project but hasn't read the issue, the diff, or the development conversation. Establish why the change exists before explaining how it works.

If the user asks for a draft, return the text without updating GitHub. Otherwise, update the requested PR description.

Arguments

/pr-description <PR_NUMBER> [--fixes <ISSUE_NUMBERS>]

• PR_NUMBER (required): The pull request to describe.
• --fixes (optional): Comma-separated issue numbers this PR fixes, such as 123,456.

Examples:

• /pr-description 3534
• /pr-description 3534 --fixes 123,456

Instructions

1. Gather the change:

   • Read the PR title, current description, base branch, and head branch.
   • Read the PR commits and diff. Use the PR's actual base and head; don't assume the current checkout is the PR branch or that its base is main.
   • Read relevant issue details, code comments, and available conversation context to understand the problem and the reasons for the change.
   • Collect issue numbers from --fixes and explicit closing references in commit messages. Don't infer that a related issue should be closed.

2. Check the existing description. If it's already accurate, understandable without outside context, and consistent with this format, leave it alone. Otherwise, rewrite it around the final implementation rather than appending updates.

3. Establish the core explanation before choosing bullets:

   • What does the affected component do?
   • What limitation or need prompted this change?
   • What will it do differently? Use only the context needed to understand this PR. Don't invent a problem to justify a feature or refactor.

4. Choose the distinct concerns a reviewer needs to assess. Usually these become 3 to 6 labeled bullets; use fewer for a small change. Group by behavior or system responsibility, not by file, helper function, or implementation step.