sync-prs

/sync-prs: bring open PRs up to date

Load .claude/harness/profile.md for REPO, DEFAULT_BRANCH, LINT_CMD, BUILD_CMD, UNIT_TEST_CMD, E2E_TEST_CMD.

Not for

Opening, retargeting, or merging PRs. Review comments (use /pr-comments). PR bodies (use /pr).

Invariants, restated as gates

These come from the always-on rules and the memory store. Do not redefine them here, just do not break them.

• Preserve the branch's existing commits. A rebase replays them; do not squash them into one, and do not amend to reduce the count.
• git push --force-with-lease on the SAME branch ref, because a rebase rewrites the commits it replays and there is no non-force way to publish that. This is the one sanctioned force-push: it is inherent to rebasing, not a commit-count preference. A force-push does not close a PR and approvals survive it here. A branch RENAME does close it, so never rename a branch that heads an open PR.
• Confirm git branch --show-current as its own step before any rebase.
• Never --no-verify, never weaken a test to get green.

Step 1: enumerate and build the graph

gh pr list --author @me --state open \
  --json number,headRefName,baseRefName,isDraft,mergeStateStatus,mergeable --limit 50

The base is baseRefName per PR. Read it; do not assume the default branch. Some PRs sit on an epic branch, and "sync with development" for those means sync the epic first, then rebase the PR onto the epic.

A PR is a stack child when its baseRefName equals another open PR's headRefName:

gh pr list --author @me --state open --json number,headRefName,baseRefName --jq '
  . as $p
  | map(. as $c | {n:$c.number, head:$c.headRefName, base:$c.baseRefName,
                   parentPR: ([$p[] | select(.headRefName == $c.baseRefName) | .number] | first)})
  | map("PR \(.n)  head=\(.head)  base=\(.base)  parent=\(.parentPR // "none")") | .[]'

Step 2: dry-run report, before touching anything

git fetch origin first, then per PR: