Conciseness

The body is lean and imperative throughout — "Do not equate age, reactions, or comment count with priority", "Preserve contributor authorship", and the compact candidate-card template each state policy in minimal tokens, and nothing explains concepts Claude already knows (no primer on what issues or PRs are). Every section earns its place; the one code block is four copy-paste gh commands with exact --json field lists. Not a 4 because I found no trimming candidates that would remove real guidance.

Actionability

Concrete guidance dominates: executable gh commands with exact JSON field selections, a copy-paste candidate-card template, and specifics like "Return three to five 'Recommended now' cards by default" and "exact ISO 8601 polling time with timezone". Not a 5 because the skill's core ranking logic is delegated entirely to an external MAINTAINERS.md (only the ladder step names are inlined, no fallback criteria), and "Prefer a configured GitHub integration; use gh when it provides the required repository context" leaves the tool-choice decision vague.

Workflow Clarity

Both workflows (Poll: 6 steps; Start: 6 steps) are clearly sequenced with real checkpoints — poll step 5 requires deep verification of each candidate, and start step 2 gates mutation: "If the recommendation is stale, the scope is ambiguous, or another active claim appeared, report the conflict before mutating GitHub". Not a 5 because there is no recovery branch after reporting a conflict (re-poll? abort and await re-selection?), and start step 4's "the repository's normal assignment or scope confirmation mechanism" offers no concrete default action or fallback.

Progressive Disclosure

Sections (Poll, Poll Safety, Candidate Format, Start, Never Auto-Dispatch) are well-organized, inline content (gh commands, card template, safety rules) is appropriately sized for the body, and the one deep-reference policy is one level away with its role stated ("MAINTAINERS.md as the ranking policy") and its ladder summarized inline. Not a 5 because that sole reference points outside the skill bundle via a repo-relative path (../../../docs/contributing/MAINTAINERS.md) that breaks when the skill is installed standalone, and no reference bundle exists alongside the skill to carry that content.

Specificity

"Poll and rank open GitHub issues, RFCs, and pull requests for maintainer work, or start one explicitly selected item" names multiple concrete actions (poll, rank, start a selected item) plus concrete behavioral constraints ("Keep polling read-only", "enter the start workflow only after explicit selection"), giving comprehensive coverage of the skill's capabilities. Not a 4 because no capability area is visibly missing; the two-mode behavior is fully enumerated.

Completeness

Both "what" (poll/rank issues, RFCs, and PRs for maintainer work, or start one explicitly selected item) and "when" (an explicit "Use when..." clause with concrete trigger phrases) are clearly and explicitly stated. This matches the anchor-5 example structure exactly; not a 4 because the when-clause is already fully explicit with concrete triggers.

Trigger Term Quality

The "Use when" clause covers five natural trigger formulations users would actually say: "asks what to work on", "requests backlog priorities", "says 'poll work'", "wants actionable issues or pull requests", and "says 'start #123'" — including both literal commands and natural-language paraphrases (question form, request form, command form). Not a 4 because even the skill-specific literal commands are quoted, which anchor-4 examples lack.

Distinctiveness Conflict Risk

The maintainer-work polling niche with distinctive literal triggers ("poll work", "start #123") is mostly distinct from generic GitHub or code-review skills. Not a 5 because "wants actionable issues or pull requests" is broad enough to overlap with general issue-triage or PR-review skills, matching the anchor-4 "minor overlap risk with closely related skills".