garyld1962 /pr — Pull Request Lifecycle
Purpose: Automate the full PR lifecycle from branch creation through optional merge.
When to Use
- Implementation is complete and ready for review/merge
- You want branch + commit + checkpoint + push + PR creation in one flow
- Squash-merge is the repo's standard and you want optional auto-merge
When NOT to Use
- Repo has project-specific release steps beyond a PR — use
/ship - You only need the quality gate — use
/checkpoint - Work isn't ready — finish implementation and tests first
Arguments
--skip-checkpoint— skip the /checkpoint quality gate--merge— auto-merge after PR creation (skip merge prompt)--no-merge— skip merge prompt entirely (PR stays open)--draft— create PR as draft
Workflow
Execute these steps in order. Stop and report if any step fails.
Step 1: Branch Check
git branch --show-current
If on main (or the repo's default branch):
- Ask the user for a branch name
- Create and switch to the new branch:
git checkout -b <branch-name>
If already on a feature branch, continue.
Step 2: Stage & Commit
Check for unstaged or staged changes:
git status
git diff HEAD
If there are changes:
- Stage relevant files:
git add <files>(reviewgit statusfirst — avoid staging untracked junk like .exe, .zip, Zone.Identifier files) - Generate a commit message from the diff (follow Conventional Commits if the project uses them, check recent
git log --oneline -10for style) - Show the commit message to the user for approval
- Commit:
git commit -m "<message>"
If no changes and no new commits ahead of origin, stop — nothing to PR.
Step 3: Run /checkpoint (unless --skip-checkpoint)
Invoke the /checkpoint skill to run the quality gate (lint, typecheck, tests, reviews).
- If checkpoint fails: stop and report failures. Do not continue to push.
- If checkpoint passes: continue.
Step 3.5: Security Quick Check (when warranted)
If the diff touches authentication, authorization, input handling, rendering of user content, or persistence (SQL, ORM, file I/O, deserialization), apply the security-quick-check rubric (_internal/security-quick-check/SKILL.md).
Skip when the diff is purely cosmetic (formatting, comments, docs, type-only changes) or strictly internal logic with no trust boundary involvement.
- If the rubric reports findings: stop and address them before push.
- If clean: continue.
Step 4: Push
git push -u origin HEAD
If the remote branch doesn't exist, this creates it. If push fails (e.g., rejected), report the error.
Step 5: Generate PR Content
Gather context for the PR:
git log origin/main..HEAD --oneline
git diff origin/main..HEAD --stat
Auto-generate:
- Title: Short (under 70 chars), derived from branch name or commit messages
- Body: Using this format:
## Summary
- <bullet 1: what changed>
- <bullet 2: why>
- <bullet 3: notable details, if any>
## Test plan
- [ ] <test item 1>
- [ ] <test item 2>
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Show the title and body to the user for approval before creating the PR. Wait for confirmation or edits.
Step 6: Create PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
Add --draft flag if --draft argument was passed.
Report the PR URL to the user.
Step 7: Merge Decision
- If
--no-mergewas passed: done. Report PR URL. - If
--mergewas passed: proceed to merge immediately. - Otherwise: ask the user "Merge this PR now?"
If merging:
gh pr merge <pr-number> --squash --delete-branch
git checkout main
git pull origin main
Report: "PR merged and branch cleaned up."
If not merging: "PR created and ready for review." Report the PR URL.
Error Handling
- Push rejected: Report the error. Suggest
git pull --rebase origin <branch>if behind remote. - PR already exists: Report the existing PR URL. Ask if user wants to update it.
- Merge conflicts: Report conflicts. Do not force-merge. Ask user to resolve.
- Checkpoint fails: Stop before push. List failures clearly.
Notes
- This skill always uses squash merge to keep main history clean.
- After merge, both remote and local feature branches are deleted.
- The PR body is always shown for approval — never auto-submitted without user seeing it.