CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

frontend-design-direction

Set an ECC-specific frontend design direction for production UI work. Use when building or improving websites, dashboards, applications, components, landing pages, visual tools, or any web UI that needs stronger product-specific design judgment.

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/frontend-design-direction/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

73%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 well-sequenced, highly actionable instruction skill with explicit validation and a genuinely executable bundled checker whose behavior matches the documentation. The main costs are token weight in the inline evidence-record specification and the missing worked example that would let an agent produce a valid record on the first try.

Suggestions

Move the detailed evidence-record field specification into a bundled reference file (e.g., references/evidence-record.md) next to the checker, keeping only the command and a compact field summary in SKILL.md.

Add one worked example of a passing local-report.json (with two viewports and a not-applicable state) so the record can be written correctly without reverse-engineering the checker.

Trim the viewport-label matching rules ("375 px matches 375px...") that restate checker internals; the checker's rejection messages already teach these on failure.

DimensionReasoningScore

Conciseness

The body is dense, imperative, and free of padding about concepts Claude already knows, but it can be tightened: the inline evidence-record field spec (contract, targetViewports, viewport-matching rules, contentStates, renderedEvidence) spans ~25 lines and duplicates semantics the bundled checker already enforces. That fits anchor 3 ("could be tightened") better than anchor 4's minor-trim bar.

3 / 5

Actionability

Concrete, executable guidance throughout: an exact checker invocation ("node <installed-skill>/scripts/check-evidence.js <local-report.json>"), exact record property names, a state/feedback table, and specific anti-patterns ("purple gradients", "cards inside cards"). The gap versus anchor 5 is the absence of a copy-paste example JSON record covering the common case, which would make the evidence workflow fully turnkey.

4 / 5

Workflow Clarity

A coherent multi-step pipeline (choose direction → record contract → build → review checklist → rendered finish gate) with an explicit validation step (the evidence checker), a feedback loop ("Fix failures, then repeat affected checks after structural changes"), and a checklist for a complex process. This matches the anchor-5 pattern of clear sequencing with explicit validation and error-recovery loops.

5 / 5

Progressive Disclosure

Well-sectioned with a real, verified one-level-deep bundle reference (scripts/check-evidence.js) invoked with an exact path, plus one external reference URL. The main gap versus anchor 5 is that the detailed JSON record schema is inlined in SKILL.md where a short reference file next to the checker would keep the overview leaner.

4 / 5

Total

16

/

20

Passed

Description

75%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 clearly answers both what and when with a strong natural trigger list, following the ideal what/when structure. Its weaknesses are limited action specificity (one action rather than several) and meaningful overlap risk with the general frontend-design skill space given the broad trigger set.

Suggestions

Add one or two more concrete actions to the what-clause (e.g., "records a checkable design contract and validates rendered UI states with a bundled evidence checker") so the capability list is not a single action.

Narrow the trigger overlap with the generic frontend-design skill by leading with differentiators like "needs a product-specific design direction or rendered-UI quality gate" rather than the broad "building or improving websites".

Include the trigger synonym "polish"/"style" (or "make it less generic") to catch phrasings users naturally use for this skill.

DimensionReasoningScore

Specificity

"Set an ECC-specific frontend design direction for production UI work" names the domain and one concrete action, but offers no list of several specific actions. It sits at the anchor-3 level (domain + 1-2 concrete actions), below anchor 4 which expects several listed actions.

3 / 5

Completeness

It explicitly answers what ("Set an ECC-specific frontend design direction for production UI work") and when ("Use when building or improving websites, dashboards, applications, components, landing pages...") with concrete trigger phrases, matching the anchor-5 pattern. The when-clause is as explicit and enumerated as the anchor example, so anchor 4's "when could be more explicit" does not apply.

5 / 5

Trigger Term Quality

"building or improving websites, dashboards, applications, components, landing pages, visual tools, or any web UI" plus "frontend" and "design" gives good natural keyword coverage users would actually say. Common variations like "polish", "style", "redesign", or "look and feel" are missing, so it is not the comprehensive anchor-5 case.

4 / 5

Distinctiveness Conflict Risk

Triggers such as "building or improving websites, dashboards, applications, components" sit squarely in the canonical frontend-design skill's territory (which the body itself acknowledges), creating real overlap risk with closely related skills. The "ECC-specific" qualifier and "design direction" framing narrow it somewhat, but not enough for anchor 4.

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

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

affaan-m/ECC

Path

skills/frontend-design-direction/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.