create-pr

name	create-pr
description	Create a GitHub pull request from the current branch. Use when user asks to create a PR, open a PR, submit a PR, push and create PR, or similar pull request workflows. Activates for phrases like "create a PR", "open a pull request", "submit PR", "push and PR", "make a PR for this", "open a draft PR".
argument-hint	[title]

Create Pull Request

Create a draft GitHub pull request from the current branch. The PR description comes from the git commit messages with no AI attribution.

Step 1: Run the Safety Check

Run the safety check script bundled with this skill. The script output below was generated at skill load time. Parse and follow it.

!for d in ~/.claude/skills/create-pr ~/.agents/skills/create-pr; do [ -f "$d/safety-check.sh" ] && bash "$d/safety-check.sh" 2>&1 && exit 0; done; echo "ERROR: safety-check.sh not found. Perform manual checks (see below)."

You MUST parse and follow the script output above. The output uses a structured format:

• ERROR: lines mean a blocking problem. Follow the INSTRUCTION: that follows. Do not proceed past step 1.
• WARNING_ lines are non-blocking but require user confirmation before continuing. Follow the INSTRUCTION: that follows each warning.
• SAFETY_CHECK=PASSED means all checks passed. Continue to step 2.

The output also provides BRANCH=, BASE=, REMOTE=, COMMITS_AHEAD=, and COMMIT_LOG: values. Use these in subsequent steps.

If the script cannot be executed (permissions, sandbox restrictions), perform the checks manually:

1. Verify you're in a git repo
2. Verify gh is installed and authenticated (gh auth status)
3. Get the current branch (git branch --show-current) — must not be the default branch
4. Confirm the remote URL (git remote get-url origin) with the user
5. Verify there are commits ahead of the base branch
6. Collect commit messages for the PR description

Step 2: Confirm the Remote

Show the user the REMOTE= value from the safety check output. Ask for confirmation that this is the correct repository to push to. The goal is to prevent accidentally pushing to a fork, upstream, or unrelated repo.

If the user has already confirmed this remote earlier in the same conversation, skip re-confirmation.

Step 3: Derive PR Title and Description

Build the PR title and description from the commit messages in COMMIT_LOG:.

Writing Style

Follow the same conventions as the git-commit skill for writing style: imperative mood, concise summary, "why" over "what". The PR description should read like well-written commit messages.

Single Commit

• Title: the commit subject line.
• Description: the commit body (everything after the subject).

Multiple Commits

• Title: use the first commit's subject line (typically the most descriptive).
• Description: merge the body text from all commits into a cohesive description. Keep the same writing style. Remove duplicate information across commits.

Cleanup Rules

Remove these patterns from the PR description before creating the PR:

• Lines matching Co-Authored-By: (case-insensitive)
• Lines matching Signed-off-by: (case-insensitive)
• Lines containing Generated with or generated by (case-insensitive)
• Any AI attribution or tool-generated footers
• Trailing blank lines

The PR must read as if a human wrote it. No AI fingerprints.

Step 4: Pre-Flight Review

Before creating the PR, do a quick sanity check on the diff and PR content. If you can spawn a subagent, delegate this review. Otherwise, do it inline.

What to Check

Run git diff <base>..HEAD and review:

1. Does the PR title accurately describe the change?
2. Does the description explain the "why"?
3. Are there files that shouldn't be included (env files, credentials, large binaries, unrelated changes)?
4. Are there obvious issues in the diff (debug prints, commented-out code, TODO markers left behind)?

If anything needs attention, present the findings to the user and ask whether to proceed or fix first.

Subagent Prompt (If Delegation is Available)

Spawn an Opus-class subagent with:

You are reviewing a pull request before it's created. This is a quick
pre-flight check, not a full code review.

PR TITLE: <title>
PR DESCRIPTION:
<description>

DIFF:
<output of git diff <base>..HEAD>

Check for:
1. Does the PR title accurately describe the change?
2. Does the description explain the "why"?
3. Are there any files that look like they shouldn't be included (env files,
   credentials, large binaries, unrelated changes)?
4. Are there any obvious issues visible in the diff (debug prints left in,
   commented-out code, TODO markers)?

Report in under 150 words. Format:

VERDICT: GOOD / NEEDS ATTENTION
NOTES: [brief findings, if any]

Step 5: Push and Create the PR

Push the Branch

git push -u origin <branch>

Create as Draft

Try creating a draft PR first:

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

If this fails because the repository doesn't support draft PRs (error message typically contains "Draft pull requests are not supported"), retry without --draft:

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

User-Provided Arguments

If the user passed a title as $ARGUMENTS, use that as the PR title instead of deriving it from commits.

Step 6: Report

Show the user:

1. The PR URL returned by gh pr create.
2. Whether the PR was created as draft or regular.

What This Skill Does NOT Do

• Run tests. Tests should pass before invoking this skill.
• Run code review. Use the code-review skill separately.
• Commit changes. Use the git-commit skill first.
• Merge the PR.