Skill

github-create-pr

Creates a pull request using GitHub CLI by following every numbered step in order. Do not skip steps. Do not improvise — execute the workflow literally. Activate when the user says "create PR", "open PR", "push and PR", "submit for review", or work is ready for review.

Open a pull request for the current branch using gh.

Steps

Check for uncommitted changes — Run git status --short. If output is non-empty, show the list and ask: "There are uncommitted changes. Commit and include them, or create the PR without them?" Do not proceed without an answer.
Verify branch — Run git branch --show-current. If on main or master, stop and warn: "You are on the default branch. Create a feature branch first."
Check remote state — Run git status -sb to detect if the branch is behind the remote. If behind, warn and ask whether to pull first.
Check for existing PR — Run:
```
gh pr list --head $(git branch --show-current)
```
If a PR already exists, show its URL and ask: "A PR already exists for this branch. Open it instead?"
Run verification — Check AGENTS.md or the project's build/test configuration for pre-push steps. Run them. If any fail, stop and fix before pushing.
Push the branch — Run:
```
git push -u origin $(git branch --show-current)
```
If push fails, report the error and suggest fixes (force push not allowed without explicit permission).
Analyze changes — Run:
```
git log main..HEAD --oneline
git diff main --stat
```
Use this to understand the scope and write an accurate PR description. Do not guess — base the description on actual changes.
Create the PR — Run:
```
gh pr create --title "<title>" --body "<body>"
```
Show the generated title and description to the user for approval before submitting. If gh is not installed, provide the manual URL: https://github.com/{owner}/{repo}/compare/{branch}
Ask about browser — "Open the PR in your browser?" If yes, run gh pr view --web.

Conventions

Title: under 70 characters, plain language summary.

Description format:

Summary paragraph explaining what and why.

- Concise bullet per logical change
- No sub-bullets
- Focus on outcomes, not file paths

## Testing (optional, only when changes affect behavior)

## Deployment (optional, only when post-merge steps exist)

No section headers unless there are multiple distinct sections. The default is summary + bullets, flat.
Do not force push without explicit user permission.
Do not push to main/master directly.
If the branch has a single commit, use its message as the PR title. If multiple commits, summarize.

└── SKILL.md

SKILL.md | | Raw

Create Pull Request

Open a pull request for the current branch using gh.

Steps

Check for uncommitted changes — Run git status --short. If output is non-empty, show the list and ask: "There are uncommitted changes. Commit and include them, or create the PR without them?" Do not proceed without an answer.
Verify branch — Run git branch --show-current. If on main or master, stop and warn: "You are on the default branch. Create a feature branch first."
Check remote state — Run git status -sb to detect if the branch is behind the remote. If behind, warn and ask whether to pull first.
Check for existing PR — Run:
```
gh pr list --head $(git branch --show-current)
```
If a PR already exists, show its URL and ask: "A PR already exists for this branch. Open it instead?"
Run verification — Check AGENTS.md or the project's build/test configuration for pre-push steps. Run them. If any fail, stop and fix before pushing.
Push the branch — Run:
```
git push -u origin $(git branch --show-current)
```
If push fails, report the error and suggest fixes (force push not allowed without explicit permission).
Analyze changes — Run:
```
git log main..HEAD --oneline
git diff main --stat
```
Use this to understand the scope and write an accurate PR description. Do not guess — base the description on actual changes.
Create the PR — Run:
```
gh pr create --title "<title>" --body "<body>"
```
Show the generated title and description to the user for approval before submitting. If gh is not installed, provide the manual URL: https://github.com/{owner}/{repo}/compare/{branch}
Ask about browser — "Open the PR in your browser?" If yes, run gh pr view --web.

Conventions

Title: under 70 characters, plain language summary.

Description format:

Summary paragraph explaining what and why.

- Concise bullet per logical change
- No sub-bullets
- Focus on outcomes, not file paths

## Testing (optional, only when changes affect behavior)

## Deployment (optional, only when post-merge steps exist)

No section headers unless there are multiple distinct sections. The default is summary + bullets, flat.
Do not force push without explicit user permission.
Do not push to main/master directly.
If the branch has a single commit, use its message as the PR title. If multiple commits, summarize.

---
name: github-create-pr
description: >
  Creates a pull request using GitHub CLI by following
  every numbered step in order. Do not skip steps. Do not
  improvise — execute the workflow literally. Activate
  when the user says "create PR", "open PR", "push and
  PR", "submit for review", or work is ready for review.
metadata:
  version: "1.0.0"
  tags: "category:workflow, tool:git, tool:github"
---

# Create Pull Request

Open a pull request for the current branch using `gh`.

## Steps

1. **Check for uncommitted changes** — Run `git status
   --short`. If output is non-empty, show the list and
   ask: "There are uncommitted changes. Commit and
   include them, or create the PR without them?" Do not
   proceed without an answer.

2. **Verify branch** — Run `git branch --show-current`.
   If on `main` or `master`, stop and warn: "You are on
   the default branch. Create a feature branch first."

3. **Check remote state** — Run `git status -sb` to
   detect if the branch is behind the remote. If behind,
   warn and ask whether to pull first.

4. **Check for existing PR** — Run:
   ```bash
   gh pr list --head $(git branch --show-current)
   ```
   If a PR already exists, show its URL and ask: "A PR
   already exists for this branch. Open it instead?"

5. **Run verification** — Check AGENTS.md or the project's
   build/test configuration for pre-push steps. Run them.
   If any fail, stop and fix before pushing.

6. **Push the branch** — Run:
   ```bash
   git push -u origin $(git branch --show-current)
   ```
   If push fails, report the error and suggest fixes
   (force push not allowed without explicit permission).

7. **Analyze changes** — Run:
   ```bash
   git log main..HEAD --oneline
   git diff main --stat
   ```
   Use this to understand the scope and write an accurate
   PR description. Do not guess — base the description
   on actual changes.

8. **Create the PR** — Run:
   ```bash
   gh pr create --title "<title>" --body "<body>"
   ```
   Show the generated title and description to the user
   for approval before submitting. If `gh` is not
   installed, provide the manual URL:
   `https://github.com/{owner}/{repo}/compare/{branch}`

9. **Ask about browser** — "Open the PR in your browser?"
   If yes, run `gh pr view --web`.

## Conventions

- Title: under 70 characters, plain language summary.
- Description format:
  ```
  Summary paragraph explaining what and why.

  - Concise bullet per logical change
  - No sub-bullets
  - Focus on outcomes, not file paths

  ## Testing (optional, only when changes affect behavior)

  ## Deployment (optional, only when post-merge steps exist)
  ```
- No section headers unless there are multiple distinct
  sections. The default is summary + bullets, flat.
- Do not force push without explicit user permission.
- Do not push to main/master directly.
- If the branch has a single commit, use its message as
  the PR title. If multiple commits, summarize.

github-create-pr is a step-by-step workflow for creating pull requests using the GitHub CLI.

Why the skill checks for an existing PR first

Agents may re-trigger PR creation on resume. Duplicate PRs confuse reviewers and clutter the repo. A simple gh pr list check prevents this.

Why verification runs before pushing

Pushing broken code creates noise — failed CI, reviewer time wasted, force-push needed to fix. Running the project's verify step locally catches issues before they reach the remote.

Why the skill shows title and description for approval

PR metadata is public and permanent. Agents hallucinate descriptions when summarizing changes from memory. Showing the user what will be submitted prevents embarrassing or inaccurate PR descriptions.

Why PR descriptions are built from git diff

Grounding the PR description in actual git diff and git log output prevents hallucination. The agent describes what changed based on evidence, not memory.

[1.0.0] - 2026-05-24

Added

Initial release of create-pr skill
PR creation workflow using GitHub CLI (gh)
Uncommitted changes check with user prompt
Branch validation (prevents PR from main/master)
Remote state check with behind-remote detection
Pre-push verification step
Browser open offer after PR creation