Create pr

Skill paultyng/skill-issue/skills/create-pr

Personal Claude Code / Cursor agent skills, rules, and config

Install

npx -y skills add paultyng/skill-issue --skill create-pr

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when creating a new GitHub pull request, opening a PR for the current branch, or when another skill (like ship-it) needs a PR created for a branch that does not have one yet.

SKILL.md

3.1 KB, as published. Nobody here has run it

Create PR

Open a new GitHub pull request for the current branch using the repo's PR template if one exists. Defaults to --draft.

1. Preconditions

Current branch must be pushed to a remote. If git rev-parse --abbrev-ref --symbolic-full-name @{u} fails, run git push -u origin HEAD first.
Skip creation if a PR already exists for the branch: gh pr view --json number 2>/dev/null returns 0. In that case the caller likely wants gh pr edit instead.

2. Detect PR template

Check for a template in this order and use the first match:

.github/pull_request_template.md
.github/PULL_REQUEST_TEMPLATE.md
docs/pull_request_template.md
pull_request_template.md (repo root)
.github/PULL_REQUEST_TEMPLATE/*.md. If multiple, prefer one matching the dominant commit type (feature.md or feat-* for feat: commits, bugfix.md for fix:, etc.). If still ambiguous, ask the user which to use.

Filename matching is case-insensitive on macOS but case-sensitive on Linux; check both common cases.

If none found, use the standard body in step 4.

3. Determine title

Use Conventional Commits format derived from the branch's commits (git log <base>..HEAD):

Single commit: use its subject line verbatim.
Multiple commits: synthesize one conventional-commit-style title covering the change. Keep under 72 chars.

4. Generate body

Apply terse-output to the body: bullets over prose, no filler ("just", "really"), no hedge openers ("I noticed that…", "You might want to consider…"). Lead with what changed and why; skip implementation play-by-play.

With template: read the template file and fill its sections from the diff (git diff <base>...HEAD) and commit history. Preserve the template's structure, headings, comments, and checklists exactly. Leave checklist items unchecked unless the work demonstrably satisfies them. For sections that do not apply, mark them N/A only if the template requires a value; otherwise leave the section body empty.

Do not strip HTML comments from the template (they are often instructions to the PR author and may be intentionally rendered as hidden guidance).

Without template, use this body:

## Summary

<1–3 bullets covering what changed and why>

## Test plan

- [ ] <specific verification steps>

5. Confirm and create

Per no-post-without-confirmation, present the title and body to the user and wait for explicit approval before creating.

After approval, write the body to a temp file (avoids shell-escaping issues with multiline markdown) and create the PR:

gh pr create --draft --title "<title>" --body-file /tmp/pr-body.md

Always pass --draft per draft-prs. Only omit --draft if the user explicitly asked for a ready/non-draft PR.

Print the resulting PR URL.