CtrlK
BlogDocsLog inGet started
Tessl Logo

frontend-component-build

Build production-ready frontend components with accessible markup, sensible props, defined states, and tested behavior. Use this skill whenever the user wants to build a component from scratch, refactor an existing one, design a component API, or implement a UI element with proper states and accessibility. Triggers on build a component, create a button, create a modal, create a form input, component API, props design, component states, refactor component, accessible component. Also triggers when implementing UI from a design that needs to be reusable.

67

Quality

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

SKILL.md
Quality
Evals
Security

Quality

Content

70%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-organized, stack-agnostic component-building guide with a clear sequenced workflow and excellent progressive disclosure to three real reference files. It could be tightened (less restatement of basics) and made more directly executable with at least one worked component example.

Suggestions

Trim restatements of concepts Claude already knows (e.g. why booleans are red flags, the '5x harder' accessibility line) to recover context budget without losing guidance.

Add one small worked example (e.g. a Button rendered end-to-end: anatomy, props type, accessible markup, states, test) so the framework lands as concrete, executable output rather than principles.

Move the verbose component-specific ARIA bullets into the existing accessibility-patterns.md reference and keep only a pointer plus the highest-value rules inline, sharpening the overview.

DimensionReasoningScore

Conciseness

Largely efficient via tight bullets and lists, but some prose restates knowledge Claude already has ("Adding accessibility later is 5x harder", "Boolean props are red flags... seven combinations") and could be trimmed without losing guidance.

2 / 3

Actionability

Concrete in places (enum example `variant: "primary" | "secondary"`, named ARIA roles, a 10-step workflow), but it is principles-and-checklists rather than executable, copy-paste component code; the API and state guidance instructs rather than demonstrates.

2 / 3

Workflow Clarity

A clearly sequenced 10-step workflow with an explicit validation gate ("A component without at least automated accessibility testing is not done") and a closing Test step that acts as a checkpoint before documenting.

3 / 3

Progressive Disclosure

Well-structured overview with three one-level-deep references signaled by markdown links (component-spec-template, component-api-patterns, accessibility-patterns), each a real file with a clearly scoped purpose; nothing is deeply nested.

3 / 3

Total

10

/

12

Passed

Description

92%

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 strong, third-person description that clearly states what the skill does and gives explicit trigger guidance with natural user phrasings. Its only real weakness is mild overlap with the sibling design-system and design-standards skills it names.

DimensionReasoningScore

Specificity

Lists multiple concrete actions: "Build production-ready frontend components with accessible markup, sensible props, defined states, and tested behavior" and enumerate build-from-scratch, refactor, design an API, and implement from a design.

3 / 3

Completeness

Explicitly answers both what (build accessible, well-propped, stateful components) and when ("Use this skill whenever the user wants to build a component..." plus an explicit "Triggers on..." list).

3 / 3

Trigger Term Quality

Includes natural phrasings a user would actually say such as "create a button", "create a modal", "create a form input", "component API", "props design", and "refactor component".

3 / 3

Distinctiveness Conflict Risk

The component niche is fairly clear, but the skill itself names overlapping neighbors (design-system, design-standards), and terms like "refactor an existing component" could plausibly route to code-review-web, so some overlap remains.

2 / 3

Total

11

/

12

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

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
rampstackco/claude-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.