CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

how-to-write-component

Use when implementing or refactoring React/TypeScript components and the task requires decisions about component ownership, feature boundaries, state, data flow, effects, or interaction ownership. Do not use for review-only requests, test-only work, copy-only edits, or styling-only changes.

Quality

85%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

An exemplary progressive-disclosure structure: the body is a lean routing index over five real, topic-split reference files with explicit verification doc pointers and concrete Tailwind mappings. The only notable gap is that the verification step names the owning docs but leaves the actual checks to them, keeping actionability and workflow clarity at 4.

DimensionReasoningScore

Conciseness

The body is a lean routing index: every line either maps a change type to a reference file, gives a concrete Tailwind class mapping, or names a verification doc. It assumes Claude's competence (no explanation of React, Tailwind, or basic concepts), matching anchor 5's 'every token earns its place'.

5 / 5

Actionability

Guidance is concrete and executable in most places — exact reference paths ('references/ownership.md'), verification doc paths ('web/docs/test.md', 'web/docs/lint.md', 'packages/dify-ui/docs/testing.md'), and copy-ready class mappings ('w-105 instead of w-[420px]', 'px-2.25 instead of px-[9px]'). It falls short of anchor 5 because 'Verify the changed behavior and complete the owning package's required checks' delegates the actual checks without stating them.

4 / 5

Workflow Clarity

The sequence is legible — route the topic to references, identify the behavior owner/state lifetime/public contract, keep the change within the vertical slice, then verify via named docs — with verification checkpoints present. It sits at anchor 4 rather than 5 because the sequence is implicit rather than enumerated and there is no validate-fix-retry feedback loop for the verification step.

4 / 5

Progressive Disclosure

Verified against the actual bundle: all five referenced files (ownership.md, state.md, data.md, interactions.md, runtime.md) exist in references/, and the body is a clear overview with well-signaled, one-level-deep reference links plus link-reference definitions. Content is appropriately split by topic; the second hop to overlay/form contracts points to external package-owned docs that is pre-announced in the body ('the overlay guide it references'), which is appropriate placement rather than deferred-content chaining.

5 / 5

Total

18

/

20

Passed

Description

78%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 strong description with an explicit trigger clause, well-chosen domain keywords, and unusually good negative boundaries that reduce conflict risk. Its main weakness is that the 'what' is implied rather than stated — it describes when the skill applies but never says what it does.

Suggestions

State the 'what' explicitly, e.g. 'Routes component architecture decisions to bundled reference guides. Use when...' so both halves of anchor-5 completeness are met.

Add commonly-said trigger terms such as 'props', 'hooks', or 'component boundaries' to broaden natural keyword coverage toward anchor 5.

DimensionReasoningScore

Specificity

The description names the domain ('implementing or refactoring React/TypeScript components') and enumerates concrete decision areas ('component ownership, feature boundaries, state, data flow, effects, or interaction ownership'). It lists several specific capabilities with only minor gaps (e.g., props and hooks are not mentioned), matching anchor 4 rather than anchor 3's '1-2 concrete actions' and falling short of anchor 5's fully comprehensive action list.

4 / 5

Completeness

The 'when' is explicit and strong ('Use when implementing or refactoring React/TypeScript components...' plus explicit anti-triggers 'Do not use for review-only requests, test-only work, copy-only edits, or styling-only changes'), exceeding anchor 4's 'when could be more explicit'. However, the 'what' — what the skill actually does (e.g., routes architecture decisions to bundled reference guides) — is only implied by the topic list and never stated as an action, so anchor 5 is not met.

4 / 5

Trigger Term Quality

Natural terms a user would say are present — 'React', 'TypeScript', 'component', 'refactoring', 'state', 'data flow', 'effects' — giving good keyword coverage. It falls short of anchor 5 because common variations like 'props', 'hooks', or 'render' are missing.

4 / 5

Distinctiveness Conflict Risk

The skill occupies a clear niche (React/TypeScript component architecture decisions) with distinct triggers, and the explicit exclusions for review-only, test-only, copy-only, and styling-only work fence off adjacent skills. This matches anchor 5's 'clear niche with distinct triggers; minimal conflict risk'.

5 / 5

Total

17

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

langgenius/dify

Path

.agents/skills/how-to-write-component/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.