GitHub Details Agent Workflow for Stacked Pull Requests

The official gh-stack repository defines a stack as an ordered list of branches rooted in a trunk branch such as main. Developers initialize a stack with gh stack init, add dependent branches with gh stack add, and create the linked pull requests with gh stack submit. The repository says submission sets each pull request's base to the branch immediately below it, so each review stays limited to that layer.

GitHub's guide also describes installing a gh-stack skill so a coding agent can follow the same branch and pull-request structure. In the example, separate agents own the data, backend, and frontend layers. That division does not prove that the resulting code is correct; it makes ownership, tests, and review questions easier to bind to a smaller unit of work.

Stacking does not eliminate dependency maintenance. When a reviewer requests a change near the bottom, the branches above it must be rebased. GitHub's guide recommends a local gh stack rebase when commit signing matters, followed by gh stack push and gh stack sync to propagate the update and refresh pull-request state. It warns that a web-based rebase resets the committer to the person who clicked it and does not sign the resulting commits.

For engineering teams, the practical value is review structure rather than faster code generation. Smaller diffs can be routed to the appropriate data, backend, or interface reviewer, while the stack map preserves the feature's dependency chain. Teams still need branch protections, tests, and human approval on every layer; the workflow changes how agent output is packaged for review, not whether it is trustworthy.