Content
75%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, lean instruction skill: it relies on real bundle files with a sensible lazy-routing scheme, defines concrete rules and validation gates, and wastes almost no tokens on explanation. Its main gaps are mild redundancy in the preview/guardrail rules and a few validation steps described as outcomes rather than checkable procedures.
Suggestions
Consolidate the preview/anti-pattern prohibitions (no temp server, no helper preview HTML, no verbal assessment) into one guardrails list — they are currently repeated across the intro and workflow sections.
Make the final verification actionable: replace 'verify the resulting HTML remains readable and structurally complete' with a concrete check (e.g., parse the file, confirm the design-tokens.css link and section structure are intact).
Add a brief ordered checklist of the end-to-end flow (plan → author → check → preview → repair → re-preview) so the sequence spread across sections is readable at a glance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense, instruction-only prose with no padding about concepts Claude already knows — every line is a rule, boundary, or routing decision. There are minor instances that could be trimmed (the preview rules and 'never start a temporary server / no verbal assessment' prohibitions are stated twice across sections), matching anchor 4 'Efficient; minor instances of over-explanation that could be trimmed' rather than anchor 5's every-token-earns-its-place. | 4 / 5 |
Actionability | Guidance is concrete: exact tool invocations ('call `media/artifact_media_review` phase=plan ... with the active HTML sourcePath'), real file paths ('design-tokens.css', 'core-v1-index.md'), token namespaces ('--ipw-*'), and explicit numbered editing rules. Minor gaps remain — e.g., 'verify the resulting HTML remains readable and structurally complete' gives no method — so it sits at anchor 4, not 5's fully copy-paste-ready coverage. | 4 / 5 |
Workflow Clarity | A clear sequence exists (pre-authoring phase=plan, edit rules 1-6, pre-delivery phase=check, preview review then re-review after repairs) with explicit checkpoints and feedback loops ('again only after repairing reported issues', 'stop without changing the file and ask the user'). It falls short of anchor 5 because the workflow is distributed across sections rather than a single ordered checklist, and a few validations ('inspect rendered sections for overflow') lack concrete procedures — anchor 4 fits. | 4 / 5 |
Progressive Disclosure | The bundle structure matches the body's claims: references/shared-guidelines.md and references/design.md both exist, and design.md is a routing table that points to the real category files (design-site.md, design-app.md, design-poster.md, etc.), giving one deliberate lazy-routing hop ('read ... once, then only the matching category reference'). Slightly below anchor 5 because SKILL.md → design.md → category file is a two-hop chain and the body also points at files owned by sibling skills, which slightly muddies navigation. | 4 / 5 |
Total | 16 / 20 Passed |