Conciseness

The body is lean and assumes competence — no generic explanations of concepts Claude already knows — and the 'Why the timing' section captures project-specific rationale Claude could not infer. A few rhetorical flourishes ("the number gets talked into agreeing with the spend", "That is motivated reasoning, and it corrupts the one field the whole system rests on") could be trimmed without losing guidance, so it sits at 'efficient; minor instances of over-explanation' rather than the every-token-earns-its-place top anchor.

Actionability

Fully executable, copy-paste-ready commands cover the common cases: `gh issue edit 412 --repo xchromo/osn --add-label "complexity:3"`, the dual-label backfill command, a complete `gh issue list --json ... --jq` filter for finding unrated issues, and the exclusion query. The concrete five-row Fibonacci rubric table plus raise/lower signals makes the judgement step executable too; this matches the top anchor.

Workflow Clarity

Both modes have clear numbered sequences and Mode A includes an owner confirmation checkpoint, but Mode B is a batch operation (one pass over up to 200 issues) whose only guard is the jq selection filter — there is no verification step confirming labels applied correctly or a dry-run/review pass, so the batch-operation cap of 3 applies. It is above the anchor of 2 because the sequence is well defined and the input-selection check is explicit.

Progressive Disclosure

Well-organized sections (rationale, rubric, Mode A, Mode B, labels, consumers) with content appropriately kept inline — the rubric table and label semantics are core and belong here. It does not hit the top anchor: at ~105 lines it exceeds the under-50-line simple-skill exception, references no bundle files (none exist), and points to external repo artifacts (`wiki/observability/session-metrics.md`, `@tools/pr-metrics`) without a clearly signaled pointer structure.

Specificity

Names several concrete actions — "proposing a rating from the issue body alone", "getting the owner to confirm or amend it", "backfilling a rating onto an existing unrated issue" — which matches the 'several specific actions; minor gaps' anchor. Not a 5 because coverage stops at the label/rating workflow itself (e.g., querying or consuming the ratings is only hinted at), and not a 3 because more than 1-2 actions are explicitly stated.

Completeness

Explicitly answers both: what ("proposing a rating... getting the owner to confirm or amend it, or backfilling a rating onto an existing unrated issue") and when ("Use when an issue needs its complexity declared... Invoked by new-feat at issue-creation time; also the backfill path for issues opened before the label existed"). Both are concrete and include trigger phrases, matching the top anchor; the 'Use when' clause is present so no cap applies.

Trigger Term Quality

Good natural keyword coverage — "complexity", "rating", "rate", "unrated issue", "backfill", "confirm or amend" — phrases a user would plausibly say when needing this skill. A few natural synonyms are missing ("estimate", "difficulty", "size the issue"), which keeps it below the comprehensive-synonym anchor of 5 and clearly above the generic-keyword anchors of 2-3.

Distinctiveness Conflict Risk

Occupies a clear niche — declaring complexity ratings on issues via labels at issue-creation or backfill time — with triggers unlikely to fire for unrelated skills. Not a 4 because the phrasing ("complexity declared", "unrated issue", "new-feat") is specific enough that overlap risk with general issue-management or metrics skills is minimal.