stack-pull-requests

Plan, build, review, and merge stacked pull requests on GitHub.

723|93|Updated Nov 14, 2021
One-click install
npx skills add https://github.com/citypaul/.dotfiles --skill stack-pull-requests
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stack-pull-requests
Source: https://github.com/citypaul/.dotfiles/tree/main/claude/.claude/skills/stack-pull-requests
Command: npx skills add https://github.com/citypaul/.dotfiles --skill stack-pull-requests

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Large or dependent code changes are hard to review as one giant pull request, and splitting work across branches without a clear topology leads to broken intermediate states, lost tests, and merge chaos. This Skill decides whether planned vertical implementation work should ship as independent PRs or as an ordered stack, then governs the stack's design, verification, review, and merge.

Core Features & Use Cases

  • Stack vs. independent PR decision: Applies explicit gates and two counterfactual tests (trunk and flow lineage) to choose between single PRs, independent PRs, intra-slice stacks, and cross-slice stacks.
  • Delivery planning: Produces a Delivery Shape table mapping each PR boundary to its base branch, owned scope, verification route, and release state, with a whole-stack gate checklist.
  • Safe execution workflow: Guides bottom-up building, per-boundary TDD and mutation-evidence gates, bottom-up review, cascading rebases for lower-branch fixes, and all-or-nothing merges via GitHub's native gh stack tooling or unlinked dependent chains.
  • Use Case: A developer has a plan with three dependent vertical slices (sign-in, rejection handling, account lockout). The Skill determines a three-PR flow-lineage stack is justified, writes the delivery plan, and drives each PR from branch creation through gh stack merge.

Quick Start

Use the stack-pull-requests skill to decide whether my planned implementation slices should ship as independent PRs or a stacked PR chain, and write the delivery plan.

Frequently Asked Questions about stack-pull-requests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large pull request into a stack on GitHub?

First confirm each boundary is a whole vertical slice or a coherent intra-slice layer with its own verification. Then build bottom-up, target each PR at the branch below it, and use gh stack submit or gh stack link for native stacks, merging with gh stack merge.

When should I use stacked pull requests instead of independent PRs?

Use a stack only when slices have hard dependencies or deliberate flow lineage where upper work starts before lower PRs merge, and the review benefit outweighs rebase and CI cascade costs. If slices can target trunk and merge in any order, prefer independent PRs.

Does GitHub support stacked pull requests natively?

GitHub offers native stacked PRs and the gh stack CLI extension as a limited preview feature that may not be enabled for every repository. Verify repository access, current documentation, and gh stack --help before relying on preview-specific commands.

How do I handle review feedback on a lower PR in a stack?

Fix the change on the lower branch that owns it, then rebase or restack every branch above it and rerun affected checks. Never add an upstack workaround for a downstack defect, and push only with safe lease protection.

Should tests go in a separate final PR in a stack?

No. Each behavior's first test belongs in the PR that introduces that behavior, following RED-GREEN-REFACTOR within the boundary. A final all-tests layer separates tests from the behavior they protect and is explicitly disallowed.

What is the difference between a GitHub-native stack and a dependent branch chain?

A native stack is a remote GitHub object where CI, reviews, and rules evaluate against the stack trunk and prefixes merge atomically. An unlinked dependent chain only has PR base refs pointing at feature branches and keeps ordinary immediate-base workflow semantics.