Content
92%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A strong orchestration-layer SKILL.md: phased workflow with explicit validation checkpoints, copy-paste executable snippets, state management for long runs, and exemplary progressive disclosure (phase-mapped reference table, verified one-level-deep bundle). The main improvement opportunity is removing the substantial rule duplication between the Critical Rules and Anti-Patterns sections and pushing the library-discovery API detail into its reference doc.
Suggestions
Deduplicate Section 9 (Per-Phase Anti-Patterns) against Section 3 (Critical Rules) — roughly ten anti-patterns restate rules verbatim (ALL_SCOPES, raw-value duplication, INSTANCE_SWAP for icons, variant-matrix cap, never parallelize, never guess IDs, helper scripts); keep one canonical location and cross-reference it.
Move the get_libraries return-shape commentary and pagination details from Section 5 into references/discovery-phase.md, keeping only the reuse decision matrix and search invocation examples in the body.
Trim the communication-contract detail in Section 1 (checklist/summary posting rules) to its essential rules — the format examples and conditional clauses could be stated in half the lines.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and domain-specific — plugin-data workarounds, state-ledger JSON, scope/code-syntax tables, reuse decision matrix — with no padding explaining concepts Claude already knows. However, Section 9 (per-phase anti-patterns) restates roughly ten rules already given verbatim in Section 3 (ALL_SCOPES, aliasing vs raw values, INSTANCE_SWAP for icons, variant-matrix cap of 30, never parallelize, never guess IDs, use helper scripts), and Section 5 inlines get_libraries return-shape detail that belongs in references/discovery-phase.md — so it could be tightened, matching the score-4 anchor (efficient, minor instances that could be trimmed) rather than 5 (every token earns its place) or 3 (noticeably padded). | 4 / 5 |
Actionability | Guidance is fully executable: copy-paste JavaScript for setSharedPluginData tagging, concrete search_design_system/get_libraries invocation examples with parameter shapes, a full state-ledger JSON example, exact code-syntax formats ('var(--color-bg-primary)'), nine named helper scripts in scripts/ with their purposes, and per-phase checklists with literal task IDs. Specific examples cover the common cases; nothing is pseudocode or hand-wavy. | 5 / 5 |
Workflow Clarity | The five phases (0–4) are strictly ordered with per-phase checklists, exit criteria ('every token from the agreed plan exists, all scopes set, all code syntax set'), explicit validation steps (get_metadata after every create, get_screenshot after each component), idempotency checks before every create, a resume protocol for context truncation, and a required-on-error reference (error-recovery.md) — matching the score-5 anchor of clear sequence, explicit validation, feedback loops, and checklists. Not below 5 because validation and recovery are pervasive, not implicit. | 5 / 5 |
Progressive Disclosure | The body is an orchestration overview with well-signaled, one-level-deep references: Section 10 maps each of the seven references/ docs (all verified to exist) to its phase with Required/Optional and 'Load when' columns, and Section 11 lists all nine scripts/ files (all verified to exist) with purposes. Bulk detail (token creation, component creation, error recovery) is correctly deferred to references rather than inlined. The only external pointer is the cross-skill ../figma-use/references/gotchas.md link, which is a declared prerequisite skill, not a nested reference. | 5 / 5 |
Total | 19 / 20 Passed |