CtrlK
BlogDocsLog inGet started
Tessl Logo

moai-ref-ui-polish

UI polish and interface-completion reference: the small visual details — concentric border radius, optical alignment, shadow-vs-border, motion easing, typography smoothing, tabular numbers, icon stroke weight, hit areas — that separate polished interfaces from generic ones. Agent-extending skill that amplifies frontend/UI domain work with production-grade "interface taste" rules. NOT for: backend logic, database design, DevOps, security audits, non-UI work.

68

Quality

82%

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

86%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 high-quality reference body: rule tables with exact, executable values, a clear review-mode/severity/verdict structure with an explicit verification checklist, and exemplary progressive disclosure that offloads depth to two well-signaled, genuinely present reference files. The only real cost is redundancy — the same rules are restated across the rule tables, Red Flags, and Verification sections — which trades token efficiency for review usability.

DimensionReasoningScore

Conciseness

The body is dense, table-driven rule statements with exact values and terse rationale columns; it explains nothing Claude already knows (no 'what CSS is' padding). It sits at 4 rather than 5 because of deliberate triplication — the same rules appear in the Motion/Interaction/Icons tables, again in Red Flags, and again in the Verification checklist — and the Core Philosophy paragraph carries some generic framing ("Great interfaces are a collection of small details that compound") that could be tightened.

4 / 5

Actionability

Guidance is fully concrete and copy-paste ready: exact values like `cubic-bezier(0.2, 0, 0, 1)`, `scale(0.96)`, `font-variant-numeric: tabular-nums`, `@media (hover: hover) and (pointer: fine)`, `transition: { type: "spring", duration: 0.3, bounce: 0 }`, and precise thresholds (44×44px touch, 40×40px desktop, ~100ms stagger, 1.5px/2px icon strokes) cover the common cases. This is an instruction/reference skill and the guidance is maximally actionable without full code blocks.

5 / 5

Workflow Clarity

The review workflow is coherently structured: Review Modes (quick/full with finding caps) → severity classification (HIGH/MEDIUM/LOW) → an explicit verdict decision table (Block / Needs changes / Approve), plus a step-one instruction to identify the project's existing styling system before suggesting changes and an explicit Verification checklist as the validation checkpoint. It falls short of 5 because the operating sequence for conducting a review (when to pick quick vs full, order of category coverage) is implied by tables rather than spelled out as a sequence.

4 / 5

Progressive Disclosure

The body keeps the high-frequency rules inline and defers deep material to two real, one-level-deep bundle files — `references/motion-principles.md` and `references/design-audit.md` (both present in the bundle) — each introduced with a clearly signaled blockquote stating what it contains and exactly when to load it ("L3, load on demand"). The design-audit reference is explicitly bound back to the same severity scale and finding caps rather than a divergent scheme, making navigation easy.

5 / 5

Total

18

/

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 strong description with a clearly articulated niche, an itemized catalog of concrete UI-polish specifics, and explicit negative boundary guidance that minimizes conflict risk. Its main gap is the absence of a positive 'Use when...' trigger clause inside the description itself (that guidance is split into a separate when_to_use field), which leaves the 'when' answer less explicit than it could be.

Suggestions

Fold a compact positive trigger clause into the description (e.g. 'Use when building or reviewing UI components, animations, hover states, or visual details'), since the description currently relies on a separate when_to_use field and a 'NOT for' list to convey when it applies.

Replace or trim the internal jargon sentence 'Agent-extending skill that amplifies frontend/UI domain work with production-grade interface taste rules' — it describes mechanics rather than capabilities and dilutes the otherwise concrete specificity.

Add a few widely-used natural trigger terms (CSS, hover/active states, micro-interactions, design polish) to the description to round out keyword coverage.

DimensionReasoningScore

Specificity

The description enumerates concrete, checkable specifics — "concentric border radius, optical alignment, shadow-vs-border, motion easing, typography smoothing, tabular numbers, icon stroke weight, hit areas" — giving comprehensive coverage of the domain's scope. It falls short of the 5 anchor because the middle sentence ("Agent-extending skill that amplifies frontend/UI domain work with production-grade 'interface taste' rules") is vague internal jargon rather than a concrete capability, and it lists covered topics rather than actions.

4 / 5

Completeness

The 'what' is explicit and detailed (a reference covering the listed visual-detail rules), and 'when' is addressed through explicit boundary guidance — "NOT for: backend logic, database design, DevOps, security audits, non-UI work" — plus the frontend/UI framing. It does not reach 5 because no positive "Use when..." trigger clause with concrete trigger phrases appears in the description itself; the positive triggers live in a separate when_to_use field, so the 'when' could be more explicit.

4 / 5

Trigger Term Quality

Natural frontend vocabulary is present ("UI polish", "border radius", "motion easing", "typography", "hit areas", "frontend/UI"), terms a user would plausibly say when needing this skill. A few common natural terms are missing from the description itself (e.g. "CSS", "hover states", "animation", "design" as trigger words), which keeps it at the 'good coverage, a few natural terms missing' anchor rather than the comprehensive-synonyms anchor at 5.

4 / 5

Distinctiveness Conflict Risk

The niche is sharply defined — visual UI polish details — and the explicit exclusion list ("NOT for: backend logic, database design, DevOps, security audits, non-UI work") plus the itemized detail catalog make it clearly distinguishable from general frontend, styling-library, or design-system skills. Only deliberate amplification of frontend skills is claimed, so conflict risk is minimal, matching the 5 anchor.

5 / 5

Total

17

/

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
modu-ai/moai-adk
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.