GitHub's August 4 engineering post shows developers how to split a large AI-generated code change into a dependency-ordered stack of smaller pull requests. The workflow uses GitHub's gh stack CLI and an agent skill to create, submit, rebase, and synchronize the layers, giving reviewers a focused diff for each concern while keeping the full feature connected.
GitHub published an August 4 engineering guide for turning one large AI-generated code change into a stack of smaller, dependency-ordered pull requests. The workflow combines GitHub's stacked-pull-request interface with the open gh-stack CLI extension and a companion agent skill.
The problem is familiar to teams using coding agents: a single prompt can produce data-model, API, client, and user-interface changes in one diff. GitHub's worked example starts with a 1,700-line product-search change and divides it into four layers: catalog data, a search API, chat integration, and the grounded user interface. Each layer depends on the one below it, but reviewers see only the change for that layer.
A stack preserves both scope and order
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.
Changes still propagate through the stack
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.
Key Points #
- 1GitHub's workflow decomposes a large agent-generated feature into dependency-ordered pull requests, each scoped to one reviewable concern.
- 2The gh-stack extension handles stack creation, submission, rebasing, pushing, and synchronization, while an agent skill teaches coding agents the same workflow.
- 3Stacked pull requests improve review boundaries and ownership but do not replace tests, branch protections, or human approval.
Scoring Rationale #
The workflow gives coding-agent users a concrete, first-party method for decomposing large changes into reviewable units. Its impact is practical for software teams, though it is a workflow and tooling improvement rather than a new model capability.
Sources #
Primary source and supporting public references used for this report.
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.