Conciseness

The body is mostly operational rather than tutorial-like, but several sections are padded with design history and restated rules: the removed v3.5 background-watch rationale ("It was removed because every job it did is already done…"), the legacy-flag paragraph ("--no-preview-spec is the pre-rename spelling, still honoured so existing scripts and muscle memory keep working"), and the same 'record it now, never soften a skip into a decline' rule repeated across Steps 5.5, 6.4, and 10. This fits anchor 3 — mostly efficient but includes unnecessary explanation that could be tightened — rather than 2, since the padding is project-specific rationale, not explanation of concepts Claude already knows.

Actionability

Mostly executable, copy-paste-ready guidance: `git push`, `gh pr create --draft --title … --body …`, `timeout 540 gh pr checks <pr-number> --watch`, exact `Skill("review-loop", "<pr-url> --no-ci")` invocations, a first-match-wins flag→invocation table, and a full report template. It stops short of anchor 5 because the skill's core task — writing the description (Steps 1–5) — is delegated wholesale to `rules/description-contract.md`, which is not present in the bundle, so the central authoring guidance is not actually executable from what ships here.

Workflow Clarity

The multi-step process is clearly sequenced (Steps 0 → 10 with explicit sub-steps) and saturated with validation checkpoints and feedback loops: CI watch with exit-code classification (0 / 124 / 127 / other), bounded retries ("up to 4 attempts total … After the fourth … escalate — never watch again"), ci-auto-fix capped at 2 invocations with print-as-you-go counters, pre-push flagged-findings surfacing, and a mandatory report with slots for every outcome. This matches anchor 5's explicit validation steps, error-recovery loops, and checklists.

Progressive Disclosure

The body is well-signaled — "Full procedure lives in [`rules/split-mode.md`](./rules/split-mode.md)", "**→ [`rules/registration-poll.md`](./rules/registration-poll.md)**" — but none of the referenced files exist in the bundle: there is no rules/, references/, scripts/, or assets/ directory, so the description contract, split-mode procedure, pre-push review rules, registration poll, and all four examples are unreachable. Scored against the actual bundle structure, this is anchor 2's minimal effective structure: the split-out content is not inlined and the references do not resolve, rather than anchor 3, where references are present but merely poorly signaled.

Specificity

The description enumerates concrete, comprehensive actions across the whole workflow: "pushes the branch, opens the PR as a draft", "runs review-loop (pr-reviewer → implement-suggestion → polish simplify, up to 5 iterations) until every review thread is resolved", "breaks the branch diff into 2–4 focused, dependency-ordered draft PRs after user approval", and "Hands red CI to ci-auto-fix, which fixes or escalates". This matches the anchor for multiple specific concrete actions with comprehensive coverage; score 4 would require minor gaps, but every phase (author, push, review, split, CI) is covered with named sub-skills and numeric bounds.

Completeness

The "what" is clearly and comprehensively answered, but the "when" is only addressed by "Invoke with /create-pr or /create-pr --split", which states the invocation form rather than when the skill is needed (no "Use when the user wants to turn a branch into a PR" or equivalent). Per the judging guideline, a missing 'Use when...' clause or equivalent explicit trigger guidance caps completeness at 3; it is not a 2 because the what-half is detailed and an explicit invocation path exists.

Trigger Term Quality

Good natural-keyword coverage: "GitHub pull request", "PR", "draft", "review", "CI", "split" — terms a user would plausibly say when asking to open or split a PR. It falls short of anchor 5 because there is no synonym spread for the triggering situations (e.g., "open a PR", "get this branch ready for review", "ship this branch") and the keyword density is dominated by internal skill and flag names (review-loop, --no-quality, ui-verify).

Distinctiveness Conflict Risk

It occupies a clear niche — PR creation from a branch (push, draft, converge, split, CI) — with distinct triggers and named sub-skills (review-loop, review-branch, ci-auto-fix) that separate it from review-only or CI-only skills. The pull-request vocabulary could superficially overlap a PR-review skill, but the creation-side actions ("pushes the branch, opens the PR as a draft", "breaks the branch diff into 2–4 … draft PRs") keep conflict risk minimal, matching anchor 5 rather than anchor 4's 'minor overlap risk'.