CtrlK
BlogDocsLog inGet started
Tessl Logo

ui

Produces distinctive production UI and screenshot-grounded visual polish. Use when building or restyling pages, components, or typography. Not for backend logic or data pipelines.

66

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

The canonical home for this skill is ui in tw93/Waza

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.

A well-structured, opinionated instruction skill: the workflow is explicitly sequenced with real validation checkpoints and recovery loops, and detail is correctly pushed into a complete, well-signaled reference bundle. The remaining costs are duplicated mode-routing prose, a few non-earning tokens, and rule text that occasionally stays at judgment level without worked examples.

Suggestions

Deduplicate the mode-routing logic between the Chinese gut-feel complaints paragraph and the Mode Picker section so each routing rule is stated once.

Number the main path steps explicitly (preflight, mode pick, direction lock, build, aesthetic review, handoff) so the base sequence stays legible under the many exception branches.

Trim low-earning tokens (e.g. the 🥷 prefix instruction) and split the longest compound sentences to lift token efficiency.

DimensionReasoningScore

Conciseness

The body is dense with novel, opinionated rules and never explains concepts Claude already knows, so it is clearly above anchor 3. It is not anchor 5 because some redundancy and padding could be trimmed: mode-routing logic is stated twice (the Chinese gut-feel paragraph and the Mode Picker paragraph both route generated-asset vs screenshot-iteration), the 'Prefix your first line with 🥷' line is a non-earning quirk token, and several very long compound sentences could be split.

4 / 5

Actionability

As an instruction-only skill it carries no code, which the scoring notes say is not penalized if guidance is actionable, and much of it is: concrete file names to grep (theme.ts, tokens.css, _variables.scss), a five-item direction checklist, a routing table with file paths, a gotchas table, and a fixed handoff output format. It stops short of anchor 5 because several rules remain judgment-level ('take colour, type, width, and voice from the current product's tokens first') without worked examples, and the anchor-5 bar of copy-paste-ready guidance covering common cases is only partially met.

4 / 5

Workflow Clarity

The flow is clearly sequenced (preflight, mode pick, direction lock, thesis summary, build, aesthetic review, handoff) with explicit validation steps: 'Do not write code until all five are resolved', the Aesthetic Review and AI Slop Test checks, and mandated viewport rendering with 'if any check fails, fix first'. Feedback loops exist (a contradictory answer reopens only the affected dimension; gotchas give recovery rules), matching anchor 5. Anchor 4's 'minor validation gaps' do not apply, though the many exception branches (app shell, dashboard, native app, document route-out) add reading overhead the sequence itself absorbs.

5 / 5

Progressive Disclosure

Scored against the actual bundle: every referenced file (durable-context.md, mode-quick-fix.md, mode-screenshot-iteration.md, mode-generated-asset.md, design-reference.md, design-native-motion.md, design-data-viz.md) exists, and the Mode Picker table signals when to load each. This is good structure per anchor 4, not anchor 5, because the body inlines a substantial amount of dense rule content beyond a pure overview, and bundle files cross-link each other (mode-quick-fix and mode-screenshot-iteration both point onward to design-reference.md), creating mild two-hop chains even though all files are also directly reachable from SKILL.md.

4 / 5

Total

17

/

20

Passed

Description

78%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 concise, third-person description that explicitly answers what, when, and what-not with a concrete negative boundary. Its weaknesses are modest breadth in the capability list and a trigger set that misses common natural phrasings for visual work.

Suggestions

Enumerate the skill's main deliverables more fully in the 'what' clause (e.g. building and restyling pages, running visual/aesthetic review against screenshots, producing design options) so specificity reaches comprehensive coverage.

Add user-natural trigger phrasings to the description itself (e.g. 'design', 'styling', 'make it look good', 'redesign', 'frontend'), which currently live only in the separate when_to_use field.

Consider naming the artifact types covered (web pages, components, app surfaces) to sharpen separation from generic frontend-development skills.

DimensionReasoningScore

Specificity

The description names the domain ("production UI and screenshot-grounded visual polish") and two concrete actions ("building or restyling pages, components, or typography"), but coverage is not comprehensive: design review, screenshot iteration, and options generation are all skill capabilities left unmentioned. It sits at anchor 3 rather than 4 because only 1-2 actions are stated, and above anchor 2 because the domain plus actions are concrete rather than generic.

3 / 5

Completeness

Both parts are explicit: what ("Produces distinctive production UI and screenshot-grounded visual polish") and when ("Use when building or restyling pages, components, or typography"), plus an explicit exclusion boundary ("Not for backend logic or data pipelines"). This matches anchor 5, which requires a clear what and when with concrete trigger phrases; anchor 4's caveat about a weakly specific 'when' does not apply.

5 / 5

Trigger Term Quality

Phrases like "building", "restyle", "pages", "components", "typography" are natural terms a user would say, matching anchor 4 (good coverage, a few missing). It stays below anchor 5 because common phrasings such as "design", "styling", "make it look good", or "redesign" are absent (they appear only in the separate when_to_use field, not the description).

4 / 5

Distinctiveness Conflict Risk

The UI-production niche is distinct and the "Not for backend logic or data pipelines" exclusion lowers mis-trigger risk, matching anchor 4 (mostly distinct, minor overlap with closely related skills). It is not anchor 5 because building/restyling pages and components could still overlap with a general frontend or web-development skill whose description covers the same surface.

4 / 5

Total

16

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
tw93/Waza
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.