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

36%

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 ./.agents/skills/design-taste-frontend-v1/SKILL.md

Quality

Content

57%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 a highly actionable, opinionated set of frontend design directives with concrete class recipes and motion configs, scoring well on actionability. It is held back by cross-section redundancy, a descriptive-only inspiration catalog, a single end-of-document validation checkpoint, and a monolithic structure with no progressive disclosure to separate reference files.

Suggestions

Merge the duplicated bans: consolidate Rule 1/Rule 2 typography and color bans with Section 7's AI Tells, and merge Section 4's motion guidance with Section 9B to remove repeated spring-physics/layoutId/perpetual-interaction directives.

Move the Section 8 Creative Arsenal catalog and Section 6 dial definitions into a separate reference file (e.g. references/arsenal.md) and link to it from SKILL.md so the main file stays an overview.

Add a short explicit generation workflow with mid-process checkpoints (e.g. verify package.json -> generate -> mobile-collapse check -> pre-flight) rather than relying on a single final checklist.

Dimension	Reasoning	Score
Conciseness	The body is overwhelmingly actionable rules rather than basic-concept explanation, but it duplicates directives across sections (Lila/AI-purple ban in Rule 2 and AI Tells; Inter and serif bans in Rule 1 and AI Tells; spring physics, layout/layoutId, and perpetual micro-interactions in Section 4 and Section 9B) and Section 8 catalogs ~40 widely-known UI patterns by name — clear tightening opportunities.	3 / 5
Actionability	Dense with copy-paste-ready specifics — exact Tailwind classes ("min-h-[100dvh]", "rounded-[2.5rem]", "shadow-[0_20px_40px_-15px_rgba(0,0,0,0.05)]"), Framer Motion configs ("type: spring, stiffness: 100, damping: 20"), and install commands; the main gap is Section 8's arsenal, which names effects ("Gooey Menu", "Parallax Tilt Card") without implementation.	4 / 5
Workflow Clarity	Topics are logically ordered (baseline config -> architecture -> directives -> pre-flight checklist) and Section 10 provides a final validation checklist, but there is no sequenced generation workflow with checkpoints throughout — the only checkpoint sits at the very end.	3 / 5
Progressive Disclosure	Internal section structure is clear and well-headed (better than a structureless wall), but the skill is a monolithic single file with no bundle files and large reference-like blocks (Section 6 dial definitions, Section 8 arsenal catalog, Section 9 bento spec) inlined that could be split into separate referenced files.	3 / 5
	Total	13 / 20 Passed

Description

16%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 functions as a versioning/install footnote rather than a capability statement: it explains when to choose this install name over v2 but never says what the skill does or what natural user request it serves. Specificity and trigger-term quality are very low because no design actions or user-facing keywords appear.

Suggestions

Lead with the functional capability, e.g. "Generates high-end, non-generic frontend UI (React/Next.js + Tailwind) with engineered design rules, motion, and anti-slop guardrails."

Add a natural-trigger "Use when..." clause naming user phrases like "frontend", "UI design", "dashboard", "landing page", or "React component styling".

Keep the v1/v2 backward-compatibility note, but move it after the capability and trigger statement so the description answers 'what' and 'when' first.

Dimension	Reasoning	Score
Specificity	The description states no concrete capability actions — it only describes version/install provenance ("preserved for projects depending on its exact behavior", "substantial rewrite", "Use this v1 install name only if you need exact backward compatibility") with zero mention of what the skill functionally does (frontend/UI generation).	1 / 5
Completeness	A "when" clause exists ("Use this v1 install name only if you need exact backward compatibility") but the functional "what" is missing — the description explains the install name's role, not what the skill does, matching the "only 'when' present without 'what'" anchor.	2 / 5
Trigger Term Quality	The only terms present ("v1", "backward compatibility", "install name", "exact behavior") are packaging jargon a user would never say when needing a design skill; natural triggers like "frontend", "UI", "dashboard", "React" are entirely absent.	1 / 5
Distinctiveness Conflict Risk	It explicitly disambiguates from v2 ("current default is design-taste-frontend (v2 experimental)"), reducing conflict between the two versions, but conveys no functional niche, so overlap risk with other design skills remains.	3 / 5
	Total	7 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: mediago-dev/mediago
Path: .agents/skills/design-taste-frontend-v1/SKILL.md
Commit: f2aa40a

Reviewed: 3 days 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.