CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

frontend-design

Analyze ambiguous frontend design requests and route the right UI owner. Use this skill when broad design intent needs classification before implementation.

Quality

59%

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/agent-ops/frontend-design/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

42%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 well-structured with clear sectioning and a sensible workflow spine, but it is an instruction-only skill whose instructions rarely reach concreteness: the classification scheme it routes on is never defined, validation gates name tools without commands, and the Avoid and Anti-Patterns sections duplicate each other verbatim. Its only reference points outside the bundle while the actual reference files go unmentioned.

Suggestions

Define the classification criteria: give one-line hallmarks of existing-system, partial-system, and greenfield (e.g. what evidence in routes/components/conventions maps to each class).

Merge the duplicated Avoid and Anti-Patterns sections into one, and make validation steps concrete by naming the actual commands for 'Plugin Eval' and the 'strict skill audit'.

Fix progressive disclosure: replace the external archive pointer with references to the actual bundle files (references/contract.yaml, references/evals.yaml, references/task-profile.json) so the body signals where each kind of detail lives.

DimensionReasoningScore

Conciseness

The body is mostly lean and imperative, but the Avoid section is duplicated verbatim as Anti-Patterns (three identical bullets: 'Do not own token-governance work...', 'Do not own motion-only polish...', 'Do not ask a broad design interview...') and gate-stopping language repeats across Constraints and Validation, fitting the 3 anchor ('mostly efficient but includes some unnecessary explanation or could be tightened') rather than the 4 anchor, which requires only minor trims.

3 / 5

Actionability

As an instruction-only skill the absence of code is acceptable per the scoring notes, but the guidance stays at high-level hints: 'Classify system maturity and implementation readiness' gives no criteria for the existing-system/partial-system/greenfield scheme, 'Resolve overlap against local frontend owner skills' offers no method, and 'Run Plugin Eval and strict skill audit' names no command — matching the 2 anchor ('minimal concrete guidance; high-level hints but missing the specific steps to execute') rather than 3, since even the central classification the skill routes on is undefined.

2 / 5

Workflow Clarity

A clear six-step sequence is present with an ask-only-when-material rule and a Validation section demanding exact commands and pass/fail reporting, but the checkpoints are named abstractly ('Run Plugin Eval and strict skill audit') with no concrete commands or error-recovery loop, matching the 3 anchor ('sequence present but checkpoints missing or implicit') rather than 4.

3 / 5

Progressive Disclosure

Sections are well-organized and the body is compact, but scored against the actual bundle: references/ contains contract.yaml, evals.yaml, and task-profile.json, none of which the body signals or links, and its single reference points outside the bundle ('Archived full context: Infrastructure/references/deferred-skill-context/agent-ops-frontend-design/'), matching the 3 anchor ('references present but not clearly signaled') rather than 4.

3 / 5

Total

11

/

20

Passed

Description

58%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 has the right two-part structure (what plus an explicit when) and stays concise in third-person imperative voice, but it operates at a high level of abstraction throughout. Concrete capabilities, natural trigger variations, and distinguishing phrases are all thin, leaving it middling on specificity, triggers, and distinctiveness.

Suggestions

Enumerate the concrete actions in the what clause, e.g. 'Classify requests as existing-system, partial-system, or greenfield, pick the narrowest owning UI skill, and produce a visual/interaction thesis with handoff notes.'

Add natural trigger phrases users would actually say, such as 'redesign', 'mockups', 'UI overhaul', or 'make it look better', to the when clause.

Sharpen distinctiveness by contrasting with implementation skills, e.g. 'Use for routing and planning only, not for implementing screens or design-system token work.'

DimensionReasoningScore

Specificity

The description names the domain ("frontend design") and two actions ("Analyze ambiguous frontend design requests", "route the right UI owner"), but the actions are abstract with no concrete deliverables, matching the 3 anchor ('names domain and 1-2 concrete actions, but not comprehensive') rather than the 4 anchor's list of several specific actions.

3 / 5

Completeness

Both what ("Analyze ambiguous frontend design requests and route the right UI owner") and when ("Use this skill when broad design intent needs classification before implementation") are explicitly present, but the when clause is abstract rather than concrete trigger phrases, so it fits 4 ('when' could be more explicit or specific) rather than 5.

4 / 5

Trigger Term Quality

"frontend design" is the one strong natural term, but common user phrasings like "redesign", "UI", "mockups", or "make it look better" are absent, fitting the 3 anchor ('some relevant keywords but missing common variations or synonyms') rather than the 4 anchor's good coverage.

3 / 5

Distinctiveness Conflict Risk

The routing framing ("route the right UI owner... before implementation") carves out a niche, but the broad trigger "frontend design" overlaps heavily with the implementation skills it routes to and no distinct trigger phrases separate them, matching the 3 anchor ('somewhat specific but could still overlap with similar skills').

3 / 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

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

jscraik/Agent-Skills

Path

Skills/agent-ops/frontend-design/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.