CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

frontend-testing

Use when writing or changing Vitest or React Testing Library tests under `web/` or `packages/dify-ui/`, or when the user explicitly requests frontend test strategy, including evaluation of an existing strategy. Do not use for frontend code-review-only requests, general testability discussion, Python tests, or Cucumber/Playwright E2E.

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 exemplarily lean router skill: it delegates all policy to the owning package docs, adds no duplicate guidance ('This skill adds no parallel policy or check sequence'), and still encodes concrete behavioral policy (delete low-value tests, report the verified contract and gaps). The only soft spot is that validation commands exist only in the referenced docs.

DimensionReasoningScore

Conciseness

Roughly eight lean lines with zero padding: no library explainers, no concept recaps, no filler. Every sentence either routes ('Read the testing policy for the package that owns the changed tests') or sets behavior, assuming Claude's competence throughout.

5 / 5

Actionability

Concrete, executable guidance: exact file paths ('web/docs/test.md', 'packages/dify-ui/docs/testing.md'), an unambiguous ownership rule, and specific behavioral directives ('report the contract verified and any material verification gap'). Falls short of 5 only because the actual validation commands are deferred to the referenced docs rather than given inline — a minor gap for a router skill.

4 / 5

Workflow Clarity

The single routing step is unambiguous (package under test → its owner doc), and verification is explicitly mandated twice ('including its validation commands', 'report the contract verified and any material verification gap'). Not 5 because the validation checkpoints themselves are not sequenced here — they live in the external policy docs; not 3 because validation is required and the sequence has no gaps for this simple skill.

4 / 5

Progressive Disclosure

Under 50 lines with no bundle files needed; sections are well organized and the two references are clearly signaled, exactly one level deep, and each annotated with what it owns ('test boundaries, environments, and commands'). Meets the rubric's simple-skill exception for a top score.

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 well-crafted trigger-focused description with strong explicit 'when' conditions, good natural keywords, and unusually good exclusion boundaries that minimize conflict risk. Its main weakness is that the 'what' — the skill's actual routing behavior — is implied rather than stated.

Suggestions

State the skill's actual behavior explicitly, e.g. prepend 'Routes frontend test work to the owning package's testing policy' so the 'what' is as explicit as the 'when'.

Add common user phrasings as triggers, such as 'unit tests', 'component tests', or 'test coverage' for the two supported packages.

DimensionReasoningScore

Specificity

Names several concrete actions — 'writing or changing Vitest or React Testing Library tests', 'frontend test strategy', 'evaluation of an existing strategy' — with only minor coverage gaps (e.g. running or debugging tests is not mentioned). Not 5 because the action list is not comprehensive; not 3 because it goes beyond 1-2 actions.

4 / 5

Completeness

The 'when' is explicit and multi-conditioned ('Use when writing or changing... or when the user explicitly requests frontend test strategy'), but the 'what' — that the skill routes to package-level testing policy — is only implied by naming the domain rather than clearly stated. Not 5 because the 'what' is not explicit; not 3 because the 'when' is strong and the 'what' is identifiable.

4 / 5

Trigger Term Quality

Good keyword coverage including 'Vitest', 'React Testing Library', 'frontend test strategy', 'Python tests', 'Cucumber/Playwright E2E', and path-based triggers ('web/', 'packages/dify-ui/'), plus exclusion triggers. A few natural variations users might say ('unit tests', 'component tests', 'RTL') are missing, so it does not reach the comprehensive-synonym level of 5.

4 / 5

Distinctiveness Conflict Risk

Clear niche (Vitest/RTL tests under two named directories) with explicit negative triggers ('Do not use for frontend code-review-only requests, general testability discussion, Python tests, or Cucumber/Playwright E2E') that disambiguate it from adjacent skills. Minimal conflict risk — matches the 5 anchor.

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/frontend-testing/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.