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 is a well-structured, opinionated design guide with concrete rules, specific anti-patterns (named hex values, typography tells), and a clear plan-review-build-critique workflow with an explicit pre-build checkpoint. Its main weakness is conciseness — the flowing prose could be tightened — and the absence of any progressive split given it runs slightly long for a single file.
Suggestions
Tighten the longest paragraphs (e.g. the opening studio framing and the AI-generated-traits list) into scannable bullets or shorter sentences; cut phrases that restate the same point.
Consider moving 'More on writing in design' into a separate reference file (e.g. WRITING.md) and linking to it from the body, leaving the core design guidance leaner and under the simple-skill threshold.
Add a short explicit critique checklist (e.g. 'before finishing: confirm palette is not a default tell, type is not the cliché default, motion is restrained, one memorable element') to push workflow clarity from a clear sequence toward a checklist-driven loop.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is genuinely substantive opinionated guidance Claude does not already know (specific AI-generated tells with exact hex values, concrete typography anti-patterns), so it is not penalized for explaining known concepts; however the prose is dense and lengthy with multi-paragraph flow (e.g. lines 9, 17, 30, 43, 45) that could be tightened. Fits the 3 anchor ('mostly efficient but includes some unnecessary explanation or could be tightened') rather than 4, because several paragraphs carry padding that does not earn its place. | 3 / 5 |
Actionability | Concrete, specific guidance throughout: 'line lengths of less than 80 characters', '4–6 named hex values', explicit anti-patterns to avoid with exact codes (#F4F1EA, #D97757, #0B0B0B), and a two-pass process producing a token system with ASCII wireframes. As an instruction-only skill the absence of code is not penalized; it stops at 4 rather than 5 because some directives stay abstract ('take aesthetic risk if justified', 'Spend your boldness in one place') with no concrete decision procedure. | 4 / 5 |
Workflow Clarity | The Process section gives a clear sequence — brainstorm token plan, review against the brief, revise, then 'Only after you've confirmed the relative uniqueness of your design plan should you start to write the code', plus self-critique while building. This is a clear sequence with a real pre-build checkpoint; it is not 5 because there is no explicit error-recovery feedback loop or checklist, and not 3 because the review-against-brief checkpoint is explicit. The skill is design-oriented, not destructive/batch, so the feedback-loop cap does not apply. | 4 / 5 |
Progressive Disclosure | No bundle files exist and the skill is self-contained with clear section headers ('Design principles', 'Process', 'Restraint and self-critique', 'More on writing in design'), no nested or broken references, and nothing that clearly belongs in a separate file. It is a 4 rather than 5 because the body is slightly over the ~50-line simple-skill threshold and the 'More on writing in design' section is tangential enough that it could plausibly be split off, leaving the core leaner. | 4 / 5 |
Total | 15 / 20 Passed |