create-pr

jMerta's avatarfrom jMerta

Create a high-quality pull request: branch, focused changes, lint/build, conventional commit, and a clear PR description with validation steps. Use when the user asks to open or prepare a PR.

⭐90stars🔀6forks📁View on GitHub🕐Updated Jan 2, 2026
[Developer Tools]

When & Why to Use This Skill

This Claude skill automates the end-to-end process of creating high-quality, review-ready Pull Requests. It streamlines the software development lifecycle by handling branch creation, enforcing conventional commit standards, running local quality gates (lint/build), and generating comprehensive PR descriptions via the GitHub CLI. It is designed to improve developer productivity and ensure code consistency across repositories.

Use Cases

  • 1. Automated PR Workflow: Quickly transition from local code changes to a structured Pull Request with automated branch naming and standardized descriptions.
  • 2. Quality Gate Enforcement: Automatically run linting, testing, and build scripts before submission to ensure only 'green' code reaches the review stage.
  • 3. Standardizing Team Contributions: Enforce the use of Conventional Commits and specific PR templates to maintain a clean and searchable project history.
  • 4. GitHub CLI Integration: Seamlessly manage PR creation, status checks, and authentication using the 'gh' tool directly within the agentic workflow.
namecreate-pr
description"Create a high-quality pull request: branch, focused changes, lint/build, conventional commit, and a clear PR description with validation steps. Use when the user asks to open or prepare a PR."

Create a PR

Goal

Produce a PR that’s easy to review and safe to merge:

  • small, scoped changes
  • green checks (lint/tests/build as appropriate)
  • clear description + validation steps

Workflow (checklist)

  1. Confirm scope
    • Restate the goal and acceptance criteria.
    • Identify files likely to change; avoid unrelated cleanup.
  2. Create a branch
    • Use a descriptive name: fix/<topic>, feat/<topic>, chore/<topic>.
  3. Implement changes
    • Keep diffs focused; prefer small commits.
  4. Run quality gates
    • Run the repo’s standard commands (lint/tests/build).
    • If bun.lock exists, prefer bun lint / bun build.
    • If bun.lock exists but bun is not available, tell the user and ask whether to install bun or use the repo’s alternative package manager.
  5. Commit
    • Prefer Conventional Commits: fix: ..., feat: ..., chore: ....
  6. Push + open PR
    • Always use GitHub CLI (gh) for PR workflows (e.g. gh pr create --fill).
    • If gh is not authenticated, run gh auth login (or gh auth status to check).
    • If gh is not installed or cannot be authenticated, tell the user and ask whether to install/authenticate or proceed with manual PR creation steps.
  7. Fill in PR body
    • Use references/pr-description-template.md.

Notes

  • Don't force-push unless you're sure it's safe for collaborators.
  • If the PR changes UX, include screenshots or a short GIF.
  • Prefer gh for create/view/checks (e.g. gh pr view, gh pr checks).

Deliverable

Provide:

  • Branch name and PR URL (or the exact steps to open it manually).
  • PR title/body (using references/pr-description-template.md).
  • Commits included and verification commands run.
  • Screenshots/GIFs if UX changed.