GitHub PR Message Writer

Use this skill to generate PR-facing text that is ready to paste into GitHub with minimal cleanup.

Default outputs:

1. Suggested PR title
2. PR body
3. Optional maintainer ping comment if the user asks

Core Goals

• Make the PR easy for maintainers to review quickly.
• Preserve the real bug / change scope.
• Avoid boilerplate status noise unless the user explicitly wants it.
• Keep the text compatible with repo-specific PR title or commitlint checks when possible.

First Checks

If the target repo exists locally, inspect these before drafting:

• .github/workflows/ for PR title / semantic PR / commitlint checks
• .commitlintrc* or equivalent lint config
• contributing docs if they define PR title conventions

If the repo lints PR title + body as a merge commit message:

• output a Conventional Commits style title
• do not use a plain prose title
• put Fixes #123 or similar issue-closing footer at the end of the PR body
• ensure there is a blank line before the footer

Writing Rules

1. Lead with the actual problem solved.
2. Explain root cause only as far as needed for review.
3. Summarize what changed in a few bullets.
4. Omit routine workflow narration such as rebasing, formatting, or CI basics unless the user asks.
5. Do not inflate the PR body into a deep-dive article unless the user explicitly wants that.
6. If the user has a public write-up or blog post, link it as optional background instead of duplicating everything.
7. If the user asks to mention production impact or deployment evidence, include it briefly near the end.
8. If the user asks to mention AI assistance, keep it short and place it near the end, before any issue-closing footer.

Default Structure

Use this structure unless the user requests a different format:

Suggested PR title

• One line only
• Prefer fix(scope): subject / feat(scope): subject when repo conventions suggest it

PR body

Use short sections:

1. Summary
2. Root cause
3. What changed
4. Additional context only if it adds value
5. Final short note if requested
6. Blank line
7. Fixes #123

What To Avoid

• Long code indexes in PR bodies
• File-by-file changelogs unless specifically requested
• Test / rebase / formatting narration as filler
• Marketing language
• Hiding the actual problem behind generic phrases like "improves stability"

Reviewer Ping Comments

When the user asks for a maintainer ping / review request comment:

• keep it under 6 lines
• be polite and direct
• mention concrete impact
• say why the review matters now
• include a background link only if it truly helps

Template:

@maintainer could you take a look at this PR when you have a chance?

This issue is currently affecting my normal use of X in production, so I would really appreciate a review when convenient.

Thanks.

Conventional-Commit-Friendly Pattern

If commitlint or semantic PR checks are present, default to:

Title:

fix(scope): concise subject

Body pattern:

## Summary

Short problem statement.

## Root cause

Short explanation.

## What changed

- change 1
- change 2

## Additional context

- optional link

Requested final note if any.

Fixes #123

Important:

• Fixes #123 belongs at the bottom, not the top
• leave a blank line before the footer
• do not reuse a prose heading as the PR title if the repo expects conventional commits

Output Style

When generating the result, prefer:

• one fenced block for Suggested PR title
• one fenced block for PR body
• one fenced block for Review request comment if requested

Keep each block ready to paste without further explanation unless the user asks for alternatives.