pr-creator
Guide for creating pull requests with draft status confirmation. Use when user requests PR creation with phrases like 'create a PR', 'make a pull request', 'gh pr create', or similar PR creation requests.
When & Why to Use This Skill
The PR Creator skill streamlines the GitHub workflow by automating pull request creation through the GitHub CLI (gh). It enhances developer productivity by managing the PR lifecycle directly within the chat, ensuring best practices like draft status confirmation and the generation of concise, meaningful PR descriptions that focus on essential changes.
Use Cases
- Scenario 1: Creating a 'Work in Progress' (WIP) pull request as a draft to share code with teammates for early feedback without triggering formal review notifications.
- Scenario 2: Rapidly submitting a completed feature or bug fix for review by automating the 'gh pr create' command with a clean, summarized description.
- Scenario 3: Standardizing repository documentation by following the skill's guidelines for minimal and essential PR descriptions, avoiding bloated or redundant templates.
| name | pr-creator |
|---|---|
| description | Guide for creating pull requests with draft status confirmation. Use when user requests PR creation with phrases like 'create a PR', 'make a pull request', 'gh pr create', or similar PR creation requests. |
PR Creator
Overview
Guides PR creation by confirming whether to create as draft before executing the gh pr create command.
Workflow
When the user requests PR creation:
Confirm draft status: Use AskUserQuestion to ask whether to create the PR as draft
Question: "Should this PR be created as a draft?" Options: - "Yes, create as draft" → Execute with --draft flag - "No, create as ready for review" → Execute without --draft flagExecute gh pr create: Based on the user's choice, run the appropriate command:
- Draft:
gh pr create --draft --title "..." --body "..." - Ready:
gh pr create --title "..." --body "..."
- Draft:
PR Description Guidelines
Write concise, minimal descriptions:
- No fixed format sections (avoid ## Summary, ## Test plan, etc.)
- Include only essential information needed to understand the change
- Keep it brief - typically 1-3 sentences or a short bulleted list
- Adapt format to PR content - simple changes need simple descriptions
Examples:
- "Fix authentication bug in login flow"
- "Add user profile API endpoint\n- GET /api/users/:id\n- Returns user data with privacy filters"
- "Refactor database queries for performance"