Conciseness

The body is mostly tight, decision-dense prose (non-negotiables, a numeric density-limit table, anti-patterns) that assumes Claude's competence, matching anchor 4. It is not anchor 5 because of minor trims available: viewport-fit rules repeat across four sections, a credit line about @zarazhangrui adds little actionable value, and bullets like "keep contrast readable" state knowledge Claude already has.

Actionability

Guidance is largely executable and specific: exact CSS rules ("height: 100vh; height: 100dvh; overflow: hidden;"), clamp() scaling, five concrete validation viewport sizes, OS-specific opener commands, and the python-pptx tool choice — matching anchor 4 for mostly executable guidance with minor gaps. It misses anchor 5 because the core implementation artifact (the mandatory viewport-safe CSS block) is delegated to STYLE_PRESETS.md rather than shown, and no runnable code sample exists.

Workflow Clarity

The 7-step workflow (detect mode, discover content, discover style, build, enforce viewport fit, validate, deliver) is clearly sequenced with an explicit validation step listing concrete sizes and browser-automation checks, an error-recovery directive ("when content does not fit, split into multiple slides"), a fallback when python-pptx is unavailable, and a final Deliverable Checklist. This matches anchor 5: explicit validation steps, feedback for error recovery, and a checklist.

Progressive Disclosure

Scored against the actual bundle: the body references `STYLE_PRESETS.md` twice ("read STYLE_PRESETS.md for the viewport-safe CSS base", "Use the density limits and mandatory CSS block in STYLE_PRESETS.md") but that file does not exist in the bundle, and the two bundle scripts (scripts/extract-pptx.py, scripts/export-pdf.sh) are never referenced from the body, leaving them undiscoverable. Section structure in the body itself is good and references are clearly signaled, which keeps this above anchor 2, but broken references and orphaned bundle files are more than the 'minor organization gaps' of anchor 4.

Specificity

The description lists several concrete actions — "Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files" and "discover their aesthetic through visual exploration" — which matches the anchor for several specific actions with minor gaps. It falls short of anchor 5 because coverage is not comprehensive (e.g., enhancing existing decks is a body capability not named), and 'stunning' is mild buzzword padding.

Completeness

It explicitly answers both questions: the what is "Create... HTML presentations from scratch or by converting PowerPoint files" and the when is an explicit "Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch" with concrete trigger phrases. This matches the anchor-5 example structure exactly; anchor 4 would require a weaker or less specific 'when' clause.

Trigger Term Quality

Natural trigger phrases are well covered: "build a presentation", "convert a PPT/PPTX to web", "create slides for a talk/pitch", plus "PowerPoint files" and file-extension mentions. It sits between anchor 4 and 5 because common synonyms like 'deck' are missing, keeping it below comprehensive synonym/extension coverage.

Distinctiveness Conflict Risk

The niche (browser-based HTML presentations, web conversion of PPT/PPTX) is distinct with trigger phrases unlikely to fire for unrelated skills. It is not anchor 5 because there is minor overlap risk with generic .pptx authoring/editing skills, which share the 'presentation' and 'PPT' vocabulary.