Conciseness

The body is dense and assumes git competence, explaining only non-obvious rationale ("`--no-track` is mandatory here: a branch cut from a remote base must not inherit the base's upstream", "Never hard-code `origin`"), and there is no conceptual padding. Not 5: a few glosses restate what the adjacent code already shows, e.g. the step-5 parenthetical "(equivalent to `git rebase --onto <base_ref> <merge-base> <subject>`, run with `-C \"$work_dir\"`.)" duplicates the code block immediately above it.

Actionability

Every step ships copy-paste-ready bash with variables defined (remote/trunk resolution, worktree selection, `git rebase --onto`, `git push --force-with-lease`, `gh pr edit --base`, `gh stack link`), and edge cases like multiple remotes, missing PRs, and merged PRs each get concrete handling. Fully executable guidance covering the common cases.

Workflow Clarity

A 12-step sequence for a destructive operation (rebase + force-push) with explicit validation checkpoints: dirty-tree check before rewriting (step 3), a pre-rebase backup with rollback (`reset --hard "${subject}.bak"`), a conflict feedback loop with per-conflict-class resolution rules and `rebase --continue` (step 5), tracking-line verification that must pass before continuing ("must show `[${remote}/${subject}]`; fix it before continuing"), and a final report checklist (step 12). This matches the feedback-loops and explicit-validation anchor.

Progressive Disclosure

Good structure: a numbered workflow with per-step code blocks, a Never section, and inline signposts to related skills (`pr-create`, `pr-style`, `using-git-worktrees`, git-rebase's conflict handler); the single-procedure content is mostly appropriately placed inline. Not 5: at ~185 lines with no bundle files, self-contained sections like the step-5 conflict-resolution policy or the worktree-path convention could be split into one-level-deep reference files to slim the always-loaded body.

Specificity

"Stack an existing or new git branch on top of another branch, restacking it in a git worktree when needed, then align the GitHub PR bases and stack metadata with `gh stack`" lists four concrete actions (stack, worktree restack, PR-base alignment, gh stack metadata alignment) covering the skill's full capability set. Not 4: no meaningful capability is left unstated, so coverage is comprehensive rather than having minor gaps.

Completeness

Explicitly answers both what ("Stack ... restacking it in a git worktree ... align the GitHub PR bases and stack metadata with `gh stack`") and when ("Use when invoked as `$git-stack` or when the user asks to stack or restack a branch or PR onto another branch") with concrete trigger phrases. Not 4: the when-clause is fully explicit and specific rather than merely present.

Trigger Term Quality

"Use when invoked as `$git-stack` or when the user asks to stack or restack a branch or PR onto another branch" includes the natural phrases users of stacked PRs actually say (stack, restack, onto another branch, PR). Not 5: a few natural variations like "stacked PRs", "chain PRs", or "change a PR's base" are absent; not 3 because the core vocabulary users would naturally use is present and specific.

Distinctiveness Conflict Risk

The stacked-PR/`gh stack`/worktree niche is clearly claimed and the triggers ("stack or restack a branch or PR onto another branch") are domain-specific vocabulary unlikely to fire for unrelated skills. Not 4: it does not meaningfully overlap with generic rebase, worktree, or PR-creation skills because the trigger terms are distinct to stacking.