design-taste-frontend-v1

The original v1 taste-skill, preserved for projects depending on its exact behavior. The current default is `design-taste-frontend` (v2 experimental), which is a substantial rewrite. Use this v1 install name only if you need exact backward compatibility.

Quality

44%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/taste-skill-v1/SKILL.md

Quality

Content

56%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.

The content is highly actionable and well-sequenced with a strong pre-flight checklist, but it is token-heavy and largely monolithic, re-explaining well-known UI patterns and inlining a sizable inspiration catalog that would be better split into reference files. It reads as a comprehensive directive list rather than a lean overview pointing to deeper material.

Suggestions

Trim Section 8 (The Creative Arsenal) to a short pointer list or extract it into a separate references file, since most named effects are concepts Claude already knows and their enumeration adds significant tokens.

Consolidate repeated guidance (spring physics, layout/layoutId, perpetual motion rules appear in both Section 4 and Section 9) to reduce redundancy.

Move the dial definitions in Section 6 and the Bento archetype specs in Section 9.C into reference files referenced from SKILL.md to improve progressive disclosure.

Dimension	Reasoning	Score
Conciseness	At ~220 lines the body is noticeably verbose: Sections 8 and 9 catalog dozens of named effects (Mac OS Dock Magnification, Gooey Menu, Holographic Foil Card, etc.) that largely enumerate concepts Claude already knows, and many directives repeat guidance already stated in earlier sections.	2 / 5
Actionability	It provides concrete, executable guidance throughout — specific Tailwind classes, import paths, Framer Motion props, and exact rules (e.g. min-h-[100dvh], type: spring stiffness: 100 damping: 20) — with only minor gaps where named effects are listed without implementation detail.	4 / 5
Workflow Clarity	Sections are numbered and the final Section 10 pre-flight checklist provides explicit verification checkpoints, but the generation workflow is directive-driven rather than a validate→fix→retry loop, so the sequence is clear with minor validation gaps.	4 / 5
Progressive Disclosure	The skill is a single monolithic SKILL.md with no bundle files; the large inspiration catalog (Sections 8–9) and dial definitions could be split into reference files, so structure exists but content that should be external is inlined.	3 / 5
	Total	13 / 20 Passed

Description

32%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.

The description is honest about its purpose (a backward-compatible v1 preserved variant) but fails to communicate what the skill actually does or when to invoke it, functioning more as a versioning footnote than a capability statement. It is distinct from its v2 sibling but largely unactionable for trigger selection.

Suggestions

Lead with a concrete 'what' — e.g. 'Generates polished, high-agency frontend marketing UIs with enforced typography, color, motion, and anti-slop guardrails' — before the version compatibility note.

Add an explicit 'Use when...' clause with natural trigger phrases such as 'design taste v1', 'high-agency frontend', or 'anti-slop frontend', so the description itself signals when to invoke it.

Move the v1-vs-v2 compatibility rationale to a trailing sentence so the opening line communicates capability rather than preservation status.

Dimension	Reasoning	Score
Specificity	The description names the skill's domain (a frontend design/taste skill and its version lineage) but states no concrete capabilities — there is no mention of what it actually does (e.g. generating marketing pages, applying typography/color/motion guardrails), only that it is 'preserved' for compatibility.	2 / 5
Completeness	It gives a vague 'what' (a preserved taste-skill kept for compatibility) and no 'when' clause telling Claude when to use it; the only conditional guidance is about version selection, not task triggers, capping completeness per the missing-trigger-guidance rule.	2 / 5
Trigger Term Quality	The only user-facing phrases are 'exact backward compatibility' and 'v1 install name'; it lacks the natural keywords a user would say to invoke the skill, relying instead on internal trigger terms not surfaced in the description.	2 / 5
Distinctiveness Conflict Risk	It is clearly distinct from the v2 default via explicit version pinning and backward-compatibility framing, with only minor overlap risk against the sibling design-taste-frontend skill.	4 / 5
	Total	10 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: nexu-io/open-design
Path: skills/taste-skill-v1/SKILL.md
Commit: 1a7a23d

Reviewed: about 3 hours ago

Table of Contents

Discovery Implementation Validation

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.