Stacked pull requests are GA, and they fit agent-sized diffs

GitHub made stacked pull requests generally available on 6 October. It’s on all github.com plans, and the changelog says it will ship in an upcoming GitHub Enterprise Server release. If you’ve been handing agents big tasks and getting back 2,000-line diffs, this is the feature aimed at that.

What a stack is

A stack is a chain of PRs where the bottom one targets main and each one above it targets the branch below. Reviewers see only the diff for their layer. You can keep building upward without waiting for the lower PRs to merge, and the docs say merging goes bottom to top, with higher PRs retargeted as lower ones land.

Two constraints worth knowing: every branch has to live in the same repository (no cross-fork stacks), and GitHub Desktop doesn’t support them. Branch protection rules apply to every PR in the stack, including mid-stack ones, and CI for PRs runs on all of them.

The CLI

The workflow runs through the gh stack extension. GitHub’s tutorial lists GitHub CLI 2.90.0 or later and Git 2.20 or later as prerequisites.

gh extension install github/gh-stack
gh stack init user-model
# ...commit the schema and migration...
gh stack add user-endpoints
# ...commit the routes...
gh stack submit

init starts the stack, add puts a new branch on top, and submit pushes every branch and creates or updates the PRs. After a reviewer asks for a change on a lower layer, fix it there and run gh stack rebase --upstack to carry it through the layers above. gh stack merge can land one or several PRs at once, with --squash, --merge or --rebase. A rebase conflict exits with code 3, which is handy if you script any of this.

Why it matters for agent output

Agents are good at producing a complete feature and bad at producing a feature a human can review in one sitting. Asking the agent to build in layers fixes the second problem at the source. GitHub’s tutorial on stacking AI-generated code is written around Copilot CLI, but the shape isn’t tool-specific. It suggests planning the layers first, with prompts like asking for a layered approach ordered by dependency, then building only the first layer before moving on.

The same tutorial is blunt about the risk: a mistake in a bottom layer propagates to everything above it, so review the foundation hardest and self-review each layer before requesting human review. That lines up with how fresh-context review works well in practice. A small, self-contained diff is something a second agent can check properly, as we covered in the fresh-context reviewer post .

If you use Claude Code or Codex instead, nothing stops you running the same plan-then-build-one-layer routine and calling gh stack yourself. The tutorial also shows installing a skill with gh skill install github/gh-stack. I haven’t confirmed how other agents pick that up, so check before relying on it.

What changed at GA

Per the changelog, approvals now survive when unchanged layers are rebased after the base branch moves, and replacement commits keep their cryptographic signatures. Stacks retarget automatically when a base branch is deleted, and a stack now merges as a single merge group. Auto-merge is still rolling out over the coming weeks. There’s also a stacked action on the pull_request webhook, so automation can react to stack membership, and gh stack now works with Git worktrees, which pairs naturally with parallel agent sessions.

The preserved approvals are the practical win in my view. Every fix to a lower layer forces a rebase of everything above it, and you don’t want that to cost you reviews on layers you didn’t touch.

Try it on your next agent task: ask for a layer plan before any code gets written, and reject the plan if a layer looks too big to review in ten minutes.