CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

review-design

Use when reviewing how a branch changes the look of a screen, or sweeping one surface with --full, against the DESIGN.md or wiki page that governs it and the shared component packages @shared/ui, @cire/ui and @osn/auth-ui. Lists every element the diff draws by hand and the component that already draws it, checks tokens, shape, colour and contrast, focus, motion, type and copy, layout and the tests that hold a look, measures every contrast or geometry claim, and reports U-C/H/M/L findings in the four-field format.

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An exceptionally actionable, well-sequenced review procedure whose every command and pattern is executable and repo-grounded, with strong validation and failure-handling. Its weaknesses are length and repetition — the report shape and read-only rules are enforced redundantly across sections — and a monolithic single-file layout where some reference material could live in bundle files.

Suggestions

State the six-permitted-headings rule and the read-only constraint once each (Step 0 and the "This is a review" paragraph) and refer back to them from later sections, cutting the repeats in "Report shape", the bold-label rule, and Step 5's break-ui passage.

Move the hand-drawn-element lookup table and the per-section grep patterns in Step 4 into a references/ bundle file (e.g. references/element-table.md and references/section-checks.md) linked from the body, slimming the always-loaded SKILL.md to the workflow itself.

Trim rhetorical framing (e.g. "A number nobody measured, written as though someone had, is the one fault this lens must not commit") to plain instructions; the surrounding rules already carry the requirement.

DimensionReasoningScore

Conciseness

The body is dense and almost entirely repo-specific (no explanations of concepts Claude already knows), but at ~630 lines it could be tightened: the six-heading report shape is enforced in three separate places (Step 0, the bold-label rule, "Report shape" plus the closing grep check), "reports and changes nothing" is restated in Step 5 and the break-ui section, and rhetorical passages ("A number nobody measured... is the one fault this lens must not commit") pad beyond instruction. This fits the mostly-efficient-could-be-tightened anchor rather than the minor-trims anchor.

3 / 5

Actionability

Fully executable throughout: a verbatim heredoc report skeleton, exact base-branch resolution commands, per-section grep patterns, a three-step component-lookup procedure with literal git grep invocations, a complete runnable bun -e contrast script including the alpha-flattening helper, and exact finding templates with tier rules — copy-paste ready and covering the common cases.

5 / 5

Workflow Clarity

Steps 0–5 are clearly sequenced with explicit validation checkpoints (the closing grep -c shape check where "Both must print 6"), error-recovery paths ("When a step cannot run", the unmeasured protocol, resume-from-report-file behaviour), and per-step ordering rules (record each finding the moment you have it). The skill is explicitly read-only, so the destructive-operation cap does not apply.

5 / 5

Progressive Disclosure

No bundle files exist, and all external material — DESIGN.md sections, wiki pages, sibling skills' SKILL.md/STANDARDS.md — is referenced one level deep with explicit paths and section names, clearly signalled. It stops short of 5 because the 630-line single file inlines substantial always-referenced material (the hand-drawn-element table, the per-section patterns) that could be split out, leaving the overview role less lean than the clear-overview anchor.

4 / 5

Total

17

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, highly specific description that explicitly pairs a concrete when-clause (including the --full sweep mode) with a comprehensive list of what the skill does, and anchors itself to named repo artefacts that make it distinctive. Its only weakness is keyword breadth: it lacks the synonym variations (design review, design system, UI, visual) a user might naturally say.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete actions — "Lists every element the diff draws by hand and the component that already draws it", "checks tokens, shape and colour and contrast, focus, motion, type and copy, layout and the tests that hold a look", "measures every contrast or geometry claim", "reports U-C/H/M/L findings in the four-field format" — with comprehensive coverage of the skill's behaviour, matching the anchor for multiple specific concrete actions rather than the minor-gaps anchor below it.

5 / 5

Completeness

It explicitly answers both questions: the trigger clause "Use when reviewing how a branch changes the look of a screen, or sweeping one surface with --full" gives a concrete, specific when (including the --full variant), and the enumerated action list gives a clear what. This matches the anchor requiring both, with concrete trigger phrases, rather than the 4 anchor where the when could be more specific.

5 / 5

Trigger Term Quality

Good keyword coverage: "reviewing how a branch changes the look of a screen", "DESIGN.md", "component", "tokens", "contrast", "layout" are natural phrasings. It stops short of the 5 anchor because common synonyms a user would say — "design review", "design system", "UI", "visual" — are absent, and "design" appears only inside the filename DESIGN.md.

4 / 5

Distinctiveness Conflict Risk

The niche is tightly pinned to look/design review of branch diffs against named governing documents (DESIGN.md, wiki page) and named packages (@shared/ui, @cire/ui, @osn/auth-ui), with distinct triggers and minimal overlap risk against neighbouring review lenses (security, performance), matching the clear-niche anchor.

5 / 5

Total

19

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (635 lines); consider splitting into references/ and linking

Warning

referenced_paths_exist

Referenced path issues: 1 missing, 1 deeper-than-1-level

Warning

Total

14

/

16

Passed

Repository

englishstreetventures/osn

Path

.claude/skills/review-design/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.