CtrlK
BlogDocsLog inGet started
Tessl Logo

color-oklch

Use when building a design token system, creating accessible colour palettes, generating colour ramps programmatically, or migrating a design system to support wide-gamut displays.

60

Quality

70%

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/color-oklch/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

65%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 clean, well-structured overview that uses progressive disclosure effectively to push implementation detail into references/rule.md. Its weaknesses are the in-body side: no executable examples and no validation checkpoints, with the actionable depth living entirely in the reference file.

Suggestions

Inline one small executable snippet (e.g. a 3-line oklch token definition) so the body is actionable on its own without requiring the reference.

Add an explicit verification checkpoint to the Fix section (e.g. 'Verify perceived lightness is equal across shade steps 300/500/700') rather than leaving validation only in rule.md.

Trim the intro paragraph's explanation of perceptual uniformity, which repeats content already in references/rule.md and restates a concept Claude already knows.

DimensionReasoningScore

Conciseness

The ~30-line body is mostly lean with useful Check/Fix/Explain/Code Review sections, but the intro paragraph re-explains perceptual uniformity — a concept Claude already knows — and duplicates rule.md's 'Why It Matters', so a little could be trimmed.

4 / 5

Actionability

Gives actionable directives ('Convert the colour token palette from hsl/hex to oklch', 'Use @media (color-gamut: p3)') but no executable code or concrete token examples in the body itself — all working examples live in references/rule.md.

3 / 5

Workflow Clarity

Check → Fix → Explain → Code Review forms a loose checklist rather than a sequenced process, and the validation/verification steps (which exist in rule.md) are absent from the body, leaving checkpoints implicit.

3 / 5

Progressive Disclosure

A concise overview body with a single, clearly-signaled one-level-deep reference ('see references/rule.md') that is verified to exist, splitting detailed implementation out appropriately.

5 / 5

Total

15

/

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.

A well-formed trigger-style description that names a clear niche and four concrete use cases with explicit 'when' guidance. It falls short of top marks because the actions are somewhat high-level and it omits the most natural technical synonyms (oklch/oklab).

Suggestions

Lead with a concise capability statement before the 'Use when' clause (e.g. 'Converts design-system colour tokens to perceptually uniform oklch().') so the 'what' is distinct from the 'when'.

Add the natural technical trigger terms users actually say — 'oklch', 'oklab', 'color palette' — alongside the existing phrases.

Tighten one action to a finer-grained verb (e.g. 'converting hsl/hex tokens to oklch') to lift specificity toward comprehensive coverage.

DimensionReasoningScore

Specificity

Lists four concrete actions ('building a design token system', 'creating accessible colour palettes', 'generating colour ramps programmatically', 'migrating a design system to support wide-gamut displays'), but each is project-level rather than a fine-grained operation, leaving minor coverage gaps.

4 / 5

Completeness

Has an explicit 'Use when...' trigger clause (so not capped at 3) and the verbs convey the 'what', but there is no distinct capability statement separate from the when-clause, keeping it just below a 5.

4 / 5

Trigger Term Quality

Includes natural domain phrases users would say ('design token system', 'accessible colour palettes', 'colour ramps', 'wide-gamut displays'), but omits common synonyms a user might actually invoke such as 'oklch', 'oklab', or the American spelling 'color'.

4 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (perceptually uniform oklch colour for design systems) with distinct triggers, with only minor overlap risk against generic design-system or accessibility skills.

4 / 5

Total

16

/

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.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.