Stacked pull requests with GitHub's native gh-stack CLI: when to stack, how to build/submit/sync a stack, responding to mid-stack review feedback, and Hamster-specific rules (dev base, one migration per PR, merge commits). Use when a change is too big for one reviewable PR or when planning multi-wave delivery.
Pro scans all 3 files and shows the line behind each finding
Scanned 9/27/2026
npx -y skills add gethamster/skills --skill gh-stack --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Gh Stack?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/gethamster-gh-stack)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
name: gh-stack
description: "Stacked pull requests with GitHub's native gh-stack CLI: when to stack, how to build/submit/sync a stack, responding to mid-stack review feedback, and Hamster-specific rules (dev base, one migration per PR, merge commits). Use when a change is too big for one reviewable PR or when planning multi-wave delivery."
version: "1.0.0"
category: "Development"
---
# gh-stack — Stacked Pull Requests
Break one large change into a chain of small, dependent PRs — each reviewable on its own, all merging atomically. `gh stack` is GitHub's native stacked-PR tool (private preview): the bottom PR targets the trunk, each PR above targets the branch below it, and GitHub renders a stack map on every PR in the chain.
## When to Use
- A change would land as a >1k-line PR that decomposes into ordered layers (schema → services → UI → tests).
- Multi-wave plan/ship work where waves are independently reviewable but sequentially dependent.
- You want reviewers to see only the delta of one layer, not the cumulative diff.
**When NOT to stack**: independent changes (separate normal PRs), single-layer changes, or hotfixes. A stack whose PRs don't genuinely depend on each other is just review overhead.
## Prerequisites
- `gh` CLI ≥ 2.0 (authenticated) and git ≥ 2.20.
- Private-preview access enabled on the repo (sign-up: https://gh.io/stacksbeta). Exit code 9 = feature not enabled.
- Install: `gh extension install github/gh-stack`
## Core Workflow
```bash
gh stack init my-feature-schema # first branch — bottoms onto the trunk
# ...code, git commit...
gh stack add my-feature-services # next layer on top
# ...code, git commit...
gh stack add my-feature-ui
# ...code, git commit...
gh stack submit # push all branches + create linked PRs
gh stack view # branches, PR links, statuses
```
Fast loop (alias + auto-commit): `gh stack alias` once, then `gs add -Am "message"` per layer.
Merging: click **Merge on the highest PR you want to land** — it and every unmerged PR below merge together atomically. All PRs in the stack are evaluated against the bottom PR's merge requirements.
## Review Feedback Mid-Stack
Never patch a lower layer's problem from a higher branch. Go to the layer that owns it:
```bash
gh stack checkout my-feature-schema # navigate to the flagged layer
# ...fix, git add, git commit...
gh stack rebase # cascade the fix through layers above
gh stack push # force-with-lease push of all branches
```
After lower PRs merge on GitHub: `gh stack sync` (fetch + reconcile + rebase remaining layers onto trunk + push + prune merged branches).
Conflicts during rebase: resolve markers, `git add`, then `gh stack rebase --continue` (or `--abort` to restore).
## Restructuring
`gh stack modify` (interactive TUI): reorder, fold (absorb a branch into a neighbor), drop, insert, rename. Needs a clean tree and linear history; it cannot split a branch. Stage with `Ctrl+S`, then `gh stack submit`. `?` shows keybindings.
## Hamster Repo Rules for Stacks
- **Base is `dev`** — the bottom PR targets `dev`, never `main`. Release PRs are not stacked.
- **One migration per PR still applies per layer.** A stack is the clean way to ship multi-migration work: one migration in the bottom (schema) PR only; upper layers carry no migrations. Migration timestamps must still sort after dev's latest — a long-lived stack is exposed to the same timestamp-ordering races as a long-lived branch, at every layer. Land stacks promptly.
- **Merge commits only** (squash/rebase disabled repo-wide). gh-stack's cascade handles this, but note the FAQ caveat: web-UI-triggered rebases don't sign commits; CLI rebases preserve your signing config.
- **Conventional Commit titles on every PR in the stack** — the title check runs per PR, not per stack.
- **CI runs per layer** against the merged ref; the bottom PR's requirements gate the whole stack's merge.
- Layer boundaries should follow the wave structure the plan already has: DB/schema → engine/services → web UI → docs/tests-polish.
## Escalation
- Exit code 3 = rebase conflict (resolve + `--continue`), 7 = rebase already in progress, 8 = stack locked (a merge is queued), 9 = preview not enabled on this repo.
- Divergent local/remote stacks: `gh stack sync` prompts (use remote / delete remote / cancel) — prefer *use remote* unless you know local is ahead.
- Full command table, flags, and exit codes: see [REFERENCE.md](./REFERENCE.md).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!