Shipping large agent changes as GitHub Stacks

Give an agent a large feature and it will happily produce a large pull request. The code may even be good. The review will not be, because nobody reads two thousand lines with the same attention they give two hundred.

Stacked pull requests solve this. Instead of one big PR against main, you ship a chain: the first PR targets main, the second targets the first, the third targets the second. Each one is small, each one is reviewed on its own, and they merge in order.

Why stacks fit agent work so well

Agents naturally work in layers: types and data first, then the logic that uses them, then the UI, then the polish. A stack mirrors that structure exactly. Reviewers get to approve the foundation before reading the code that depends on it, and a problem in layer two does not block review of layer one.

How it works in Dispatcher

When you execute a task, you choose how it ships:

• Single PR, the default, for most tasks.
• Stacked PRs, for changes too big for one review.

The choice is made when the workspace is created. A stacked workspace still uses one worktree: the stack is a sequence of branches in the same checkout, which is how GitHub's gh stack tooling expects to work.

When stack mode is on, Dispatcher gives the agent the official gh-stack skill as part of its context, so it knows how to build the stack layer by layer without needing anything installed separately. Every stack action in the UI maps to a non-interactive gh stack command, because an agent waiting on an interactive prompt will simply hang.

Once the layers exist, the stack map shows each branch, its pull request, and its base. You can review layer by layer and merge the stack from the same place.

Writing a task that stacks well

Stacks work best when the task names the layers up front:

Ship as three PRs: (1) route map and types, (2) the NavGroup component and its tests, (3) keyboard navigation for the settings sidebar.

The agent follows the plan, and reviewers know before they open the first PR what the next two will contain.

When not to stack

Stacks add ceremony. For a change that fits comfortably in one review, a single PR is faster for everyone. We reach for stacks when a diff passes a few hundred lines or touches several layers of the system at once.