CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

design-system

Govern and validate design-system changes. Use when tokens, typography, spacing, iconography, themes, or style aliases need repository-grounded evidence.

Quality

71%

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

Quality

Content

60%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.

A well-structured, clearly sectioned governance skill with a real fail-fast validation loop and a genuine (verified) reference bundle. Its weaknesses are abstractness — no named commands, canonical paths, or code anywhere in the body — plus meta-filler sections and safety boilerplate that dilute the token budget, and several cited paths that don't resolve within the bundle.

Suggestions

Make the Workflow and Validation sections executable: name the actual repo design-system validation commands and the canonical token/alias file paths (e.g. the concrete token layer files to load), or point to where in references/ those commands live, instead of "Run the repo-specific design-system checks or nearest available validation".

Delete or relocate the meta content: the Philosophy section (skill-design commentary), generic safety boilerplate in Constraints, and the Inputs/Outputs lists that duplicate references/contract.yaml — keeping one canonical copy in the reference file.

Fix the dangling references: either move the Infrastructure/references lens-pack, expertise-map, and deferred-skill-context materials into this skill's references/ directory or drop the citations, so every path cited in Progressive Disclosure resolves from the skill bundle.

DimensionReasoningScore

Conciseness

The body is bullet-based and free of concept over-explanation, but contains unnecessary padding: the "Philosophy" section ("Keep the skill focused on the decision and workflow the user actually requested") is meta-commentary about skill design rather than design-system guidance, "Constraints" restates generic safety boilerplate (untrusted input, redaction, destructive commands) not specific to this skill, and Inputs/Outputs duplicate the same lists already machine-encoded in references/contract.yaml. Above anchor 2 (no heavy padding or tutorial prose), below anchor 4 (several sections could be trimmed or removed outright).

3 / 5

Actionability

There is some concrete conceptual guidance — the layer taxonomy "brand, alias, mapped, component, or documentation layers", the gotcha that screenshots don't prove compatibility, and worked example prompts — but nothing executable: no validation commands, no canonical file paths, no code. "Run the repo-specific design-system checks or nearest available validation" never names the checks, and "Run the smallest command or test that exercises the changed behavior" gives no command. This matches anchor 3 (some concrete guidance but incomplete, missing key executable details) rather than anchor 2, since the layer taxonomy and examples do direct real decisions.

3 / 5

Workflow Clarity

The Workflow section gives an ordered approach (scope small, load smallest canonical surface, classify the layer, prefer existing tokens, explain impact, run checks), and the Validation section supplies an explicit fail-fast feedback loop ("stop at first failed gate; do not proceed until it is fixed and rerun") reinforced by a Failure Mode blocker rule. This is not a missing-validation case, so the cap at 3 does not apply. Below anchor 5 because checkpoints are decoupled from the workflow steps (a separate section, not inline), the steps mix policies with sequence, and no concrete command is attached to any checkpoint.

4 / 5

Progressive Disclosure

Scored against the actual bundle: the three local references cited (references/contract.yaml, references/evals.yaml, references/task-profile.json) all exist, are one level deep, and each is signaled with its purpose in a dedicated Progressive Disclosure section — matching anchor 4's "references mostly clear". Held below anchor 5 because three of the six cited paths (Infrastructure/references/software-literature-expert-lens-pack.md, Infrastructure/references/software-literature-skill-expertise-map.md, and Infrastructure/references/deferred-skill-context/frontend-ui-design-system/) do not exist in the bundle and are unresolvable from this skill, and Inputs/Outputs duplicate content already in contract.yaml.

4 / 5

Total

14

/

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.

A solid description with an explicit, trigger-rich "Use when" clause and a distinct design-system niche. Its main weakness is the vague "what": "Govern and validate" states no concrete capabilities, and a few natural trigger synonyms (design tokens, theme variables, colors) are missing.

Suggestions

Replace the abstract "Govern and validate design-system changes" with 2-3 concrete capabilities, e.g. "Audit token/alias/component layers, trace changes to canonical sources, and validate generated style outputs against repo contracts".

Add missing natural trigger variations such as "design tokens", "theme/CSS variables", and "colors" to the when-clause so users phrasing requests those ways still match.

Clarify what "repository-grounded evidence" concretely means in the description (e.g. cite canonical token files and validation commands) so the skill's output is predictable from the description alone.

DimensionReasoningScore

Specificity

"Govern and validate design-system changes" names the domain and two actions, plus the mechanism "repository-grounded evidence", but the actions are abstract — "govern" is a buzzword-adjacent verb with no concrete capability stated (unlike "extract text", "fill forms"). It sits above anchor 2 (actions minimal/generic) because two actions and an evidence mechanism are stated, but below anchor 4/5 because no concrete operations are enumerated.

3 / 5

Completeness

Both parts are present: what ("Govern and validate design-system changes") and an explicit when ("Use when tokens, typography, spacing, iconography, themes, or style aliases need repository-grounded evidence") with concrete trigger phrases. Below anchor 5 because the "what" is high-level — it never states concretely what governing or validating involves; above anchor 4 because the when-clause is fully explicit rather than merely improvable.

4 / 5

Trigger Term Quality

"tokens, typography, spacing, iconography, themes, or style aliases" are natural terms a user raising a design-system request would say, giving good keyword coverage. Below anchor 5 because common variations are missing — e.g. "design tokens", "CSS/theme variables", "colors", "UI styles" — leaving a few natural phrasings uncovered.

4 / 5

Distinctiveness Conflict Risk

A clear niche (repository-grounded design-system governance) with distinct trigger vocabulary; unlikely to fire for backend or doc-processing skills. Minor overlap risk remains with general frontend/styling or branding skills via broad terms like "themes", "spacing", and "style aliases", so it falls just short of anchor 5.

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

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

jscraik/Agent-Skills

Path

Skills/frontend-ui/design-system/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.