GitHub Stacks Brings Stacked PRs to Copilot Agents

There's a problem that anyone who has handed a feature to an AI coding agent has hit, usually around the moment they open the resulting pull request and feel their stomach drop. The diff is enormous. Every layer of the feature—data fetching, business logic, UI—is jammed into one PR, and the review process transforms from "thoughtful code evaluation" into "archaeological dig." You're not reviewing code anymore. You're just trying to figure out where one thing ends and another begins.

GitHub's new Stacks feature, demoed this week in a video from the GitHub channel, is a direct response to that problem. The pitch is straightforward: instead of one massive AI-generated PR that nobody wants to review, you get a chain of smaller, sequenced PRs—each building on the last, each independently reviewable, each running its own CI checks.

The mechanism is a two-part installation: the gh-stack CLI extension and a corresponding GitHub Copilot "skill" that lets the agent actually invoke stacking behavior. Once both are in place, Copilot can not only write code but also orchestrate the PR structure around that code. That's a meaningful expansion of what a coding agent can do inside a repository.

What the Demo Actually Shows

The demo walks through building a trend tracker application—something to monitor which words are gaining traction online. It's a practical enough example: three distinct feature layers (data fetching via PyTrends, chart visualization, multi-trend comparison) that could plausibly arrive as one impenetrable monolith from an AI agent given a single prompt. Instead, a single detailed prompt instructs Copilot to create three separate PRs, structured as a stack, each adding one layer of functionality.

The result on the GitHub side is visually clean. Each PR in the stack shows the full stack context—you can see where you are in the sequence, what's above and below, and which other PRs are ready to merge. The demo shows CI running on every individual PR in the stack, which means each layer of the feature is tested independently before anything touches main.

"GitHub Stacks make it easier for you and anyone on your team to review PRs, not only created by a human, but also by coding agents," the demo explains. That framing matters. The workflow isn't being sold purely as a developer productivity tool—it's being positioned as a necessary piece of infrastructure for a world where agents are generating code at a pace humans can't review in traditional PR-sized chunks.

The rebasing behavior is worth noting: each subsequent PR in the stack is automatically rebased on the PR below it, so the change set for any given PR reflects only what that layer adds. You're not reviewing the entire accumulated diff every time—just the incremental piece. This is the core value proposition of stacked PRs as a workflow, and it's what makes large features reviewable without requiring reviewers to hold the entire feature in their head simultaneously.

The Skill Architecture Is the Interesting Part

What's technically novel here isn't stacked PRs themselves—the concept has existed in developer workflows for a long time, and plenty of teams have built manual processes around it. What's new is the agent-native implementation: a Copilot "skill" that gives the agent the ability to call gh-stack commands directly.

Skills, in Copilot's architecture, are essentially tool integrations—they tell the agent what external capabilities it has access to and how to invoke them. Installing the gh-stack skill globally means any Copilot session can use it; the demo shows confirming installation by asking Copilot directly whether the skill is available, and the agent responds by describing what it can now do with the Stack CLI.

This is worth sitting with for a moment. The workflow being demoed isn't "developer uses tool to break up code." It's "developer prompts agent; agent writes code, creates branches, opens PRs, and structures the entire PR stack—autonomously." The human's role shifts from doing the work to reviewing the output of the work. The demo closes with a one-click merge of the full stack: "The stack is going to go ahead and be merged, and then we should be able to successfully have all of our changes available for us to use."

That's a significant compression of the loop between feature idea and merged code. Whether that compression is uniformly good is a question worth holding onto.

The Review Problem Isn't Solved, It's Redistributed

Stacked PRs make large AI-generated changesets more navigable. They don't necessarily make them more understandable. A reviewer still has to evaluate whether the PyTrends data-fetching implementation is sound, whether the chart layer introduces any state management issues, whether the multi-trend comparison is architected in a way that won't create problems six months from now.

What stacking does is give reviewers a fighting chance by removing the cognitive overhead of parsing a massive undifferentiated diff. Instead of one PR with 600 changed lines across eight files, you get three PRs of 200 lines each, with clear conceptual boundaries. That's genuinely useful. Any reviewer who has stared at a monolithic AI-generated PR knows the particular despair of trying to hold the entire thing in working memory.

But the review skill required doesn't decrease—it's just applied in smaller chunks. The demo is optimistic about what CI coverage provides: "CI is going to run on every single PR in that stack." Tests passing is necessary but not sufficient for good code review, a point GitHub would probably agree with if you pushed them on it. The tool creates better conditions for review; it doesn't replace judgment.

There's also a question this feature sidesteps: what happens when the AI's architectural decisions across the stack are wrong? If the data fetching layer in PR 1 makes an assumption that causes problems in PR 3, a reviewer catching that in PR 3 has to reason backward through already-merged or in-flight code. Stacked PRs impose a linear review order on code that may have non-linear dependencies. That's a tradeoff, not a flaw, but it's worth understanding before you're in the middle of it.

Where This Fits in the Larger Picture

GitHub releasing this as a "skill" rather than a core Copilot feature tells you something about the current state of agent tooling: the ecosystem is still being assembled, capability by capability. The extensibility model—install a CLI extension, attach it as a skill, grant the agent access—is flexible enough that you can imagine similar integrations for deployment, monitoring, documentation generation. The stacking use case is the demo; the architecture is the announcement.

"This is a short example of how to use the brand new GitHub Copilot Stacks feature," the demo notes at the close. Short, yes—but the implications extend further than six minutes can fully explore.

The honest version of this feature's promise is that it makes the human-in-the-loop workflow for AI-generated code more sustainable. Reviewers have been quietly drowning in AI output, and the informal solution has been to either rubber-stamp large PRs or avoid using agents for anything complex. Neither is good. Stacked PRs are a structural answer to a structural problem.

Whether that answer scales as agents get more capable—generating not three-layer stacks but thirty—is the question that will matter in about eighteen months.

---

Dev Kapoor covers open source and developer communities for Buzzrag.