Gh Create Pr

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.