GitHub stacked pull requests: reviewing agent changes after a mid-stack revision

Start with the revision reviewers will request

GitHub released stacked pull requests on October 6, 2026, coordinating dependent changes through review and merging across all github.com plans. Consider an agent building an export feature: persistence, service rules, an API, and an interface arrive as separate pull requests (PRs). Then a reviewer changes the service’s quota behavior halfway through the stack. The useful test is whether reviewers can trace that decision through every dependent layer. Sources: GitHub

Each PR targets the preceding branch, with the bottom PR targeting trunk. Required reviews, checks, and code ownership requirements follow that trunk. Ownership-file edits in a lower layer do not change ownership requirements above it. GitHub also supports landing a stack through the merge queue as one merge group. Enterprise Server support was planned without a specified version, and stack auto-merge was still rolling out as of October 14, 2026. Sources: GitHub, GitHub Docs

Split the feature around reviewable decisions

For the proposed export service, use four layers with explicit responsibilities. Put migration tests beside the model, authorization tests beside the service, and integration tests beside the API. Avoid postponing all tests to the final PR, where they cannot support earlier decisions. The table below outlines an illustrative design, with each layer answering a different review question.

Before implementation, require each PR to explain its decision, name prerequisites, and identify behavior deferred to later layers. The stack description should explain the complete feature and shared requirements, such as preventing duplicate exports. Assign feedback to the layer that owns the behavior, and designate a person to review the integrated feature. Directory boundaries alone are a weak organizing principle when understanding a small diff still requires reconstructing the whole system.

The official extension requires GitHub CLI 2.0 or later and Git 2.36 or later. Its documented workflow creates dependent branches and submits PRs with the preceding branch as each base. Keep these branches in the same repository because native stacks do not support cross-fork dependencies. Install the extension with the first command below, then implement and commit each layer with its tests before adding the next. Sources: GitHub Docs, GitHub

gh extension install github/gh-stack

gh stack init export-model
# Implement, test, and commit the model.

gh stack add export-service
# Implement, test, and commit the service.

gh stack add export-api
# Implement, test, and commit the API.

gh stack add export-ui
# Implement, test, and commit the UI.

gh stack push
gh stack submit

Trace a service change through dependent layers

Make the review request concrete: replace a generic quota failure in the second PR with a typed result containing retry information. Before changing anything, record branch commit identifiers, PR bases, approvals, required checks, and the end-to-end result. Those records help distinguish the requested behavior change from effects introduced while updating dependent branches.

Check out the service layer, update its behavior and tests, and commit the revision. The following sequence rebases from the current branch toward the top and pushes the updated stack. A conflict-free rebase shows that the history operation succeeded. Separately test whether the API, worker, and interface still express the intended behavior. Sources: GitHub

gh stack checkout export-service
# Change the service and its tests; commit.

gh stack rebase --upstack
gh stack push

1. Verify quota rejection and retry information in the service layer.
2. Check the API’s status and response body, plus the worker’s retry behavior.
3. Check that the interface displays retry information and retries do not create duplicate exports.
4. Inspect every layer’s diff for changes outside its stated responsibility.
5. Record approval retention and dismissal separately for each PR.

If conflicts occur, resolve them in the layer where they appear and inspect the resulting diff before continuing. The extension’s documentation provides commands to continue the rebase or abort it and restore the pre-rebase branch state. The two commands below are alternatives: choose whether to proceed with the resolution or abandon the rebase. Sources: GitHub

gh stack rebase --continue

gh stack rebase --abort

Separate retained approvals from renewed review

GitHub says server-side Rebase stack retains approvals when an otherwise unchanged stack is updated after its base advances. That includes repositories configured to dismiss stale approvals. Test this scenario separately from the quota revision, recording approvals before and after the rebase with stale-review dismissal enabled. An upper layer may need renewed human scrutiny even when the behavior change lives below it. Sources: GitHub

This walkthrough is a proposed evaluation; the research included no repository experiment or controlled benchmark of the generally available feature. It also left unresolved how GitHub identifies an unchanged diff and how preservation interacts with approval of the most recent reviewable push. Capture the resulting diff, tests, and review state after resolving an API-layer conflict. Use those records to guide reassessment of changed behavior.

GitHub says server-side Rebase stack creates signed replacement commits while preserving original authorship. Automatic rebases after partial merges sign replacements when rules require signatures or any original commit was signed. Inspect both the author identity and the displayed signer, which answer different questions. For a local rebase, check local signing configuration and actual signature verification. After partially merging the bottom PR, inspect the remaining branch bases, replacement signatures, and checks. Sources: GitHub

Validate the merge group and account for CI work

For stacks targeting main, GitHub documents that a pull_request workflow filtered to main runs for every layer. Queue validation requires GitHub Actions checks to respond to merge_group; PR events alone are insufficient. The event reference distinguishes merge_group from pull_request and push. The configuration below supplies both triggers. Its event example comes from Enterprise Server documentation and establishes event configuration, not native-stack availability on that server version. Sources: GitHub Docs

on:
  pull_request:
    branches: ["main"]
  merge_group:
    types: [checks_requested]

Before merging, the selected PR and every lower PR must satisfy requirements, and interbranch history must be linear. Removing or ejecting a queued PR also removes the PRs above it. Queue groups may exceed their configured maximum by up to 50% to accommodate a stack; larger stacks move intact into the next group. Test integration with a failure that appears only when the complete feature meets current main. Preserve the merge-group commit identifier and check results, and separately test dependent removals by ejecting a middle PR. Sources: GitHub Docs

Atomic landing supports merge, squash, and rebase; merge and squash produce one corresponding commit per PR. Compare final history under the repository’s permitted methods, including a partial squash merge followed by continued work. Budget for repeated continuous integration (CI) work. If four layers each run a suite costing C, their runs cost approximately 4C before retries and queue checks. This illustrative calculation makes runner minutes and queue latency useful companions to review-time measurements. Sources: GitHub Docs

Coordinate worktrees before agents rewrite history

gh-stack v0.2.0, released October 2, 2026, added repository-wide stack tracking and cross-worktree operations. Branches can occupy separate worktrees, with operations executing in the checkout that owns each branch and recovery available from another worktree. The extension’s documentation says dirty or busy owning worktrees stop operations. The extension neither automatically stashes changes nor creates or removes worktrees. Its mutation locks coordinate gh-stack processes, not arbitrary Git commands or editors. Sources: GitHub

Assign API and interface work to separate worktrees and agree on a pause before rewriting affected branch history. Repeat the service revision with clean, idle worktrees, then with uncommitted interface edits, recording the stop and recovery behavior. Compare similar features using total human review minutes, full-feature completion time, re-review effort, escaped defects, CI minutes, and conflicts. Count the complete export feature as one delivery so that splitting it into more PRs does not itself look like a productivity gain.