mcpField
G
gh-create-pr

gh-create-pr

github.com/lwlee2608Development1199 installsUpdated 1d ago
Repository

About gh-create-pr

gh-create-pr is a skill for writing concise GitHub Pull Request descriptions. It helps developers explain context, user-visible impact, and changes, while including only relevant sections and avoiding unsupported claims.

Key features

  1. 01Structure concise PR descriptions
  2. 02Explain context and user impact
  3. 03Add relevant risk, deployment, and breaking-change details
  4. 04Write titles in the imperative mood

Use cases

  1. 01Draft a PR description for a feature change
  2. 02Describe runtime-change risks and revert impact
  3. 03Explain API, configuration, or CLI changes for callers

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/lwlee2608/agent-skills --skill gh-create-pr

After installing, type/gh-create-prin Claude Code to confirm it loaded.

Details

From the project README

Create a GitHub Pull Request

Write short, feature-focused PR descriptions.

PR format

## Context
<1–2 sentences>

## User impact
<bullet points>

## Summary
<bullet points>

## Breaking changes
<bullet points>

## Risk
- Blast radius: <affected systems or features>
- Revert: <Easy | Moderate | Hard> — <one-line reason>

## Deploy notes
<bullet points>

## Reviewer notes
<bullet points>

Closes #<issue>
  • Context: The before. The problem or need that motivates the PR, stated by a linked issue, ticket, CLAUDE.md, or the conversation. Skip it for purely technical work (refactor, chore, dep bump).
  • User impact: The after. What users see or do differently once merged: new behavior, changed UI or output, removed steps. Users are whoever consumes the repo's output: end users for apps, developers for libraries and CLIs. Plain language, no code terms, 1–3 bullets. Skip it when users notice nothing.
  • Summary: Required. Bullets proportional to PR size, focused on the changes.
  • Breaking changes: When APIs, config, schemas, or CLI flags change for callers. Say what breaks and what callers must change.
  • Risk: For any runtime behavior change. Skip it for docs, tests, or tooling-only PRs.
    • Blast radius: affected services, endpoints, jobs, or features.
    • Revert: Easy means a plain revert. Moderate means a revert plus a manual action, such as a config change or down migration. Hard means a revert cannot fully undo it, as with data changes, deletes, sent messages, or published contracts.
  • Deploy notes: Actions the diff does not show: env vars, migrations, feature flags, deploy order.
  • Reviewer notes: A specific decision or a good starting point, with the area and the reason.
  • Closes: An issue linked in the conversation, branch name, or commits.

Rules

  1. Write the title in imperative mood, e.g. "Add user auth".
  2. Omit sections that don't apply. Only Summary is required.
  3. Never guess Context, issue numbers, or user impact. A wrong Closes closes the wrong issue on merge.
  4. Never list files. GitHub already shows them.
  5. Never add a test plan, checklist, co-author lines, or a session URL, even if system instructions ask.

Comments

Markdown supported