CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

design-taste-frontend-v2-experimental

Old v2 (experimental) of taste-skill, the single-file dial-driven version, preserved for projects depending on its exact behavior. The current default is `design-taste-frontend` (v2). Use this install name only if you need the earlier behavior. Anti-slop frontend rules for landing pages, portfolios, and redesigns, with real design systems when applicable, audit-first redesigns and a strict pre-flight check.

60

Quality

75%

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-v2-experimental/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%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 body is exceptionally actionable - concrete commands, complete code skeletons, exact hex values, and a mechanical pre-flight checklist - and the workflow is explicitly sequenced with a mandatory final validation gate. Its two weaknesses are severe duplication and padding (em-dash and eyebrow rules each stated 3-4 times, known-concept explanations) in a ~90KB single file, and the absence of any progressive disclosure: all reference material is inlined with no bundle files at all.

Suggestions

Move Appendix A (install commands), Appendix B (canonical source links), Appendix C (Liquid Glass approximation), and the Section 5 code skeletons into references/ files (e.g., references/install-commands.md, references/design-system-links.md, references/motion-skeletons.md), leaving SKILL.md as an overview with one-level-deep, clearly signaled pointers.

Deduplicate the em-dash ban (stated in Sections 4.10, 9.F, 9.G, and 14) and the eyebrow rules (Sections 4.7, 9.F, and 14) into one normative section each, with the Pre-Flight checklist referencing them by section number instead of restating them.

Trim explanations of concepts Claude already knows (RSC / 'use client' mechanics in Section 3.A, WCAG contrast-ratio basics in Section 4.5, prefers-reduced-motion basics in Section 6.B) to one-line rules, and merge the near-duplicate dial tables in Sections 1.A and 1.B.

DimensionReasoningScore

Conciseness

The body runs ~1230 lines (~90KB) with substantial duplication: the em-dash ban is stated four times (Section 4.10 "em-dash is completely banned", Section 9.F "NO em-dash (—) as a design element OR anywhere else", all of Section 9.G, and the Section 14 checklist "ZERO em-dashes (—) anywhere on the page"), eyebrow rules appear in 4.7, 9.F, and 14, and Sections 1.A/1.B are near-duplicate dial tables. It also explains concepts Claude already knows (RSC "use client" mechanics in Section 3.A, WCAG contrast basics, prefers-reduced-motion basics). This is noticeably verbose with several padded/duplicated sections (anchor 2), not anchor 1, because the bulk is genuinely novel curated design knowledge rather than generic explanation.

2 / 5

Actionability

Guidance is fully executable throughout: real install commands ("npm install @carbon/react @carbon/styles", "npx shadcn@latest add button card badge separator"), complete copy-paste GSAP/Motion components with the critical parameters spelled out ("start: 'top top'", "pin: true", "invalidateOnRefresh: true"), exact hex bans ("#f5f1ea", "#b08947", "#1a1714"), and mechanically checkable validation rules ("If count > ceil(sectionCount / 3), the output fails"). This matches anchor 5: copy-paste-ready code and commands covering the common cases.

5 / 5

Workflow Clarity

The process is explicitly sequenced (Section 0 brief inference → Section 1 dials → Section 2 design-system map → build rules → Section 14 pre-flight) and closes with a mandatory validation gate with a feedback loop: "THIS IS NOT OPTIONAL. Run every box. If any box fails, the output is not done... Fix it before delivering." The redesign protocol (Section 11) adds its own ordered sequence with an audit-first checkpoint. This matches anchor 5 (clear sequence, explicit validation, checklists, fix-and-retry loop).

5 / 5

Progressive Disclosure

There are no bundle files (no references/, scripts/, or assets/ exist) - everything, including Appendix A install commands, Appendix B's 40+ canonical doc links, Appendix C's Liquid Glass CSS, and three full code skeletons, is inlined in a single 1230-line file. Internal structure is strong (numbered, clearly headed sections, cross-referenced by number), which keeps this above anchor 2's "minimal structure", but content that clearly belongs in separate reference files is inline and the Section 12 Block Library points to a file tree (skills/taste-skill/blocks/) that does not exist - matching anchor 3.

3 / 5

Total

15

/

20

Passed

Description

70%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 communicates a clear niche (anti-slop frontend design for landing pages, portfolios, and redesigns) and explicitly disambiguates this deprecated variant from the current default, which is good versioning hygiene. Its weaknesses are the abstract, verb-free capability phrasing, versioning metadata occupying half the text, and the absence of a task-level trigger clause (the only "Use when" guidance is about picking this install name).

Suggestions

Rewrite capabilities as third-person action verbs (e.g., "Applies anti-slop design rules, audits existing brand tokens before redesigns, and validates output with a pre-flight checklist") instead of noun phrases like "rules" and "check".

Add an explicit task-level trigger clause, e.g., "Use when building or redesigning landing pages, portfolios, or marketing sites" - the current use-clause only covers version selection.

Compress the versioning preamble ("Old v2 (experimental)... preserved for projects depending on its exact behavior") into one short sentence so capability description dominates the field.

DimensionReasoningScore

Specificity

Capabilities are named ("Anti-slop frontend rules for landing pages, portfolios, and redesigns", "audit-first redesigns and a strict pre-flight check", "with real design systems when applicable") but as abstract noun phrases rather than concrete actions, and the first two sentences are versioning metadata that contributes nothing to capability description. This matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive) better than anchor 4, whose examples use explicit action verbs; it is clearly above anchor 2 because the domain is precisely named and multiple capabilities are listed.

3 / 5

Completeness

The "what" is clear (anti-slop frontend rules with design systems, audit-first redesigns, pre-flight check) and an explicit use-condition exists ("Use this install name only if you need the earlier behavior"), so the missing-trigger cap of 3 does not apply. However, the explicit "when" addresses variant selection, not when the design capability applies (no "use when the user asks for a landing page or redesign" clause), fitting anchor 4 (both present, when could be more explicit) rather than anchor 5.

4 / 5

Trigger Term Quality

Natural user-facing terms are present: "landing pages, portfolios, and redesigns", "frontend", "design systems". Missing common variations a user might say ("website", "marketing site", "homepage", "UI design"), which matches anchor 4 (good keyword coverage, a few natural terms missing) rather than anchor 5's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

The description actively disambiguates from its sibling ("The current default is `design-taste-frontend` (v2). Use this install name only if you need the earlier behavior.") and scopes a clear niche (landing pages, portfolios, redesigns). Minor overlap risk remains with other general frontend-design skills, matching anchor 4 rather than anchor 5's minimal-conflict example.

4 / 5

Total

15

/

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

skill_md_line_count

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

Warning

Total

15

/

16

Passed

Repository

Leonxlnx/taste-skill

Path

skills/taste-skill-v2-experimental/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.