pr-comment

name	pr-comment
description	Use when the user asks to write, draft, summarize, or compose a pull request description or change summary. Covers reviewer-facing PR bodies, strict Summary plus Key Changes formatting, and issue-closing keywords when the linked issue is known.

PR Comment

This skill writes PR descriptions and change summaries for reviewers. It does not handle inline review replies or generic issue comments.

Output rules

• Output only one fenced markdown block.
• Use ## Summary and ## Key Changes.
• Include issue-closing text like Closes #43 when appropriate and known.
• Do not add prose before or after the fenced block.
• Keep the write-up concise and copy-paste ready.

Apply this skill when

• the user says "write a PR", "draft a PR", "summarize this PR", or "describe this diff"
• the user wants a reviewer-facing change summary
• the user shares a diff or changed files and wants a polished PR body

Goals

1. Tell the reviewer what changed in user-visible terms.
2. Explain why the diff exists, especially the root cause.
3. Group the key changes without dumping a file-by-file changelog.
4. Include issue-closing language when there is a linked issue.

Format

## Summary

<one short paragraph, usually 2-4 sentences>

## Key Changes

<1-3 bullets for a small change, or grouped bullets by area for a larger one>

Closes #<issue>

## Summary

The summary should cover:

• what changed
• where it changed
• why it changed

Lead with the user-visible surface or workflow. Include the root cause when it helps the reviewer understand why the diff exists.

## Key Changes

• Small change: use 1-3 bullets total.
• Multi-area change: group bullets by area with a plain label line such as Registry: or Docs:.
• Name specific symbols, files, commands, or surfaces only when that increases reviewer understanding.
• Do not restate the summary or enumerate every touched file.

Style rules

• Backticks for file paths, commands, symbols, and config keys.
• Prefer direct reviewer-facing language.
• Keep the body tight; cut preamble like "This PR" or "In this change".
• Use root-cause framing when it clarifies a bug fix.
• Ground claims in the visible diff or in user-provided context.

Issue-closing rules

• If the linked issue is known and the change resolves it, include a closing line such as Closes #43.
• If issue linkage is ambiguous, leave it out unless the user asked for it.
• Put the closing line at the end of the markdown block.

Ask only if needed

If the user gave a diff but not enough context, ask at most once for:

• the main user-visible surface affected
• whether an issue number should be closed

If the user already explained the change well enough, write immediately.