GitHub just shipped a private preview of Stacked PRs, and it's exactly what it sounds like: native support for breaking giant pull requests into a chain of small, focused ones that build on each other. Each PR in the stack gets reviewed independently, but they all land together on main. The feature comes with a CLI tool called gh stack that handles branch creation, cascading rebases, and pushing changes. There's also an AI integration angle that matters: run npx skills add github/gh-stack and your AI coding agents can learn to work with stacks natively. The Skills package is a playbook that agents like Copilot or Cursor can follow to create, manage, and merge stacked PRs without human hand-holding. If your AI coding agent can't handle stacks yet, GitHub just gave you a way to fix that. You can pair this with tools that treat agents like background processes. Graphite and Aviator just got a problem they can't code around. Both startups built their businesses on solving GitHub's lack of native stacked diff support. Now GitHub is eating their lunch. Classic platform risk. Build on someone else's platform long enough, and eventually they'll absorb your feature set. Graphite and Aviator still have some advantages in advanced automation and CLI ergonomics, but for many teams, good enough and native beats better but external. Over on Hacker News, the reaction splits along familiar lines. People who've used stacked diffs in Phabricator or Mercurial are happy to see this come to GitHub at last. Monorepo teams and anyone working on long-running features will benefit. But some developers argue PR stacks are the wrong abstraction entirely. They'd rather see better commit-level management. Tools like Jujutsu take a different approach, treating commits as the primary unit of work. The argument goes that stacks are just a workaround for git's limitations, not a feature in their own right. That debate won't be settled by this launch.