pr

Creates GitHub pull requests following conventional commits, draft PR structure, and Slack notification conventions.

Updated Jul 17, 2026
One-click install
npx skills add https://github.com/guneysol/agent-configs --skill pr-guneysol
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pr
Source: https://github.com/guneysol/agent-configs/tree/main/agents/skills/pr
Command: npx skills add https://github.com/guneysol/agent-configs --skill pr-guneysol

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Creating pull requests often leads to inconsistent commit messages, unscoped staging, missing context for reviewers, and forgotten team notifications. This Skill enforces a repeatable PR workflow so every pull request follows the same conventions for staging, committing, pushing, description formatting, and team communication. ## Core Features & Use Cases - Scoped Staging and Conventional Commits: Stages only changes belonging to the PR and commits with type(scope): description messages using types like feat, fix, refactor, docs, test, and chore. - Structured Draft PR Creation: Uses gh pr create to open draft PRs with a title matching the commit message and a body organized into Why, Changes, and Test plan sections, with no tool attribution. - Slack Follow-Up Message: Generates a casual Slack ping summarizing the PR so teammates are notified immediately after creation. - Use Case: After finishing a bug fix on a feature branch, invoke the Skill to stage only the relevant files, commit with a conventional message, push the branch, open a draft PR with a reviewer-friendly body, and get a ready-to-send Slack message. ## Quick Start Create a pull request for my current branch following the standard conventions and draft the Slack message for my teammate.

Frequently Asked Questions about pr

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

FAQPage Schema
How do I create a GitHub pull request with conventional commits?▼

Stage only the changes belonging to the PR, commit with a `type(scope): description` message using types like feat, fix, or refactor, push the branch, then run gh pr create with a title matching the commit message and a structured body.

How to write a good pull request description for reviewers?▼

Lead with a Why section explaining the problem, follow with a brief bulleted Changes list covering only what matters for review, and end with a Test plan of checkboxes for end-to-end verification. Keep one goal per PR and omit tool attribution.

Can I create a draft pull request with the GitHub CLI?▼

Yes, gh pr create supports opening draft PRs, and this workflow defaults to drafts unless a ready-for-review PR is explicitly requested. The title should match the commit message and the body follows the Why, Changes, Test plan structure.

What if my working tree is clean but commits are not pushed?▼

A clean working tree with unpublished branch commits is still valid for PR creation. Skip the staging and committing steps, push the branch to origin, and continue with gh pr create as normal.

Should I push changes directly to the main branch?▼

No, never push straight to the default branch. If you are on main or master, create a feature branch first, then push with git push -u origin <branch> before opening the pull request.