Conciseness

The body is dense with non-obvious, tool-specific knowledge (atomicity, page-context resets, 0-1 colors, sizing-enum distinctions) and explains nothing Claude already knows, but it repeats material: the layoutSizing rules appear in Rules 12/12b, again in the Section 7 error table, and again in the Section 8 checklist; the page-switching rule appears in Rule 9 and twice in Section 2; Rule 15 restates Section 3. Section 11 ('Snippet examples') is vague filler. This matches anchor 3 — mostly efficient but could be tightened — rather than anchor 4, where over-explanation is only minor.

Actionability

Fully executable, copy-paste-ready guidance covering the common cases: `await figma.setCurrentPageAsync(page)` snippets, a dozen `node.query()` selector examples, `node.set()` batching, `figma.createAutoLayout('VERTICAL', { name: 'Column', itemSpacing: 8 })`, `await frame.screenshot({ scale: 2 })`, ready-to-run inspection scripts, and an error-message → likely-cause → fix table keyed to exact error strings. This is the anchor-5 case; anchor 4 would imply gaps in the covered cases, and there are none of consequence.

Workflow Clarity

Section 6 gives a numbered six-step pattern (inspect → skeleton → fill → return IDs → validate → fix before moving on), a suggested step order, and a per-step table of what to validate with get_metadata vs get_screenshot; Section 7 gives an explicit STOP → read error → fix → retry feedback loop plus a self-correction table; Section 8 adds a pre-flight checklist; and the atomicity guarantee makes retry-safe validation explicit. This is exactly the anchor-5 combination of clear sequence, explicit validation, feedback loops, and checklists.

Progressive Disclosure

The Section 10 Reference Docs table maps all 11 verified reference files to when-to-load and what-it-covers; links carry precise anchors (all spot-checked anchors exist in gotchas.md, and working-with-design-systems/wwds.md exists); the 455KB d.ts is explicitly marked grep-only. It falls short of anchor 5 because ~60 lines of query-selector syntax and QueryResult API reference are inlined in Section 5 where the skill's own pattern would put them in a reference file, and the 435-line body itself carries material (full editor-mode node-type lists) that could be externalized. It is clearly above anchor 3: the split is real and well-signaled, with only minor placement gaps.

Specificity

The description lists multiple concrete actions — 'create/edit/delete nodes, set up variables or tokens, build components and variants, modify auto-layout or fills, bind variables to properties, or inspect file structure programmatically' — which matches the anchor-5 comprehensive-coverage example. However, the rubric mandates a 1-point reduction for second-person voice ('you MUST invoke this skill BEFORE every use_figma tool call', 'NEVER call use_figma directly'), bringing it to 4. It is not a 3 because the action list is far broader than the 1-2 actions that anchor describes.

Completeness

The 'when' is explicit and detailed ('Trigger whenever the user wants to perform a write action or a unique read action that requires JavaScript execution in the Figma file context — e.g. ...'), but the 'what' is never stated: the description only says the skill is a MANDATORY prerequisite to load before use_figma calls, never what it actually provides (Plugin API rules, code recipes, error-recovery workflow). Per the guideline to score only what is explicitly stated, this mirrors anchor 3 (one half clear, the other only weakly implied) rather than anchor 4 where both halves are present.

Trigger Term Quality

Natural terms a Figma-user would say are well covered: 'nodes', 'components and variants', 'variables or tokens', 'auto-layout', 'fills', 'bind variables', 'inspect file structure', plus the tool name 'use_figma'. It falls short of anchor 5 because common synonyms and surface phrasings are missing — no mention of 'frames', 'pages', 'screens', 'design files', or 'design system', which a user would naturally say and which this skill's own body treats as core territory.

Distinctiveness Conflict Risk

Triggering is pinned to a specific tool ('BEFORE every use_figma tool call') and concrete Figma API operations, giving it a clear niche with minimal generic conflict. It is not a 5 because the skill family itself contains closely related siblings (figma-generate-design, figma-generate-library, figma-use-slides, per the body) whose tasks — building components, screens, variables — overlap the listed triggers 'build components and variants' and 'set up variables or tokens', so the wrong sibling could plausibly fire. It is well above anchor 3 because the tool-call binding is far more specific than a domain-only description.