GitHub’s stacked pull requests preview gives teams a native way to break one large code change into a chain of smaller dependent pull requests. The docs position the feature around review and mergeability: each pull request in the chain can be reviewed and merged independently.
That matters even more in agent-assisted development than in manual development. Agents are good at producing broad patches. Teams are still bottlenecked by understanding, reviewing, testing, and safely merging those patches. A stack makes the work legible: foundation change first, dependent change next, product surface after that.
GitHub’s docs cover creating stacked pull requests with the gh stack extension or directly on GitHub, restructuring stacks, rebasing branches, merging from the bottom up, merging individually, merging contiguous groups, and optimizing GitHub Actions for stack-aware CI.
The important product move is that the stack is not a private convention hidden in branch names. It becomes a review object with documented CLI behavior, web review, merge strategy, and CI metadata.
New Runtime Read
The scarce resource in coding-agent workflows is not code generation. It is review bandwidth.
Stacked PRs are a useful answer because they make a large agent output decomposable without pretending the pieces are independent. The better default for agent work is not “one giant PR with a heroic reviewer.” It is a chain where each layer has its own diff, evidence, CI result, and merge decision.