agentleFS
Sign inStart free
paultyngpaultyng/skill-issue/skills/create-pr/SKILL.md

create-pr

Skill8 starsChanged 3 months agoMITView on GitHub

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.

  • Commits and pushes

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 178 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

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

    line 17
  2. Distinctive:

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

    line 27
  3. Very specific:

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

    line 31
  4. Distinctive:

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

    line 43
  5. Distinctive:

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

    line 61
  6. Very specific:

    Always pass --draft per draft-prs.

    line 67

“Common” is measured: kept by at least 6 in 10 of the 178 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. .github/pull_request_template.md
  2. .github/PULL_REQUEST_TEMPLATE.md
  3. docs/pull_request_template.md
  4. pull_request_template.md (repo root)
  5. .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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free