Content
67%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 well-engineered, deeply actionable skill for a genuinely complex domain: the tool分工, merge precedence, and validation-before-batching rules are concrete and specific, and the six reference files are real, well-signaled, and one level deep. The main weakness is token efficiency — significant rule repetition, duplicated reference-loading instructions, and dense multi-clause sentences that could be tightened, plus some gotcha-level detail that could migrate to the references.
Suggestions
State the exact-nodeId-over-fallbackNodeId precedence rule once (in Step 3) and reference it from the Overview and Step 2 instead of re-explaining the instance-vs-backing-component rationale in three places.
Consolidate reference-loading instructions into the References section's per-file 'Load when...' conditions, keeping only the first inline mention per file, to remove the 3-4 repeated 'Load references/gotchas.md' directives.
Move the detailed transformTemplate composition formula and interleaved-transform offset arithmetic into references/examples-and-anti-examples.md (already the designated home for worked examples), keeping only the wrapper > static-transform > inner nesting rule and a pointer in the body.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with genuinely novel Figma-specific signal (no padding with concepts Claude already knows), but key rules are repeated: exact-vs-fallbackNodeId matching is explained three times (Overview, Step 2, Step 3), and load-this-reference instructions for gotchas.md/examples-and-anti-examples.md appear in 3–4 places each. Several sentences (the transformTemplate composition bullet, Rule 1's exception chain) are long and winding and could be tightened, matching 'mostly efficient but could be tightened' rather than anchor 4's 'minor instances'. | 3 / 5 |
Actionability | Concrete tool-call signatures (get_design_context(fileKey=..., nodeId=...)), exact timing formulas ("startMs + orderPosition * staggerStepMs"), explicit precedence rules (exact id > fallbackNodeId > name/position), and usable code patterns (transformTemplate={(_, generated) => "<css> " + generated}) give mostly executable guidance. Not 5 because the inline snippets are fragments with placeholder arguments and complete worked examples are delegated to a reference file rather than covering the common cases inline. | 4 / 5 |
Workflow Clarity | Five clearly sequenced steps with per-step sub-instructions, and Step 5 plus Critical Rule 4 provide an explicit validation checkpoint with a feedback loop ("Spot-check one animation runs end-to-end (reload, observe, iterate) before batching") — so the batch-operation cap does not apply. Below anchor 5 because there is no consolidated checklist for the intricate Step 3 merge (id matching, wrappers, split nodes, SVG paths) and error recovery beyond 'iterate' is mostly implicit. | 4 / 5 |
Progressive Disclosure | All six referenced files exist in references/ and are one level deep, each linked inline at point-of-need and catalogued in a References section with 'Load when...' conditions — good structure and easy navigation. Below anchor 5 because the SKILL.md body itself carries heavy gotcha-level detail inline (e.g., the full interleaved-transform and transformTemplate-composition mechanics) that belongs in the examples/gotchas references, and load instructions are duplicated across Step 3, Step 5, Critical Rules, Examples, and References sections. | 4 / 5 |
Total | 15 / 20 Passed |