name	create-pr
description	Use when the user asks to create, or open a PR. Validates branch name against repo conventions, uses the repo's PR template if present, writes a concise informative description, and opens the PR via gh. No Claude attribution.

Create PR

Open a GitHub PR with a clean, concise description. No Claude attribution of any kind.

1. Validate the branch name

Run git rev-parse --abbrev-ref HEAD.

If on the default branch (main/master/trunk), stop and ask the user to create a branch first.
Look at recent branches for the repo's naming convention: git branch -r --sort=-committerdate | head -20.
Judge the current name against that convention and the work on the branch (git log <base>..HEAD --oneline). A bad name is vague (patch-1, fix, wip, tmp, test), doesn't describe the change, or violates the convention (wrong prefix, wrong case, missing ticket ID).
If the name is bad:
- If the user passed a replacement as an argument to the skill, use it.
- Otherwise propose one derived from the commits + convention and ask for confirmation.
- Rename with git branch -m <new> before pushing. If the branch was already pushed, also delete the old remote branch after the new push succeeds (git push origin :<old>).

Respect any local branch-naming hook or memory the user has set (e.g. a hiradp/ prefix convention). Don't override it.

2. Gather context

Determine the base branch: gh repo view --json defaultBranchRef -q .defaultBranchRef.name (fallback to main).

In parallel:

git status
git log <base>..HEAD — all commits that will ship
git diff <base>...HEAD — full diff (summarize mentally if large; don't paste it back to the user)
git log -5 --oneline on the base to match commit/title style

3. Find the PR template

Check in order and use the first one that exists:

.github/pull_request_template.md
.github/PULL_REQUEST_TEMPLATE.md
.github/PULL_REQUEST_TEMPLATE/*.md — if multiple, pick the one that matches the change type or ask
docs/pull_request_template.md
pull_request_template.md

If none exists, use:

## Why
<1-3 bullets: why changed >

## What
<1-3 bullets: what changed >

4. Write the title and body

Title: under 70 chars. Match the repo's commit style (check git log --oneline on the base) — conventional commits, ticket prefix, sentence case, etc.
Body: fill in the template. Lead with why, then what. Cut filler. Keep checkboxes/sections from the template intact even if short. Link tickets when the branch name or commits reference one.
Do NOT include 🤖 Generated with Claude Code, Co-Authored-By: Claude …, "Generated by", or any similar attribution — in the title, body, or anywhere else.

5. Push and open the PR

No upstream set: git push -u origin <branch>
Otherwise: git push

Then:

gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

Return the PR URL to the user.

Notes

If gh isn't authenticated, tell the user to run gh auth login (suggest the ! gh auth login prefix so it runs in-session).
Never force-push or rewrite history as part of this skill. If the remote has diverged, stop and ask.
If there are no commits ahead of base, stop — there's nothing to PR.

name	create-pr
description	Use when the user asks to create, or open a PR. Validates branch name against repo conventions, uses the repo's PR template if present, writes a concise informative description, and opens the PR via gh. No Claude attribution.

Create PR

Open a GitHub PR with a clean, concise description. No Claude attribution of any kind.

1. Validate the branch name

Run git rev-parse --abbrev-ref HEAD.

If on the default branch (main/master/trunk), stop and ask the user to create a branch first.
Look at recent branches for the repo's naming convention: git branch -r --sort=-committerdate | head -20.
Judge the current name against that convention and the work on the branch (git log <base>..HEAD --oneline). A bad name is vague (patch-1, fix, wip, tmp, test), doesn't describe the change, or violates the convention (wrong prefix, wrong case, missing ticket ID).
If the name is bad:
- If the user passed a replacement as an argument to the skill, use it.
- Otherwise propose one derived from the commits + convention and ask for confirmation.
- Rename with git branch -m <new> before pushing. If the branch was already pushed, also delete the old remote branch after the new push succeeds (git push origin :<old>).

Respect any local branch-naming hook or memory the user has set (e.g. a hiradp/ prefix convention). Don't override it.

2. Gather context

Determine the base branch: gh repo view --json defaultBranchRef -q .defaultBranchRef.name (fallback to main).

In parallel:

git status
git log <base>..HEAD — all commits that will ship
git diff <base>...HEAD — full diff (summarize mentally if large; don't paste it back to the user)
git log -5 --oneline on the base to match commit/title style

3. Find the PR template

Check in order and use the first one that exists:

.github/pull_request_template.md
.github/PULL_REQUEST_TEMPLATE.md
.github/PULL_REQUEST_TEMPLATE/*.md — if multiple, pick the one that matches the change type or ask
docs/pull_request_template.md
pull_request_template.md

If none exists, use:

## Why
<1-3 bullets: why changed >

## What
<1-3 bullets: what changed >

4. Write the title and body

Title: under 70 chars. Match the repo's commit style (check git log --oneline on the base) — conventional commits, ticket prefix, sentence case, etc.
Body: fill in the template. Lead with why, then what. Cut filler. Keep checkboxes/sections from the template intact even if short. Link tickets when the branch name or commits reference one.
Do NOT include 🤖 Generated with Claude Code, Co-Authored-By: Claude …, "Generated by", or any similar attribution — in the title, body, or anywhere else.

5. Push and open the PR

No upstream set: git push -u origin <branch>
Otherwise: git push

Then:

gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

Return the PR URL to the user.

Notes

If gh isn't authenticated, tell the user to run gh auth login (suggest the ! gh auth login prefix so it runs in-session).
Never force-push or rewrite history as part of this skill. If the remote has diverged, stop and ask.
If there are no commits ahead of base, stop — there's nothing to PR.

create-pr

Create PR

1. Validate the branch name

2. Gather context

3. Find the PR template

4. Write the title and body

5. Push and open the PR

Notes

Create PR

1. Validate the branch name

2. Gather context

3. Find the PR template

4. Write the title and body

5. Push and open the PR

Notes