Claude Skill

pr-creator

Creates or updates GitHub PRs with house-style titles and bodies, issue linking, repository templates, and draft state. Use when asked to "create a PR", "rewrite the PR description", or "polish this PR". For code fixes use tidy; for CI and review threads use pr-babysitter; for np

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download mblode-agent-skills-skills_pr-creator-24f4fd8.zip · 7 KB
mblode/agent-skills 123 11 forks MIT Updated 6d ago
Part of mblode/agent-skills — 22 skills

Install

skills CLI npx skills add https://github.com/mblode/agent-skills/tree/main/skills/pr-creator
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install mblode-agent-skills@llmmart
Git git clone https://github.com/mblode/agent-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole mblode/agent-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

pr-creator

Write PR descriptions like a developer posting in Slack, not an AI summarizing a diff.

  • IS: creating or updating a GitHub PR's title, body, draft state, and reviewers, plus the commit restructuring and review path that make a large diff readable.
  • IS NOT: changing the code in the diff (use tidy), reviewing it for bugs (use pr-reviewer), watching CI and review comments after the PR exists (use pr-babysitter), or cutting npm releases (use autoship).

Reference Files

File Read When
references/pr-polish.md Commits contain fixup, WIP, or "address review" noise, the diff exceeds 500 lines, or the user asks to polish, restructure, squash, or split the PR

Workflow

Copy this checklist to track progress:

PR creation progress:
- [ ] Inspect the current branch and diff against the existing PR base, or the discovered default branch merge-base
- [ ] Existing PR? gh pr view --json url,state,isDraft (state OPEN means edit, not create)
- [ ] Linear ID from branch, commits, prompt, or issue link; no ID means no prefix
- [ ] Noisy commits or a >500-line diff? references/pr-polish.md, before pushing
- [ ] PR template present? Read it (paths under Templates)
- [ ] Draft title and body against Rules and Anti-patterns
- [ ] git push -u origin HEAD
- [ ] gh pr create (or gh pr edit); then gh pr view --json url,title and return the URL

Do not ask the user to approve the description first; the point is speed. They can ask for a rewrite and you run gh pr edit.

Rules

  1. Title. With a Linear ID: ABC-123: Add auth flow. Without one: Add auth flow. Under 60 characters, no trailing period. If the repo lints PR titles (a semantic-pull-request or commitlint workflow under .github/workflows/), use its shape and put the ID at the end: feat: add auth flow (ABC-123). Linear links on the ID wherever it sits in the title.
  2. Body. One short paragraph: what changed and why it matters. Length follows the change; a one-line body is fine for a one-line fix.
  3. No fake why. If the reason is not in the prompt, the Linear issue, the branch, the commits, or the diff, leave it out rather than inventing one.
  4. Risk only when real. One Risk: line for migrations, billing, auth, permissions, irreversible writes, wide blast radius, or a subtle behavior change. Otherwise nothing.
  5. Testing only if real. Say what you ran only if you ran it. Never a Test plan section, never checkboxes.
  6. Partial work. If this PR does not finish the Linear issue, keep the ID out of the title and write Part of ABC-123 in the body. Linear's default automation moves a linked issue to Done when the PR merges; the non-closing magic word links without closing.
  7. Draft and reviewers only when asked. --draft for "draft" or "WIP"; gh pr ready promotes it later, gh pr ready --undo demotes. --reviewer alice,org/team only for people the user named; CODEOWNERS already requests owners.
  8. Stop after the useful content. The harness's attribution setting owns the PR footer (Generated with Claude Code, session link). Never hand-write one, and never strip one the harness or a repo policy appends. Everything above the footer is this skill's; its one-paragraph body replaces the harness's default Summary and Test plan sections.

Anti-patterns: never write these

  • Openers that narrate the artifact: "This PR implements...", "This change ensures...", "This commit introduces..."
  • Changelog verbs with no reason attached: "Refactored X to improve Y", "Updated Z to handle...", "Added comprehensive test coverage for..."
  • Lines that start with a filename or path; the diff already lists the files
  • A Test plan section with checkboxes
  • A bullet list that restates the diff

Examples

Feature (ABC-123 is the real Linear ID)

Title: ABC-123: Add auth flow with session management

Adds the auth flow needed for session-based login, including refresh, timeout handling, and a small error boundary for auth failures.

Bugfix (real risk, real testing)

Title: PAY-482: Dedupe Stripe webhook retries

Stripe retries webhooks on timeout and our handler wasn't idempotent, so retried events created duplicate invoices. Now we record processed event IDs and skip repeats. Tested by replaying a captured retry sequence locally.

Risk: touches the billing write path.

Chore (no Linear ID, no why beyond the diff)

Title: Bump eslint to 9 and fix the new no-unused-vars hits

Bumps eslint to 9. The only code change is removing three unused imports it now flags.

The first two carry the real why from the commits and stop. Risk: earns its line in the second because the diff touches billing writes; the testing sentence is there only because a replay actually ran. The third has no deeper why, so it does not pretend to.

Templates

GitHub reads the first match of pull_request_template.md (case-insensitive) in .github/, the repo root, or docs/, or a PULL_REQUEST_TEMPLATE/ directory in any of those for multiple templates. gh pr create --body skips the template entirely, so when one exists, read it and write the body in its shape: keep its headings, answer each in a sentence or two, and put the one-paragraph description under the first heading. Add nothing the template does not ask for.

Creating the PR

Write the exact body to a temporary file with the file tool, then pass its path through --body-file. The examples use /tmp/pr-body.md; choose a task-specific temporary path during execution.

No PR yet: create

git push -u origin HEAD   # when creating a PR for local commits

gh pr create --title "ABC-123: Add auth flow" --body-file /tmp/pr-body.md

gh pr view --json url,title   # evidence the PR exists; return the url

Add --draft or --reviewer here when Rule 7 applies. --base only when the target is not the default branch.

PR already open: update title and body

gh pr edit overwrites the title and body wholesale, so draft the full replacement, not a patch. Same rules and anti-patterns apply.

# A metadata-only edit does not push local commits.

gh pr edit --title "ABC-123: Add auth flow" --body-file /tmp/pr-body.md

gh pr view --json url,title   # confirm the update; return the url

Gotchas

  • gh pr create on a branch with no upstream: in a TTY it blocks on a "Where should we push?" prompt; from a non-interactive harness it aborts with you must first push the current branch to a remote, or use the --head flag. Either way, git push -u origin HEAD first.
  • Non-interactive gh pr create needs both --title and --body (or --fill); without them it exits with must provide --title and --body (or --fill) when not running interactively. --fill copies commit messages verbatim, which is exactly the changelog body this skill exists to avoid.
  • Quote the heredoc delimiter (<<'EOF'). Unquoted <<EOF lets the shell expand backticks and $vars in the body, corrupting the description or running commands.
  • Two different failures look alike: on the default branch, gh pr create aborts with must be on a branch named differently than "main"; on a branch with nothing new against the base it fails with No commits between main and <branch>. The first needs a branch, the second a commit.
  • A branch with an open PR fails gh pr create with a pull request for branch ... into branch main already exists. gh pr view --json state first; OPEN means gh pr edit. A MERGED or CLOSED result is a stale PR, so create a new one.
  • Derive the Linear ID from the branch, uppercased: Linear's default branch format is username/abc-123-title-slug, so mblode/abc-123-add-auth gives ABC-123. Never guess an ID: Linear links the PR to whatever ID the title contains, and a wrong one moves someone else's issue.
  • Plain git diff omits committed changes. Use the actual PR base with three-dot diff; do not assume main, especially for stacked PRs.
  • Restructure commits before the first push. Force-pushing a rewritten branch under an open PR marks existing inline comments "outdated" and the reviewer loses their thread.

Related skills

  • pr-reviewer: run before creating to check the diff for bugs.
  • tidy: applies fixes to the code in the diff; this skill edits only the PR and its commits.
  • pr-babysitter: hand off after creation to watch CI, conflicts, and review comments.
  • autoship: npm release pipeline (changesets, version PR, publish); "ship it" without release context routes here instead.

Maintenance only: evals/evals.json contains regression scenarios for changes to this skill; it does not load during a user task.

Files (agent-skills)
  • evals
    • evals.json 1.4 KB 
      {
  "skill_name": "pr-creator",
  "evals": [
    {
      "id": 1,
      "prompt": "Update only the body of the existing PR. Its base is release/next, and this local checkout also has an unpushed experimental commit.",
      "expected_output": "Edit the PR metadata against the correct published PR scope.",
      "files": [],
      "assertions": [
        "Does not push the experimental commit",
        "Uses the PR base instead of main",
        "Returns the updated PR URL"
      ]
    },
    {
      "id": 2,
      "prompt": "Create a PR for a partial implementation of ABC-123. The repository template requires Summary and Validation sections.",
      "expected_output": "Use the required template and a non-closing issue reference.",
      "files": [],
      "assertions": [
        "Preserves the repository headings",
        "Uses Part of ABC-123 rather than claiming the issue is complete",
        "Does not fabricate validation results"
      ]
    }
  ],
  "routing": {
    "should_trigger": [
      "Update only the body of the existing PR. Its base is release/next, and this local checkout also has an unpushed experimental commit.",
      "Create a PR for a partial implementation of ABC-123. The repository template requires Summary and Validation sections."
    ],
    "near_miss": [
      {
        "prompt": "Diagnose the red CI job on this existing PR.",
        "expected": "pr-babysitter"
      }
    ]
  }
}
  • references
    • pr-polish.md 5 KB 
      # PR Polish

Restructure commits and add a review path so a large or messy PR reads cleanly. Loaded by pr-creator when commits are noisy, the diff exceeds 500 lines, or the user asks to polish, squash, restructure, or split.

Do this before the first push wherever possible. Rewriting history under an open PR marks inline comments on the old SHAs "outdated" and the reviewer loses their thread.

## Guardrails

- Snapshot the tree before any rewrite and compare after. Same hash means only history changed; a different hash means code changed, so stop and investigate before pushing.

  ```bash
  TREE_BEFORE=$(git rev-parse HEAD^{tree})
  # ... rewrite ...
  [ "$TREE_BEFORE" = "$(git rev-parse HEAD^{tree})" ] || echo "TREE CHANGED: abort"
  ```

- Push a rewritten branch with `git push --force-with-lease`, never plain `--force`. Plain force overwrites commits a teammate pushed while you were rewriting; with-lease refuses when the remote moved.
- Do not rewrite a branch other people have commits on without telling them; their next pull diverges.
- Read the repo's commit convention from `git log --oneline -20` and match it. If the log uses Conventional Commits (`feat(scope): ...`), write new commits that way; if it does not, do not introduce it in one PR.
- After restructuring, run lint and tests on HEAD as an external check. Reordering can leave an intermediate commit that references code from a later one; that is a readability problem, not a blocker, unless the repo bisects.

## Pick the lightest rewrite that fits

| Situation | Rewrite |
|-----------|---------|
| Fixups aimed at specific earlier commits ("address review", typo fixes, "oops") | Autosquash |
| Commits are fine but one message is wrong, and it is the tip | `git commit --amend -m "..."` |
| Commits interleave unrelated work, or the order fights the reader | Soft reset and rebuild |
| The PR bundles independent changes a reviewer could approve separately | Split |

### Autosquash

Mark each stray commit as a fixup of its target, then let git fold them in. `GIT_SEQUENCE_EDITOR=true` accepts the generated todo list unchanged, so no editor opens.

```bash
BASE=$(git merge-base HEAD origin/main)
git commit --fixup=<target-sha>              # for new stray changes; an existing stray commit needs the soft reset path unless its subject already starts with "fixup!"
GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash "$BASE"
```

Git 2.44 and later also accept `git rebase --autosquash "$BASE"` with no `-i`; the `GIT_SEQUENCE_EDITOR` form works on every version (verified on 2.43), so it is the default here. Any commit whose subject already begins `fixup!` or `squash!` is folded without further flags, and fixups never open a commit editor, so the command completes with no TTY.

### Soft reset and rebuild

For a full reorder, collapse the branch to one staged change and recommit it in reading order. This is non-interactive by construction, which is why it beats scripting `GIT_SEQUENCE_EDITOR` with `sed` for anything more than a squash.

```bash
BASE=$(git merge-base HEAD origin/main)
git reset --soft "$BASE"                     # all changes stay staged, history is gone

git commit -m "Add user role column migration" -- <schema-files>
git commit -m "Add role-based permission checks" -- <logic-files>
git commit -m "Add role selector to settings page" -- <ui-files>
git commit -m "Add permission and role tests" -- <test-files>
```

`git commit -m ... -- <paths>` commits only the named paths from the index and leaves the rest staged, so the next commit picks up where the last one stopped. The split is by file: `git add -p` needs a terminal, so when one file carries two logical changes, keep them in one commit rather than fighting it.

Reading order, when the change has these layers:

1. Schema and migrations
2. Core logic (models, services, business rules)
3. Wiring (routes, controllers, endpoints)
4. UI (components, styles)
5. Tests
6. Config, docs, tooling

### Split

Extract the independent slice onto its own branch, then rebuild the original without it.

```bash
git switch -c <new-branch> origin/main
git cherry-pick <sha>...                     # the independent commits, oldest first
git push -u origin HEAD                      # then gh pr create for this slice per SKILL.md

git switch <original-branch>
# soft reset and rebuild, omitting the extracted files
```

Add `Part of ABC-123` to both bodies if they share one Linear issue, and one line in the original PR saying what moved where. Split only work that a reviewer could approve without the other PR; splitting coupled changes doubles the review, it does not halve it.

## Review path in the description

The one-paragraph rule in SKILL.md still applies. For a diff over 500 lines or touching five or more files, add one line telling the reviewer where to start:

```text
Review path: start with migration.sql, then permissions.ts, then the UI.
```

The `Risk:` line, when the change earns one, follows the same rule as SKILL.md: one line, only for something non-obvious ("The migration locks the users table; run during low traffic").
  • SKILL.md 9 KB 
    ---
name: pr-creator
description: Creates or updates GitHub PRs with house-style titles and bodies, issue linking, repository templates, and draft state. Use when asked to "create a PR", "rewrite the PR description", or "polish this PR". For code fixes use tidy; for CI and review threads use pr-babysitter; for npm releases use autoship.
compatibility: Requires Git and authenticated GitHub access. The documented command workflow uses GitHub CLI.
---

# pr-creator

Write PR descriptions like a developer posting in Slack, not an AI summarizing a diff.

- **IS:** creating or updating a GitHub PR's title, body, draft state, and reviewers, plus the commit restructuring and review path that make a large diff readable.
- **IS NOT:** changing the code in the diff (use `tidy`), reviewing it for bugs (use `pr-reviewer`), watching CI and review comments after the PR exists (use `pr-babysitter`), or cutting npm releases (use `autoship`).

## Reference Files

| File | Read When |
|------|-----------|
| `references/pr-polish.md` | Commits contain fixup, WIP, or "address review" noise, the diff exceeds 500 lines, or the user asks to polish, restructure, squash, or split the PR |

## Workflow

Copy this checklist to track progress:

```text
PR creation progress:
- [ ] Inspect the current branch and diff against the existing PR base, or the discovered default branch merge-base
- [ ] Existing PR? gh pr view --json url,state,isDraft (state OPEN means edit, not create)
- [ ] Linear ID from branch, commits, prompt, or issue link; no ID means no prefix
- [ ] Noisy commits or a >500-line diff? references/pr-polish.md, before pushing
- [ ] PR template present? Read it (paths under Templates)
- [ ] Draft title and body against Rules and Anti-patterns
- [ ] git push -u origin HEAD
- [ ] gh pr create (or gh pr edit); then gh pr view --json url,title and return the URL
```

Do not ask the user to approve the description first; the point is speed. They can ask for a rewrite and you run `gh pr edit`.

## Rules

1. **Title.** With a Linear ID: `ABC-123: Add auth flow`. Without one: `Add auth flow`. Under 60 characters, no trailing period. If the repo lints PR titles (a `semantic-pull-request` or commitlint workflow under `.github/workflows/`), use its shape and put the ID at the end: `feat: add auth flow (ABC-123)`. Linear links on the ID wherever it sits in the title.
2. **Body.** One short paragraph: what changed and why it matters. Length follows the change; a one-line body is fine for a one-line fix.
3. **No fake why.** If the reason is not in the prompt, the Linear issue, the branch, the commits, or the diff, leave it out rather than inventing one.
4. **Risk only when real.** One `Risk:` line for migrations, billing, auth, permissions, irreversible writes, wide blast radius, or a subtle behavior change. Otherwise nothing.
5. **Testing only if real.** Say what you ran only if you ran it. Never a `Test plan` section, never checkboxes.
6. **Partial work.** If this PR does not finish the Linear issue, keep the ID out of the title and write `Part of ABC-123` in the body. Linear's default automation moves a linked issue to Done when the PR merges; the non-closing magic word links without closing.
7. **Draft and reviewers only when asked.** `--draft` for "draft" or "WIP"; `gh pr ready` promotes it later, `gh pr ready --undo` demotes. `--reviewer alice,org/team` only for people the user named; CODEOWNERS already requests owners.
8. **Stop after the useful content.** The harness's `attribution` setting owns the PR footer (`Generated with Claude Code`, session link). Never hand-write one, and never strip one the harness or a repo policy appends. Everything above the footer is this skill's; its one-paragraph body replaces the harness's default `Summary` and `Test plan` sections.

## Anti-patterns: never write these

- Openers that narrate the artifact: "This PR implements...", "This change ensures...", "This commit introduces..."
- Changelog verbs with no reason attached: "Refactored X to improve Y", "Updated Z to handle...", "Added comprehensive test coverage for..."
- Lines that start with a filename or path; the diff already lists the files
- A `Test plan` section with checkboxes
- A bullet list that restates the diff

## Examples

### Feature (`ABC-123` is the real Linear ID)

```text
Title: ABC-123: Add auth flow with session management

Adds the auth flow needed for session-based login, including refresh, timeout handling, and a small error boundary for auth failures.
```

### Bugfix (real risk, real testing)

```text
Title: PAY-482: Dedupe Stripe webhook retries

Stripe retries webhooks on timeout and our handler wasn't idempotent, so retried events created duplicate invoices. Now we record processed event IDs and skip repeats. Tested by replaying a captured retry sequence locally.

Risk: touches the billing write path.
```

### Chore (no Linear ID, no why beyond the diff)

```text
Title: Bump eslint to 9 and fix the new no-unused-vars hits

Bumps eslint to 9. The only code change is removing three unused imports it now flags.
```

The first two carry the real why from the commits and stop. `Risk:` earns its line in the second because the diff touches billing writes; the testing sentence is there only because a replay actually ran. The third has no deeper why, so it does not pretend to.

## Templates

GitHub reads the first match of `pull_request_template.md` (case-insensitive) in `.github/`, the repo root, or `docs/`, or a `PULL_REQUEST_TEMPLATE/` directory in any of those for multiple templates. `gh pr create --body` skips the template entirely, so when one exists, read it and write the body in its shape: keep its headings, answer each in a sentence or two, and put the one-paragraph description under the first heading. Add nothing the template does not ask for.

## Creating the PR

Write the exact body to a temporary file with the file tool, then pass its path through `--body-file`. The examples use `/tmp/pr-body.md`; choose a task-specific temporary path during execution.

### No PR yet: create

```bash
git push -u origin HEAD   # when creating a PR for local commits

gh pr create --title "ABC-123: Add auth flow" --body-file /tmp/pr-body.md

gh pr view --json url,title   # evidence the PR exists; return the url
```

Add `--draft` or `--reviewer` here when Rule 7 applies. `--base` only when the target is not the default branch.

### PR already open: update title and body

`gh pr edit` overwrites the title and body wholesale, so draft the full replacement, not a patch. Same rules and anti-patterns apply.

```bash
# A metadata-only edit does not push local commits.

gh pr edit --title "ABC-123: Add auth flow" --body-file /tmp/pr-body.md

gh pr view --json url,title   # confirm the update; return the url
```

## Gotchas

- `gh pr create` on a branch with no upstream: in a TTY it blocks on a "Where should we push?" prompt; from a non-interactive harness it aborts with `you must first push the current branch to a remote, or use the --head flag`. Either way, `git push -u origin HEAD` first.
- Non-interactive `gh pr create` needs both `--title` and `--body` (or `--fill`); without them it exits with `must provide --title and --body (or --fill) when not running interactively`. `--fill` copies commit messages verbatim, which is exactly the changelog body this skill exists to avoid.
- Quote the heredoc delimiter (`<<'EOF'`). Unquoted `<<EOF` lets the shell expand backticks and `$vars` in the body, corrupting the description or running commands.
- Two different failures look alike: on the default branch, `gh pr create` aborts with `must be on a branch named differently than "main"`; on a branch with nothing new against the base it fails with `No commits between main and <branch>`. The first needs a branch, the second a commit.
- A branch with an open PR fails `gh pr create` with `a pull request for branch ... into branch main already exists`. `gh pr view --json state` first; `OPEN` means `gh pr edit`. A `MERGED` or `CLOSED` result is a stale PR, so create a new one.
- Derive the Linear ID from the branch, uppercased: Linear's default branch format is `username/abc-123-title-slug`, so `mblode/abc-123-add-auth` gives `ABC-123`. Never guess an ID: Linear links the PR to whatever ID the title contains, and a wrong one moves someone else's issue.
- Plain `git diff` omits committed changes. Use the actual PR base with three-dot diff; do not assume `main`, especially for stacked PRs.
- Restructure commits before the first push. Force-pushing a rewritten branch under an open PR marks existing inline comments "outdated" and the reviewer loses their thread.

## Related skills

- `pr-reviewer`: run before creating to check the diff for bugs.
- `tidy`: applies fixes to the code in the diff; this skill edits only the PR and its commits.
- `pr-babysitter`: hand off after creation to watch CI, conflicts, and review comments.
- `autoship`: npm release pipeline (changesets, version PR, publish); "ship it" without release context routes here instead.

Maintenance only: `evals/evals.json` contains regression scenarios for changes to this skill; it does not load during a user task.

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related

Claude Prompt
Tighten-my-prose editing prompt
Claude Skill
Adversarial code-review skill for Claude
Claude Workflow
Deep-research workflow (fan-out + verify)
Claude Skill
Conventional-commit writer for Claude