CtrlK
BlogDocsLog inGet started
Tessl Logo

wpds

Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc.

58

Quality

66%

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

Quality

Content

57%

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 concrete MCP resource pointers and a clear niche, but it stops short of executable code or an explicit validation feedback loop, and carries minor verbosity (synonym list, 'etc etc'). Adding a concrete code/lint example and tightening redundancy would lift the lower dimensions.

Suggestions

Include at least one concrete, executable snippet — e.g. a sample `wpds://components/Button` lookup result or a lint command invocation — rather than only instructing Claude to 'provide working code snippets'.

Make the validation step an explicit checkpoint with a feedback loop (run lint → fix errors → re-run until clean), instead of the conditional 'use them to validate ... when possible'.

Trim redundant tokens: collapse the WordPress/WP and Design System/DS synonym list into a single inline note and drop the "etc etc" filler in the When-to-use list.

DimensionReasoningScore

Conciseness

The body avoids explaining basic concepts (React/TypeScript/CSS, what a design system is) and stays sectioned, but the synonym list and the chatty "etc etc" in the When-to-use list add tokens that could be trimmed, and the When-to-use list overlaps the description.

2 / 3

Actionability

It gives concrete, actionable MCP resource pointers (wpds://pages, wpds://components/:name, wpds://design-tokens) and names real packages (@wordpress/components), but provides no executable code or concrete lint commands — the Output section demands 'working code snippets' without showing any.

2 / 3

Workflow Clarity

A sequence is implied (prerequisites → use MCP for docs → read required docs → boundaries → validation → output), but the validation step is weak ("when possible") with no explicit validate-fix-retry checkpoint, so checkpoints remain implicit.

2 / 3

Progressive Disclosure

With no bundle files present, the single well-organized SKILL.md (clear sections: Prerequisites, When to use, Rules, Output) and one-level MCP URI references satisfy the simple-skill guidance that well-organized sections alone can score 3.

3 / 3

Total

9

/

12

Passed

Description

75%

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 an explicit "Use when" trigger and a clear, distinct WPDS niche, but its capability list reads as asset categories rather than concrete actions and lacks several natural trigger terms users would say. Tightening specificity and adding common synonyms would raise it.

Suggestions

Replace the category list ("components, tokens, patterns, etc.") with concrete actions, e.g. 'Use when building or reviewing UIs with WPDS — picking components, applying design tokens, and following WPDS patterns.'

Add natural trigger terms users actually say, such as Gutenberg, WooCommerce, WordPress.com, Jetpack, @wordpress/components, or @wordpress/ui, which currently appear only in the body.

Drop the vague trailing "etc." so the capability set reads as deliberate rather than open-ended.

DimensionReasoningScore

Specificity

The description names the domain and references concrete WPDS asset categories ("components, tokens, patterns, etc.") tied to the action "building UIs", but these are noun categories rather than multiple distinct concrete actions, and the trailing "etc." is vague.

2 / 3

Completeness

It explicitly answers what ("building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns") and provides an explicit "Use when ..." trigger clause, satisfying both what and when.

3 / 3

Trigger Term Quality

It includes some natural terms users would say ("building UIs", "WordPress Design System (WPDS)", "components", "tokens"), but omits common variations a user would actually mention (e.g., Gutenberg, WooCommerce, @wordpress/components) that appear only in the body.

2 / 3

Distinctiveness Conflict Risk

Binding the trigger to the specific WordPress Design System (WPDS) carves out a clear niche that is unlikely to fire for non-WordPress UI skills, despite the somewhat generic "building UIs" phrasing.

3 / 3

Total

10

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
WordPress/agent-skills
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.