菜单
Use when creating a stacked PR-fixup, follow-up patch PR, companion review-fix PR, or branch named with suffixes like -p0/-p1 that targets another open PR branch.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | stacking-pr-fixups |
| description | Use when creating a stacked PR-fixup, follow-up patch PR, companion review-fix PR, or branch named with suffixes like -p0/-p1 that targets another open PR branch. |
A PR-fixup branch is a narrow patch stacked on the PR under review. Its base is the reviewed PR's head branch, and its readiness depends on how complete the requested fixes are.
Required sub-skills: Use checkpointing-and-publishing-git-work for task-only commits and pushes, publishing-reviewable-prs for PR creation, title/body updates, or ready-state changes, and ralph-review-until-clean before publishing when requested. The publisher must use writing-reviewable-pr-descriptions.
gh pr list --head <branch> --state open --json number,headRefName,headRepository,headRepositoryOwner,baseRefName,url.gh pr view <base-pr-or-branch> --json number,author,headRefName,headRefOid,headRepository,headRepositoryOwner,urlheadRefName, never the base PR's own base branch.ivan/; if there is no slash, prepend ivan/.-p<N> before adding the new suffix.-p<N>, starting at -p0 and incrementing to the next unused local head, relevant remote head, or open PR head in the target repository.jason/multi-cred-test becomes ivan/multi-cred-test-p0.publishing-reviewable-prs; its canonical body states that the PR is stacked on the base PR, lists the fixes and verification, and includes current Stack and Diff disclosures.ready operation and request review from the base PR author only when the readiness rule below allows it; report any review-request failure instead of silently skipping it.| Fix context | Stop point |
|---|---|
| The user provides a bounded fix list, or explicitly enumerated review issues are all addressed | Proceed through ready-for-review and request the base PR author's review. |
| Intended fixes are uncertain versus the review intent | Pause before marking ready and ask whether the PR is ready. |
| Some fixes are known, but more are likely | If the user asked to create a PR and the known fixes are committed, open or update a draft PR; otherwise branch-only is fine. Stop before ready-for-review and tell the user it is awaiting further additions. The user can say Proceed to mark ready and request review. |
| No fixes are provided yet | Check out the new fixup branch from the base PR head and pause; do not commit or open an empty PR. |
| Mistake | Fix |
|---|---|
Basing the fixup PR on main | Base it on the reviewed PR's head branch. |
Reusing -p0 after another fixup exists | Scan local heads, relevant remote heads, and open PR heads before choosing the suffix ordinal. |
| Marking ready while fixes are speculative or incomplete | Stop at draft or branch-only and ask for the readiness decision. |
| Requesting review while still draft | Request the base PR author's review only after ready-for-review. |
| Duplicating the full fixup rationale on the base PR | Post a short pointer comment and keep details in the fixup PR. |
| Sweeping nearby cleanup into the fixup | Keep the diff to the intended review fixes. |
Use when handling any Git-backed change and safe task completion. Use when asked to implement a change in a repository and commit clean checkpoints; review a branch or repository for bugs, including review-only work; create commits or checkpoints; push and verify a remote branch; reconcile with an exact lease; integrate or discard a branch; classify or clean up a worktree; or close out Git work. If a repository task says "In Codex" or "In Claude Code," apply in either harness, even when mutation or publication is forbidden. Do not use for Git explanations or pasted summaries without repository action. Owns safe task-only commits, publication, completion choices, and provenance-aware cleanup without publishing non-task work.
Use when leading work from Cursor, Claude Code, or Codex that may need delegation across Cursor, Claude Code, Codex, Spark, browser/computer-use agents, or separate worktrees; deciding what stays local versus handed off; or coordinating multi-agent work.
Use when the user explicitly asks to get a GitHub branch or pull request merged, shipped, over the line, or closed out end to end: "get this merged", "drive it to merge", "ship this PR", "merge and close out this branch", or resume a previously stated merge/closeout workflow. Do not use for single-step PR operations, PR-description-only, review-only, status-only, issue-triage, check-only, CI-check-only, comment-only, ready-only, open-PR-only, draft-PR-only, or publish-only requests unless the user also states a merge or closeout goal. Requests to inspect checks, blockers, readiness, comments, or policy without asking to continue toward merge do not trigger this skill. Requests that say to open a PR, leave it draft, or that the PR is not ready to merge do not trigger this skill.
Use when the operator asks to get a branch, change set, draft PR, or pull request ready for review end to end: "get this PR review-ready", "make this ready for review", "prepare this draft PR for review", "mark ready for review", "tighten then publish for review", or "review-ready yeet". Do not use for review-only, status-only, PR-description-only, draft-PR-only, publish-only, merge, ship, or closeout requests unless the operator also states a ready-for-review outcome.
Use when working with Graphite `gt` stacks: creating or tracking stacked branches, navigating or reparenting a stack, restacking, submitting or updating stacked PRs, fixing Graphite metadata, or diagnosing stack ancestry and publication state.
Use when PR review loops, bot review reruns, CodeRabbit or Greptile cycles, unresolved pull request comments, ready-for-review, mark ready, merge readiness, blocked merges, stale review threads, requested reviewers, branch closeout, merge tasks, docs-only PRs, or skill-only PRs affect a pull request.