Conciseness

The body is dense and high-signal with no basic-concept explanations (it assumes competence throughout, e.g. going straight to "git remote -v must list microsoft/vscode"), but two warnings are repeated nearly verbatim — the fork-remote `gh` caution appears in both step 1 ("never bare `gh issue view`, which a fork remote can redirect") and step 2 ("never rely on `gh`'s default-repo resolution, which a fork remote can redirect…"), and "never hand off to a host's Create PR action" appears in both step 5 and step 6. This matches anchor 4 (minor instances that could be trimmed) rather than 5, and exceeds anchor 3 since there is no evaluative filler or unnecessary explanation.

Actionability

Guidance is copy-paste executable at every step: the record fetch (`gh api "repos/egamma/vscodesweeper-state/contents/records/microsoft/vscode/items/<issue-number>.md?ref=state"…`), the live gate (`gh issue view <issue-number> --repo microsoft/vscode --json state,labels,updatedAt`), the PR-open command (`gh pr create --repo microsoft/vscode --base main --draft --title … --body-file <body file>`), exact plan paths (`.sweeper/plans/issue-<issue-number>.md`), and a fully ordered PR-body spec. The common cases (both modes, refusal paths) are all covered; the one abstraction ("a normal, descriptive message") is a deliberate delegation, matching anchor 5.

Workflow Clarity

The process is explicitly sequenced (steps 0–6) with validation checkpoints everywhere: five numbered refusal gates, a staleness check, a statement-by-statement validation table in step 5, tests required to "fail before your change and pass after — run them both ways", gates 2–4 re-run before any push, and explicit error-recovery paths (no record → "continue on the issue by your normal means"; dirty tree → stop without stashing). This is anchor 5 — clear sequence, explicit validation, feedback loops, and checklists; the destructive/public-operation cap does not apply since validation is pervasive.

Progressive Disclosure

No bundle files exist, and the ~120-line body is well sectioned with numbered headings so everything operationally needed is inline and navigable — good structure per anchor 4. It falls short of anchor 5 because nothing is split out: the document exceeds the "under 50 lines" simple-skill exception and inlines the full PR-body template and record-format details that could live in a one-level-deep reference.

Specificity

The description enumerates the full workflow as concrete actions — "fetch the sweeper's review record from its state repo", "implement the change in the current vscode checkout from the review's brief", "validate the diff against it", and "open a draft PR" — comprehensively covering the task. It fits anchor 5 rather than 4 because there are no gaps in the action coverage.

Completeness

It explicitly answers both questions: "what" via the four concrete actions, and "when" via the explicit trigger clause "Use ONLY when the request explicitly asks for the sweeper — … or asks to implement a sweeper plan", plus negative guidance ("Do NOT use for a plain 'fix this issue' request"). This matches anchor 5 with concrete trigger phrases; the missing-'Use when' cap does not apply.

Trigger Term Quality

Trigger terms are comprehensive and natural to the invoking user: "sweeper-implement", "sweeper", "vscodesweeper", "a sweeper record", "an agent-ready issue", "a sweeper brief", "implement plan <n>", and the file path ".sweeper/plans/issue-<n>.md" — covering synonyms and concrete file patterns like the anchor-5 example. It is not 4 because no common invocation form is missing.

Distinctiveness Conflict Risk

The niche is unambiguous — all triggers are sweeper-specific ("sweeper", "vscodesweeper", "a sweeper record", ".sweeper/plans/…") and the description actively disambiguates the closest conflict ("Do NOT use for a plain 'fix this issue' request that doesn't mention the sweeper; fix those directly with your normal tools instead"). Minimal conflict risk, matching anchor 5.