Manage Stacked PRs

Complete the requested change and leave its affected stack aligned on GitHub. A local edit or target-only push is not completion when upper layers still need restacking.

Apply alongside the workflow that owns the requested code change. This skill owns stack scope, history alignment, scoped push, and verification. It does not start stack creation, merging, unrelated repairs, comments, reviews, or monitoring. Reading or editing this skill does not authorize changes to a live stack. Honor explicit local-only, read-only, and narrower scope instructions; report any resulting alignment work as unfinished.

Establish the stack and boundaries

1. Read repository instructions. Resolve the target PR from the human request or task context, otherwise the current branch's PR. Use authenticated GitHub reads and gh stack view --json to confirm the host, repository, exact head repository, push remote, ordered membership, PR states, and base relationships. Resolve ambiguous identities or membership before changing history; do not infer order from PR numbers or branch names.
2. Before checkout/ref changes or code edits, read $repair-pr's shared stack coordination and resolve its installed helper. Look up the exact PR and head repository/branch. Defer on lookup errors, an active registry transaction, a building stack without a verified enclosing batch repair handoff, uncertain membership, or another owner. For a verified published but unregistered stack, register its full ordered membership with --published using this task's snapshot path as the ledger. Acquire the whole-stack edit token, or reuse the enclosing repair or merge coordinator's owner/token after verifying it against current registry state. A nested invocation must not release its caller's token. The helper requires repair-pr to be installed; do not proceed unlocked when unavailable. Inspect Git status, git worktree list --porcelain, and pending Git or gh-stack operations. Preserve pre-existing changes and use clean appropriate worktrees. Do not steal another checkout's branch or automatically stash its changes. Keep affected worktrees idle during history changes: gh-stack metadata is shared, and its locks do not coordinate arbitrary Git writes.
3. Before edits, record the task and a snapshot outside tracked source. For delegated post-merge alignment, preserve the caller's pre-merge inherited boundaries instead of deriving them from already changed parent refs. Include every layer's PR URL, head repository/branch, local and remote head SHAs, base name, and body, plus the trunk and immediate parent SHAs. Record each child's verified inherited old parent boundary using stack metadata and Git ancestry. A stale child's boundary can differ from its parent's current tip; do not substitute that tip blindly. Retain the snapshot path and update progress, commits, scope expansions, and push outcomes for continuation.
4. Compare the target against its immediate parent, not the default branch. Separate its own changes from inherited work. Record existing alignment problems without adopting unrelated repairs.

On continuation or re-invocation of the same task, reconcile the existing snapshot and actual local/remote state before new edits. Preserve original inherited boundaries, skip already completed work, and update expected SHAs only after accounting for previous writes and concurrent changes.

Keep two distinct sets: