Content
71%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 highly actionable, platform-specific skill with executable examples, explicit layout-QA validation, and well-signaled one-level-deep references for optional features. Its main weaknesses are duplicated guidance that inflates the always-loaded context, and large parameter/format/strategy sections that belong in reference files per its own progressive-disclosure pattern.
Suggestions
Deduplicate repeated guidance: keep one canonical statement of the run_sdk_snippet rule, the ≤100-char edit threshold, and the image-keyword rules (merge "Image Requirements" keyword bullets into the "image_search Keyword Strategy" section or vice versa).
Move the tool parameter tables, magic.project.js JSONP format spec, and slide_images_content format template into references/ files (e.g. references/slide-tools.md), linking from the body the way in-page-builds.md and slide-transitions.md already are.
Resolve the contradictory height guidance: the template comment "DO NOT set height or max-height, allow extreme cases to exceed" under an explicit height: 1080px contradicts the "strictly no overflow" hard requirement, and remove or reconcile the unused slide_count parameter.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Most of the ~1050 lines carry platform-specific contract detail Claude cannot know (tool params, magic.project.js, font specs), but the same guidance is repeated several times: the run_sdk_snippet warning appears 3 times, the ≤100-char edit threshold in "Tool Selection Principles" is restated in "Edit Slide Workflow", and image-keyword rules are duplicated between "Image Requirements" and the full "image_search Keyword Strategy" section. This matches "mostly efficient but includes some unnecessary explanation or could be tightened"; not 2 because the bulk is genuinely novel, required specification rather than padding. | 3 / 5 |
Actionability | Copy-paste-ready code covers the common cases: complete create_slide_project and create_slide calls with real parameter dicts and a working analysis_js body, full image_search/web_search requirement examples, and a complete HTML template with CDN URLs. Placeholder """...""" bodies in the second/third slide examples are clearly marked template illustration, which is justified flexibility. | 5 / 5 |
Workflow Clarity | The Complete Creation Workflow is clearly sequenced with explicit validation (create_slide runs analysis_js layout QA) and a bounded feedback loop ("Serious issues: fix at most once, if unresolved continue next page"; "An unknown outcome requires rereading before further writes"), and edit/move workflows add per-task steps. Not 5 because the template's contradictory comment "height: 1080px; /* DO NOT set height or max-height, allow extreme cases to exceed */" directly conflicts with the stated hard requirement "Page height must strictly not exceed 1080px", and the create_slide_project table's slide_count parameter is documented but never used coherently in the examples. | 4 / 5 |
Progressive Disclosure | The three reference files exist, are one level deep, and are well-signaled with conditional loading ("When the user requests click-controlled reveals, read [in-page-builds.md]"), with the cited #production-plan-format anchor verified as real. However, a large amount of reference-grade content is inlined in the always-loaded SKILL.md — full tool parameter tables, the magic.project.js JSONP format spec, the slide_images_content format template, and the multi-section image_search keyword strategy — fitting "content that should be separate is inline"; not 4 because that inline bulk is substantial, not a minor gap. | 3 / 5 |
Total | 15 / 20 Passed |