CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

49

Quality

54%

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

Fix and improve this skill with Tessl

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

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 a dense, unusually actionable rulebook — nearly every directive carries exact classes, values, or library APIs. Its weaknesses are redundancy (rules restated across Sections 2/4/7/9/10), a long catalog of concepts Claude already knows, and a monolithic structure with no progressive disclosure into reference files.

Suggestions

Deduplicate rules repeated across Sections 2, 4, 7, 9, and 10 (spring physics, anti-Inter, layout/layoutId, dvh/mobile-collapse) by stating each once and cross-referencing — this would substantially improve conciseness.

Move Section 8 (The Creative Arsenal) and Section 6 (Dial Definitions) into a references/ file (e.g. references/arsenal.md), keeping SKILL.md as a lean overview with clearly signaled one-level-deep links.

Add one worked example (a small Hero or Bento component) that demonstrates the rules composed together, closing the gap between directive-list and executable output.

DimensionReasoningScore

Conciseness

The ~250-line body repeats the same directives across sections — spring physics (`stiffness: 100, damping: 20`) in Sections 4 and 9, the Inter ban in Sections 3 and 7, `layout`/`layoutId` in 4 and 9, `min-h-[100dvh]` and mobile collapse in 2, 6, and 10 — and Section 8 catalogs ~50 concepts (Bento Grid, Masonry, parallax, marquee) Claude already knows. Not 1 because there is no textbook-style explanation of basics; not 3 because the duplication and known-concept catalog are substantial padding that could be cut roughly in half.

2 / 5

Actionability

Guidance is highly concrete: exact Tailwind classes (`max-w-[1400px] mx-auto`, `text-4xl md:text-6xl tracking-tighter leading-none`), exact Framer Motion params, exact placeholder URLs (`https://picsum.photos/seed/{random_string}/800/600`), and install-path requirements. Not 5 because there is no worked end-to-end example combining the rules into runnable output; not 3 because nothing is pseudocode or abstract — every directive is directly implementable.

4 / 5

Workflow Clarity

The flow is legible — baseline dials drive Sections 3–7 ("Use these baseline (or user-overridden) values as your global variables to drive the specific logic in Sections 3 through 7") and Section 10 provides an explicit pre-flight validation checklist ("Evaluate your code against this matrix before outputting"). Not 5 because there is no error-recovery/feedback loop and the inter-section flow is otherwise topical rather than sequenced; not 3 because the closing checklist is an explicit, itemized checkpoint.

4 / 5

Progressive Disclosure

The body is well-sectioned with clear numbered headers, but everything is inlined in a single monolithic SKILL.md with no bundle files — Section 6 (dial definitions) and Section 8 (the creative arsenal) are reference-style catalogs that clearly belong in separate files. Not 2 because structure and navigation within the file are good; not 4 because roughly 100 lines of reference material should be split out per progressive-disclosure practice.

3 / 5

Total

13

/

20

Passed

Description

52%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 excellent at version disambiguation and conflict avoidance, but it says nothing about what the skill functionally does. A user or Claude scanning it cannot learn that this is a frontend design/taste skill, so it would rarely be selected on capability grounds.

Suggestions

State what the skill does before its provenance, e.g. 'Applies opinionated frontend design taste (typography, motion, anti-slop guardrails) for React/Tailwind projects' — this would lift specificity and completeness.

Add functional trigger phrases to the description (e.g. 'design taste', 'polished marketing page', 'anti-slop frontend') so natural user language matches, rather than relying only on versioning keywords.

Keep the v1/v2 disambiguation — it is the description's strongest asset.

DimensionReasoningScore

Specificity

The description names its identity ("The original v1 taste-skill") but lists no concrete actions — it never states what the skill does (frontend UI generation, typography, motion, anti-slop guardrails). Not 1 because it is not pure abstraction (it conveys versioning/provenance); not 3 because there are no 1-2 concrete functional actions at all.

2 / 5

Completeness

"When" is explicit ("Use this v1 install name only if you need exact backward compatibility") but "what" is vague — the skill's actual function is never described. Not 2 because a specific when-clause is present alongside a (weak) what; not 4 because the what is provenance-only, with no statement of capability.

3 / 5

Trigger Term Quality

Some relevant keywords appear ("v1", "taste-skill", "design-taste-frontend", "backward compatibility"), but common natural phrases a user would say when needing frontend design taste help are absent from the description itself. Not 4 because coverage lacks synonyms users actually say for the skill's function; not 2 because several version-specific keywords are present.

3 / 5

Distinctiveness Conflict Risk

It explicitly disambiguates from the v2 default ("The current default is `design-taste-frontend` (v2 experimental)...") and scopes use to exact backward compatibility, giving it a clear niche with minimal conflict risk. Clearly matches the top anchor rather than 4, since it actively steers away from the sibling skill.

5 / 5

Total

13

/

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
nexu-io/open-design
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.