**MANDATORY prerequisite** — you MUST invoke this skill BEFORE every `use_figma` tool call. NEVER call `use_figma` directly without loading this skill first. Skipping it causes common, hard-to-debug failures. 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. 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.
69
85%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
85%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description is strong in specificity, completeness, and distinctiveness, clearly defining its role as a mandatory prerequisite for Figma tool calls with concrete action examples. Its main weakness is the trigger term quality — while it covers technical Figma operations well, it could better incorporate natural user language. The imperative/second-person framing ('you MUST invoke') is unusual but contextually appropriate since it's instructing Claude rather than describing to a user.
Suggestions
Add more natural user-facing trigger terms like 'design', 'UI', 'prototype', 'mockup', 'Figma design' to improve matching when users describe tasks in non-technical language.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: create/edit/delete nodes, set up variables or tokens, build components and variants, modify auto-layout or fills, bind variables to properties, inspect file structure programmatically. | 3 / 3 |
Completeness | Clearly answers both 'what' (prerequisite skill for use_figma tool calls, enabling write and read actions via JavaScript in Figma) and 'when' (explicitly states trigger conditions: before every use_figma call, when user wants write actions or unique read actions requiring JS execution, with specific examples). | 3 / 3 |
Trigger Term Quality | Includes some natural terms like 'create', 'edit', 'delete', 'components', 'variants', 'auto-layout', 'variables', and 'Figma', but misses common user phrasings like 'design', 'prototype', 'UI', 'layout', 'style'. The heavy focus on technical implementation terms (nodes, tokens, JavaScript execution) may not match how users naturally phrase requests. | 2 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — it's specifically tied to the `use_figma` tool and Figma file context with JavaScript execution. The mandatory prerequisite framing and specific tool name make it very unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality, well-structured skill that provides comprehensive, actionable guidance for using the Figma Plugin API via the use_figma tool. Its greatest strengths are the executable code examples, clear incremental workflow with validation checkpoints, and well-organized progressive disclosure to reference docs. The main weakness is moderate redundancy — several critical rules (page switching, return values, font loading) are restated across multiple sections, which inflates token count without adding new information.
Suggestions
Consolidate repeated rules (page switching, return values, font loading) — state each once authoritatively and cross-reference rather than restating in Critical Rules, Page Rules, Pre-Flight Checklist, and Error Recovery sections.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is lengthy but most content earns its place — the API rules, gotchas, and patterns are things Claude wouldn't inherently know. However, there's some redundancy: the same rules (e.g., page switching, return values, font loading) are repeated across multiple sections (Critical Rules, Page Rules, Pre-Flight Checklist, Error Recovery table). Some tightening is possible without losing clarity. | 2 / 3 |
Actionability | Excellent actionability throughout — executable JavaScript code examples for every major concept (page switching, node queries, auto-layout creation, inspection scripts), concrete error-to-fix mapping tables, specific API calls with correct syntax, and a copy-paste-ready pre-flight checklist. The query selector syntax documentation with examples is particularly strong. | 3 / 3 |
Workflow Clarity | Outstanding workflow clarity with explicit incremental workflow steps (inspect → skeleton → fill → validate → fix), validation checkpoints at each stage with a table specifying what to check and how, atomic error recovery with a clear stop-read-fix-retry sequence, and feedback loops for error correction. The suggested step order for complex tasks and the validation matrix are exemplary. | 3 / 3 |
Progressive Disclosure | Excellent progressive disclosure with a clear reference table (Section 10) mapping each doc to when to load it and what it covers. References are one level deep, clearly signaled with relative paths, and organized by task type. The main SKILL.md serves as a comprehensive overview while deferring detailed patterns, gotchas, and API specifics to dedicated reference files. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
fabc1ca
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.