Gh Create Pr

---
name: gh-create-pr
description: Create a GitHub PR from the current branch. Use when the user asks to "create a PR", "open a pull request", or "submit a PR".
allowed-tools: Bash
---

Create GitHub pull request(s) from the current branch. If this session touched multiple repos (check conversation context, plan issue, or ask the user), create a PR in each repo. Run steps 1-8 for each repo in sequence.

1. **Check state**: Run `git status` and `git branch --show-current`.
2. **Prepare a branch**:
   - Always fetch the latest base branch (main/master) first.
   - If the current branch is main/master, create a new branch off the freshly fetched base. Pick a short, descriptive branch name from the conversation context (e.g. `resource-tags-docs`). Move any uncommitted changes to the new branch.
   - Otherwise, rebase the current branch onto the freshly fetched base. If there are conflicts, stop and ask the user to resolve them.
3. **Handle uncommitted changes**: If there are uncommitted changes on the (now non-master) branch, ask the user if they want to commit first. Do not proceed until the working tree is clean.
4. **Push the branch**: Push the current branch to remote with `git push -u origin`.
5. **Gather context**: Read the git log for all commits on this branch since it diverged from the base branch. If a plan issue was referenced in this conversation, read it for additional context. Check for a PR template at `.github/pull_request_template.md` or `.github/PULL_REQUEST_TEMPLATE.md` in the repo. If one exists, use it as the structure for the PR description.
6. **Create the PR**: Use `gh pr create` with `--title`, `--body`, and `--web` (opens the browser with the PR pre-filled for editing). Do not use `--edit` (opens a terminal editor, unreliable).
   - A concise title (under 70 characters)
   - Body: for trivial PRs (single commit, simple change), a few plain-text sentences covering what, why, and how it was tested. For non-trivial PRs (multi-commit, multi-file, or complex changes), use three sections: `## What`, `## Why`, `## Tested`. Use bullet lists when listing multiple changes or test steps. Keep each section concise; reviewers read the diff for details.
     - Size the body to the change's consequence, not to the work behind it: a comment-only fix stays trivial however much investigation established it, while a one-line change to a widely-instantiated module is not.
     - Lead with what the change does for the reviewer rather than the method that found it, and leave evidence, log excerpts and ruled-out hypotheses in the plan issue.
     - Do not restate what the commit messages already say. The PR body adds the overarching why and how it was tested; the per-commit details are in the commits.
   - Link to the plan issue only if it is in the same repo as the PR. Do not link to plan issues in other repos.
   - Do not set reviewers or labels.
   - **Footer**: Check for `~/.claude/skills/gh-create-pr/pr-footer.md`. If it exists, append its content to the PR body, separated by `---`. Replace `{{model}}` with the full model slug including version and variant (e.g. "Claude Opus 4.8", "GPT-5.6 Sol").
7. **Post-creation**: If creating PRs across multiple repos, cross-link them in each PR description (e.g. "Related: owner/other-repo#N"). Do NOT cross-link from a public repo to a non-public repo.

Rules:
- Never create a PR without pushing the branch first.
- Keep the description concise. No empty boilerplate sections.