跳到正文
cccskills
免费在 GitHub 公开

gh-stack

Organize dependent code changes into a chain of branches and pull requests, so reviewers can examine one layer at a time. The skill guides stack creation, edits, synchronization, rebasing, and merging with gh-stack.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Manages stacked PRs and splits multi-part work into reviewable branches with gh-stack. Use for stack creation, viewing, edits, push, submit, sync, rebase, merge, or checkout; when asked to split or isolate work for review; whenever a user mentions a stack, branch layers, dependent PRs, or gh stack; or when a stack is checked out.

集成工具GitHub
查看安装方法

适用场景

  • Split dependent changes into reviewable pull requests
  • Update a lower branch and propagate changes upward
  • Synchronize local branches with GitHub
  • Merge dependent pull requests in order

包含的文件(4)

  • SKILL.md8.0 KB
  • references/commands.md8.9 KB
  • references/stack-design.md4.1 KB
  • references/troubleshooting.md6.6 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

gh-stack

gh stack is a GitHub CLI extension for stacked branches and pull requests. A stack is an ordered chain of branches rooted on a trunk, where each branch has one PR based on the branch below it, so a reviewer sees only that layer's diff.

gh stack prints a stack trunk-first, left to right:

(main) <- auth <- api <- frontend

Left is the bottom, right is the top. auth is based on main and merges first; frontend merges last. up moves toward the top, away from trunk; down moves toward it. Foundational work belongs at the bottom, code that depends on it above. For how to choose the layers, read references/stack-design.md.

Setup

gh extension install github/gh-stack
git config rerere.enabled true         # remember conflict resolutions
git config remote.pushDefault origin   # required if the repo has more than one remote

Non-interactive use

gh stack branches on whether stdout is a TTY. Piped, most commands error cleanly or print static text; under a PTY the same commands open a prompt or a full-screen TUI and block forever. Agent harnesses differ, so always pass the flags below instead of relying on that detection.

Multiple remotes: never run push, submit, sync, rebase, or link without --remote <name> unless remote.pushDefault is configured. checkout and trunk have no --remote flag and require the config.

Always runNever run bareWhy
gh stack view --jsongh stack viewopens a TUI under a PTY
gh stack submit --autogh stack submitprompts for a title per new PR
gh stack merge <target> --yesgh pr mergegh pr merge cannot merge a stack
gh stack init <branch>...gh stack initprompts for branch names
gh stack add <branch>gh stack addprompts for a name, and fails even when piped
gh stack checkout <target>gh stack checkoutopens a selection menu
gh stack up / down / top / bottomgh stack switchswitch is menu-only
—gh stack modifyTUI-only, no non-interactive path
  • view --short is safe in both modes, but it is formatted for humans. Use --json to parse.
  • checkout <pr> when a different local stack already covers those branches cannot be forced. Run gh stack unstack --local first (this keeps the stack on GitHub), then retry.

Branch placement

  • Starting multi-part work: create the stack before writing files. Do not implement every concern on trunk and split it later. Put one dependent concern in each layer, bottom to top.
  • Editing an existing stack: check out the layer that owns the change before editing. Never commit a lower layer's concern on the current top branch. Run gh stack view --json; if ownership is unclear, inspect git log --all -- <path>. Then check out the owner, edit, commit, rebase upstack, and return to top.
gh stack down                   # or: gh stack checkout api
git add ... && git commit -m "Add get-user endpoint"
gh stack rebase --upstack       # replay every branch above onto the change
gh stack top                    # return to where you were
gh stack push

Core loop

gh stack init auth              # create the stack and check out its branch
git add ... && git commit -m "Add auth middleware"
gh stack add api                # next layer, branched from the current one
git add ... && git commit -m "Add API routes"
gh stack submit --auto          # push every branch and open draft PRs
gh stack view --json            # confirm

Add --open to submit to create PRs ready for review instead of drafts. Branch names are verbatim — gh stack add refactor/foo creates refactor/foo.

Staying in sync

gh stack sync                   # fetch, reconcile with GitHub, rebase, push, refresh PR state
gh stack sync --prune           # also delete local branches for merged PRs

Pruning never happens without --prune when non-interactive. If the local and remote stacks have diverged, sync prints both chains, makes no changes, and exits 0 with Sync aborted — see references/troubleshooting.md.

Merging

Scope the merge with an argument:

gh stack merge 42 --yes          # PR #42 plus every unmerged PR below it
gh stack merge 7 --yes           # every unmerged PR in stack #7
gh stack merge 42 --yes --squash # or --merge, --rebase, --merge-method <method>

Pass a PR number to merge that PR and every unmerged PR below it, or a stack number to merge every unmerged PR in that stack. The operation is all-or-nothing: if any PR in that set cannot merge, none do.

Without a method flag the last-used method is reused. If the base branch uses a merge queue, the stack is queued instead and the queue picks the method, ignoring any flag you passed with a warning; queued PRs may land in separate groups.

Reading state

gh stack view --json writes JSON to stdout. Status messages go to stderr — do not parse them, branch on exit codes instead.

trunk           string
currentBranch   string
branches[]      name, head, base, isCurrent, isMerged, isQueued, needsRebase
branches[].pr   number, url, state ("OPEN" | "MERGED" | "QUEUED"); absent when no PR exists

base is the saved SHA of the parent branch that this branch was last known to contain. It may be older than the parent's current tip. needsRebase is true when the current parent tip is no longer an ancestor of the branch.

Exit codes

CodeMeaningRecovery
0Success—
1Generic errorRead stderr
2Not in a stackgh stack init, or gh stack checkout <target>
3Rebase conflictFollow the Exit 3 recovery below
4GitHub API failureCheck gh auth status, retry
5Invalid argumentsFix the invocation; see <command> --help
6Disambiguation requiredBranch is in several stacks; check out a non-shared branch
7Rebase already in progressgh stack rebase --continue or --abort
8Stack file lockedAnother gh stack process is writing; retry after ~5s
9Stacked PRs unavailableNot enabled on the repository; tell the user
10Modify recovery requiredgh stack modify --abort

Exit 3 recovery:

  • After gh stack rebase: resolve the files, run git add, then gh stack rebase --continue; use gh stack rebase --abort to restore the stack.
  • After gh stack sync: the stack has already been restored. Run gh stack rebase to recreate the conflict, then resolve and continue as above.

Constraints

  • Stacks are strictly linear: one parent, at most one child. Use separate stacks for parallel work.
  • There is no non-interactive reorder or removal. Errors may suggest gh stack modify, but it is TUI-only — restructure with unstack then init instead.
  • PR titles and bodies are auto-generated. Use gh pr edit afterwards to change them.

More detail

gh stack <command> --help is authoritative for flags and arguments. Note that gh stack help <command> does not work — it prints the top-level help.

Open the reference whose trigger matches the task; no need to preload all three.

  • references/stack-design.md — read before creating a stack, when deciding how many layers to use, what belongs in each one, or whether work belongs in a new stack.
  • references/commands.md — read when a command fails unexpectedly or you need its preconditions, side effects, atomicity, or ordering guarantees.
  • references/troubleshooting.md — read on a rebase conflict, after a squash-merge, on local and remote divergence, when restructuring a stack, or when driving stacks from another tool.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Guide app automation on iOS, tvOS, macOS, and Android using help matched to the installed agent-device CLI. Tasks include screen inspection, taps, text entry, scrolling, and collecting logs, network information, or performance evidence.

中文简介正在准备中。当前显示英语简介。

  • Navigate apps and verify the resulting screens
  • Automate text entry and scrolling
  • Capture screenshots and inspect interface information
CherryHQ/cherry-studio-app40202026年10月21日 更新

Build app screens with Expo Router using guidance on layout, navigation, native tabs, and animations. It covers route organization and styling patterns, with Expo Go as the starting point for testing.

中文简介正在准备中。当前显示英语简介。

  • Build screens and navigation with Expo Router
  • Organize native tabs and navigation stacks
  • Add link previews and context menus
CherryHQ/cherry-studio-app40202026年10月21日 更新

diagnose

免费

Diagnose bugs, intermittent failures, and performance regressions through structured logging and reproduction. It ranks possible causes with confidence scores, tests competing explanations, and reports whether the evidence proves the cause or leaves the diagnosis incomplete.

中文简介正在准备中。当前显示英语简介。

  • Trace the cause of a reproducible bug
  • Investigate intermittent failures through repeated runs
  • Compare possible causes of browser or device failures
CherryHQ/cherry-studio-app40202026年10月21日 更新

Drive repeated debugging cycles with the required diagnose skill: establish evidence for a cause, choose one focused fix, and rerun the original validation. Reassess after each change until no credible fix remains or further progress requires user input.

中文简介正在准备中。当前显示英语简介。

  • Repeating bug fixes and verification until validation is clean
  • Checking performance changes against original measurements
  • Investigating regressions after each fix
CherryHQ/cherry-studio-app40202026年10月21日 更新

Check published EAS Updates from the command line using crash rates, user counts, and payload size. Compare adoption of the app's bundled version and over-the-air updates, with JSON output for automated health checks.

中文简介正在准备中。当前显示英语简介。

  • Check update health after publishing
  • Compare crash rates with a previous release
  • Compare bundled and over-the-air update adoption
CherryHQ/cherry-studio-app40202026年10月21日 更新

Create and edit EAS workflow YAML files to automate builds and deployment for Expo projects. The skill consults current documentation and validates configuration structure, required parameters, job dependencies, and expressions against the published schema.

中文简介正在准备中。当前显示英语简介。

  • Create an EAS workflow for builds and deployment
  • Edit workflow triggers and job dependencies
  • Validate existing workflow YAML files
CherryHQ/cherry-studio-app40202026年10月21日 更新

查看 CherryHQ 的全部技能

报告此技能的问题