Conciseness

The body is dense and prescriptive with no filler — it never explains concepts Claude already knows (the worktree `.git`-file note is genuinely non-obvious). It falls short of the 5 anchor because of minor trims available: the fork-remote rationale for pinning `--repo` is stated twice ("never rely on `gh`'s default-repo resolution, which a fork remote can redirect…" repeats step 1's "never bare `gh issue view`…"), and the single-paragraph "Inline spec takes precedence" block packs four distinct rules into one long sentence. Not 3, because these are isolated tightenings in an otherwise lean document.

Actionability

Every step is copy-paste ready: exact `gh api`/`gh issue view`/`gh search prs` commands with flags and JSON fields, `git rev-parse --git-path info/exclude`, a complete plan-file template with per-section instructions, and the literal closing message to end the turn with. This matches the 5 anchor — fully executable commands covering the common cases, not the 4 anchor's "minor gaps".

Workflow Clarity

The sequence (preconditions → fetch record → five live-state gates → build plan → stop) has explicit validation checkpoints at every stage: `git status --porcelain` cleanliness, `gh auth status`, open/closed state, `security` label, duplicate-PR search, and a staleness comparison requiring maintainer confirmation. Recovery loops are specified ("If the maintainer asks questions or requests changes instead, revise the file and end the turn the same way"), and failure paths state exactly what to say. This is the 5 anchor, not 4, because checkpoints are explicit rather than merely present.

Progressive Disclosure

There are no bundle files, and the skill is a single well-organized document with numbered sections — nothing here needs one-level-deep references, so nothing is misfiled. It sits at 4 rather than 5 because the ~105-line body is at the edge of what belongs in one file: the plan-file template (step 3) is a substantial inline block that a reference file could hold, and the very long step-3 paragraph buries the precedence rules (inline spec vs. approved plan file vs. record) mid-section rather than signaling them up front.

Specificity

The description lists multiple concrete actions — "fetch the sweeper's review record from its state repo", "put the review's open decisions to the maintainer", "write a plan file (.sweeper/plans/issue-<n>.md)" — plus the explicit boundary "it writes no code and ends there". This comprehensively covers the skill's behavior, matching the top anchor rather than the 4 anchor ("several specific actions; minor gaps"), since no capability of the skill is left unstated.

Completeness

Both halves are explicit: the "what" is the three concrete actions plus the boundary, and the "when" is "Use ONLY when the request explicitly asks for the sweeper plan" with concrete trigger phrases and a negative case. This matches the 5 anchor ("clearly and explicitly answers both what AND when with concrete trigger phrases") and exceeds the 4 anchor, whose 'when' is less specific.

Trigger Term Quality

It quotes the natural phrases a user would actually type — "sweeper-plan", "plan … with the sweeper" — and covers the remaining entry points ("a sweeper record or agent-ready issue to plan first"). For this tool's niche the term coverage is exhaustive, including the skill-name form users would invoke directly; not the 4 anchor because no common variation is missing.

Distinctiveness Conflict Risk

The "Do NOT use for a plain planning request that doesn't mention the sweeper" clause explicitly fences it off from generic planning skills, and the sweeper-specific vocabulary gives it a clear niche with minimal conflict risk. It is clearly distinguishable from the sibling sweeper-implement skill because it states "the sweeper-implement skill implements the approved plan".