figma-use

**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.

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/figma/skills/figma-use/SKILL.md

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a highly actionable, dense reference for the Figma Plugin API with an exemplary incremental workflow, validation checkpoints, and well-organized one-level-deep references that all exist on disk. Its main weaknesses are repetition of the same critical rules across multiple sections and inlining of detailed API surface (the query selector grammar) that would fit better in a reference file.

Suggestions

Consolidate the repeated setCurrentPageAsync, layoutSizing, and font-load guidance: state each rule once in Section 1 and have Sections 2, 7, and 8 reference it by anchor instead of restating it, cutting a substantial fraction of tokens.

Move the full query selector grammar and QueryResult methods table (Section 5) into a reference file (e.g., references/query-api.md), keeping only 2–3 illustrative examples and the scope note in SKILL.md.

Trim the pre-flight checklist by removing items that restate Critical Rules verbatim and keeping only the checks that are not already stated above.

Dimension	Reasoning	Score
Conciseness	Nearly all content is genuinely non-obvious, tool-specific knowledge (atomic failed scripts, per-call page resets, the font-load recipe, layoutSizing enum rules, exact error strings) with almost no explanation of concepts Claude already knows. However, the same critical rules are restated across Sections 1, 2, 7, and 8 — setCurrentPageAsync guidance appears roughly five times and Rule 12/12b content is repeated in the error-recovery table and pre-flight checklist — so it could be meaningfully tightened rather than being fully efficient.	3 / 5
Actionability	Fully executable throughout: copy-paste-ready JS snippets (page switching, query/set, createAutoLayout, inspection scripts), a complete selector grammar with worked examples, a QueryResult methods table, and error-message-to-fix mappings keyed to literal error strings. Below-anchor arguments don't apply — the common cases are covered with concrete code.	5 / 5
Workflow Clarity	The incremental workflow is explicitly sequenced (inspect first → skeleton with placeholders → incremental fill → return IDs → validate after each step), with a per-step validation table, explicit feedback loops in error recovery (STOP → read error → fix → retry, leveraging atomicity), a suggested step order, and a pre-flight checklist. This matches the top anchor's validate-fix-retry pattern exactly.	5 / 5
Progressive Disclosure	A Reference Docs table maps each of eleven real on-disk reference files to a 'when to load' trigger and coverage summary, with deep anchors into specific sections — clear, one-level-deep, well-signaled navigation. It falls short of anchor 5 because Section 5 inlines a full selector grammar and QueryResult API table that belong in a reference file, making the overview itself heavier than the ideal quick-start form.	4 / 5
	Total	17 / 20 Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has strong, concrete trigger coverage for the Figma Plugin API domain and answers both what and when, but it front-loads mandatory-invocation rhetoric in second person ('you MUST invoke this skill BEFORE every use_figma tool call') that crowds out a direct statement of the skill's capability. Tightening the lead to a third-person capability statement would raise specificity and completeness.

Suggestions

Lead with a third-person capability statement (e.g., 'Executes JavaScript in Figma files via the Plugin API, covering node creation/editing, variables, components, variants, auto-layout, and fills.') before the invocation prerequisite, removing the second-person phrasing that costs specificity.

Add natural user phrasings as triggers — 'edit a Figma file', 'change colors/fills in Figma', 'build a design system component' — so the description fires when users describe tasks without naming the use_figma tool.

Trim the imperative framing ('MANDATORY', 'NEVER call use_figma directly without loading this skill first') to a single clause; the rest is repeated enforcement rather than capability or trigger information.

Dimension	Reasoning	Score
Specificity	The description lists several 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'), which alone fits anchor 4, but the second-person voice ('you MUST invoke this skill') incurs the rubric's 1-point specificity penalty and the 'MANDATORY prerequisite / NEVER call use_figma directly' framing is invocation protocol rather than capability description. It is above anchor 2 because the domain and multiple concrete actions are genuinely named, not generic.	3 / 5
Completeness	Both what ('perform a write action or a unique read action that requires JavaScript execution in the Figma file context') and when ('Trigger whenever the user wants to...') are explicitly present with concrete trigger examples. Below anchor 5 because the leading sentences describe when-to-invoke protocol rather than clearly stating what the skill provides (Plugin API rules and workflows), making the 'what' indirect.	4 / 5
Trigger Term Quality	Good natural keyword coverage for the domain — 'variables or tokens', 'components and variants', 'auto-layout', 'fills', 'bind variables to properties', 'inspect file structure'. A few natural user phrasings are missing ('edit my Figma file', 'change the color in Figma', 'design file'), and triggers lean on the technical tool name 'use_figma' rather than synonyms, keeping it below anchor 5.	4 / 5
Distinctiveness Conflict Risk	A clear niche — JavaScript execution in the Figma Plugin API context — with distinct triggers (variables, auto-layout, component variants). Minor overlap risk remains with closely related sibling skills (figma-generate-design, figma-generate-library, figma-use-slides) that share the same use_figma tool and Figma domain, so it does not reach anchor 5's 'minimal conflict risk'.	4 / 5
	Total	15 / 20 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 1 deeper-than-1-level, 4 suspicious	Warning
referenced_paths_exist	Referenced path issues: 1 deeper-than-1-level	Warning

	Total	14 / 16 Passed

Repository: openai/plugins
Path: plugins/figma/skills/figma-use/SKILL.md
Commit: 5fd93af

Reviewed: 2 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

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.