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.
The body delivers genuinely non-obvious, opinionated design guidance with a concrete two-pass plan-review workflow and specific calibration tells, and it is well organized as a self-contained file. Its main weaknesses are restating UX/typography fundamentals Claude already knows and lacking a worked example of the design-plan output it asks for.
Suggestions
Trim or compress sections that restate known fundamentals (line-length and line-height rules, active voice, CTA naming, error-tone guidance) down to the design-specific deltas, keeping only what Claude would not already do by default.
Add a compact worked example of the token-system design plan (a short palette/type/layout/principles sketch) so the two-pass process has a concrete output template to emulate.
Consolidate the process into one numbered sequence (ground -> plan -> review against brief -> build -> critique) with the critique step as an explicit checkpoint, replacing the informal 'See the below section on writing' cross-reference with a proper section link.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The bulk is non-obvious, high-value guidance (the calibration list of AI-generated tells with specific hex values, the two-pass plan-review process), but portions restate knowledge Claude already has — 'Default to line lengths of less than 80 characters', 'Use active voice as default. A CTA says exactly what happens when it is used', 'Errors don't apologize' — and could be tightened, matching anchor 3 rather than 4. | 3 / 5 |
Actionability | For an instruction-only skill the guidance is largely executable: 'describe the core base palette as 4-6 named hex values', a defined plan artifact (color/type/layout/principles with ASCII wireframes), specific tells to avoid with concrete values, and a CSS specificity warning. Minor gaps — no example design plan or code snippet — keep it at anchor 4 rather than 5. | 4 / 5 |
Workflow Clarity | A clear sequence exists — ground in subject matter, brainstorm a token plan, 'review that plan against the brief before building', 'Only after you've confirmed the relative uniqueness... should you start to write the code', then self-critique with screenshots — with an explicit review checkpoint. The build-time critique is soft ('if your environment supports it') and the sequence is distributed across sections rather than one ordered list, so anchor 4 rather than 5; no destructive/batch cap applies. | 4 / 5 |
Progressive Disclosure | No bundle files exist, and the single-file body is well sectioned (subject grounding, principles, process, restraint, writing) and appropriately self-contained. At ~65 lines it slightly exceeds the under-50-line simple-skill exception, and 'See the below section on writing for more guidance' is an informal cross-reference, so anchor 4 rather than 5. | 4 / 5 |
Total | 15 / 20 Passed |