github-pr-message-writer

Generate GitHub pull request titles, bodies, and review request comments.

2|Updated Jun 18, 2026
One-click install
npx skills add https://github.com/zero-yx/static_flow --skill github-pr-message-writer-zero-yx
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: github-pr-message-writer
Source: https://github.com/zero-yx/static_flow/tree/main/skills/github-pr-message-writer
Command: npx skills add https://github.com/zero-yx/static_flow --skill github-pr-message-writer-zero-yx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing clear, convention-compliant pull request text is repetitive and easy to get wrong, especially when repositories enforce commitlint or semantic PR title checks. This Skill drafts ready-to-paste PR titles, bodies, issue-closing footers, and maintainer ping comments based on a concrete bug fix or feature change. ## Core Features & Use Cases - Convention-aware PR titles: Inspects .github/workflows/ and commitlint configs to decide between Conventional Commits style (fix(scope): subject) and plain prose titles. - Structured PR bodies: Produces Summary, Root cause, What changed, and optional Additional context sections, ending with a properly placed Fixes #123 footer. - Maintainer ping comments: Drafts short, polite review request comments under six lines that state concrete impact. - Use Case: After fixing a production bug in an open-source dependency, ask for a PR message and receive a commitlint-safe title, a concise review-ready body, and a maintainer ping comment you can paste directly into GitHub. ## Quick Start Draft a GitHub PR title and body for my fix that resolves the token refresh race condition, following the repo's conventional commit rules and closing issue #123.

Frequently Asked Questions about github-pr-message-writer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a good GitHub pull request description?▼

Structure the PR body with short Summary, Root cause, and What changed sections that lead with the actual problem solved. Omit routine workflow narration like rebasing or formatting, and place the issue-closing footer such as Fixes #123 at the bottom after a blank line.

How to write a conventional commit PR title for GitHub?▼

Use the format fix(scope): subject or feat(scope): subject when the repository runs commitlint or semantic PR checks. Inspect .github/workflows/ and .commitlintrc config files first to confirm the convention before choosing between a conventional title and plain prose.

Where should the Fixes issue footer go in a PR body?▼

The Fixes #123 footer belongs at the very bottom of the PR body, separated from the preceding content by a blank line. Placing it at the top or inline within sections breaks the expected structure and reduces readability for reviewers.

How do I politely ping a maintainer for a PR review?▼

Keep the review request comment under six lines, be polite and direct, and mention the concrete impact of the issue. State why the review matters now, such as production impact, and include a background link only if it genuinely helps the maintainer.

What should I avoid putting in a pull request body?▼

Avoid long code indexes, file-by-file changelogs, test and rebase narration, and marketing language. Do not hide the actual problem behind generic phrases like improves stability, and link to external write-ups instead of duplicating deep-dive content.