pr

PR

Create or update a pull request for the current branch.

Use ../write-pr/SKILL.md as the standards reference for PR titles, descriptions, release notes, API changes, code changes tables, and human-note preservation.

Workflow

1. Gather context:
   • Current branch: git branch --show-current
   • Working tree: git status --short
   • Existing PR: gh pr view --json number,title,url 2>/dev/null
   • Recent branch commits: git log main..HEAD --oneline 2>/dev/null || git log -3 --oneline
2. Check for overlapping work so we don't step on a teammate's toes:
   • List open PRs touching the same area: gh pr list --state open --json number,title,url,author,headRefName,updatedAt, and search for related work: gh pr list --search "<keywords>" --state open.
   • Compare their changed files against ours (gh pr diff <number> --stat) to judge real overlap, not just a shared filename.
   • If someone already has a PR open for this: prefer building on their work over racing it. Offer to base our branch on theirs, contribute a review or a follow-up commit, or hand our changes over. Only open a competing PR when the approaches genuinely diverge, and when we do, link to theirs and explain how ours differs so the choice is easy for reviewers.
   • Surface what you found to the user before proceeding when there's meaningful overlap.
3. Prepare the branch:
   • If on main, create a new branch with a descriptive name.
   • Commit relevant changes, excluding secrets and explicitly private content.
   • Push the branch to the remote. Never force push.
4. Run an initial review pass before asking a human to look. Spin out a few subagents in parallel over the diff (git diff main...HEAD), each with a focused lens, then fold their findings into concrete fixes:
   • Does the change actually solve the stated problem, end to end, rather than papering over a symptom?
   • Does it leave the codebase better than we found it — clearer names, no dead or duplicated code, no drive-by regressions?
   • Any weird abstractions, premature generality, or unnecessary code that a reviewer would flag? Prefer the smaller, more direct version.
   • Sweep the diff's added comments for slop, and run the stale-neighbour check, following ../write-pr/SKILL.md § The comment sweep. On an update, this catches whatever the branch grew since the PR was opened, which on a long-lived branch is most of it.
   • Fix what's clearly worth fixing so the human review starts from a strong diff.