mma

name	mma
description	Merge main into open PR branches.
user-invocable	true
allowed-tools	["Bash","Read","Edit","Write","Agent"]

mma

Repo-wide fan-out of sync-pr-branch: instead of resyncing one branch, resync every currently-open PR in the repo against main (and each PR's own remote), so a burst of merges into main doesn't leave the rest of the queue stale and conflict-prone.

This is not a duplicate of sync-pr-branch — it's an orchestration layer on top of it. The per-branch mechanics (fetch, merge origin/main, merge origin/<branch>, resolve conflicts, run checks, push) are unchanged; only sync-pr-branch owns that logic. Keep it that way — if the per-branch steps ever need to change, fix them in sync-pr-branch and this skill inherits the fix for free.

When this fires

• "merge main into all pr branches", "sync every open PR with main", "mma", "resync the whole queue with main".
• After a run of merges to main (e.g. finishing an ardia/gia sweep) — proactively, even without being asked, since every remaining open PR just fell further behind.

The procedure

1. List every open PR in the repo (mcp__github__list_pull_requests / gh pr list). Note each PR's number and headRefName.

2. Check whether main is actually ahead before touching anything:

   git fetch origin main
   

   For a PR whose origin/main is already an ancestor of the branch tip (git merge-base --is-ancestor origin/main <branch-tip> returns true), skip it — main is already incorporated; nothing to merge.

3. Resync each PR branch, one at a time — do not parallelize the push step. This is the shared-runner exception in practice: several PRs is decomposable, but each push triggers that PR's own CI and @claude review bot on a runner the whole repo shares, and parallel pushes make per-PR status illegible and can race concurrency groups against each other (see gha's own claude-review-<PR>/cancel-in-progress note for what that race looks like in practice). Work the queue serially, or cap concurrency low enough that no two pushes land in the same few seconds.

   For each PR branch, in its own worktree (never the shared main checkout — see the per-repo memory file for this repo's worktree conventions if it has one). Pass -b <branch> so the worktree gets a real local branch instead of detached HEAD — sync-pr-branch's own step 1 checks git branch --show-current and halts if that's empty:

   git worktree add -b <branch> .claude/worktrees/pr-<N> origin/<branch>
   

   cd doesn't persist across separate tool calls — run subsequent commands with that path ((cd .claude/worktrees/pr-<N> && git ...), or an absolute path) rather than assuming a prior cd carried over.

   Then run exactly the sync-pr-branch procedure against that branch: fetch, merge origin/main, merge origin/<branch>, resolve any conflicts (see resolve-conflicts / rc), run the repo's pre-commit checks, push.

   Only merge origin/main and the PR's own — never another open PR's branch. Cross-PR changes stay out of scope here, same as 's own note.

Notes

• You can parallelize the local fetch-and-merge groundwork (step 3's setup, before any push) within a single agent loop when the queue is large — but keep the pushes themselves sequential per step 3's shared-runner reasoning. This skill doesn't define a cross-agent coordination mechanism, so don't dispatch one background agent per PR and assume they'll serialize their pushes on their own; either push from a single loop, or add an explicit handoff (a queue, a lock file) before fanning the push step out across agents.
• This skill only touches branches with an open PR. A stale local worktree left over from a merged PR isn't in scope — that's the post-merge skill's job.
• If every open PR is already current with main, say so and stop; nothing to do is a valid, common outcome right after this same skill last ran.