CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

dev-create-test

Use when a module needs test coverage - creates tests for adapters, hooks/composables/stores, and components.

Quality

81%

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

82%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 tight, highly actionable skill body: three complete test templates, a clear decision structure by module type, and an exact run command, with essentially no wasted tokens. The only notable gaps are a missing `vi` import in the component template and the absence of an explicit fix-and-re-run loop after running vitest.

Suggestions

Fix the component example's imports: it uses `vi.fn()` but the import line is `import { describe, it, expect } from 'vitest'` — add `vi` to make the template copy-paste ready.

Add a brief step 5 for the failure path, e.g., 'If tests fail, fix the test or mock and re-run' — this closes the feedback loop and would lift workflow clarity to a 5.

DimensionReasoningScore

Conciseness

The body is lean with zero explanation of concepts Claude already knows — it opens directly with "Create tests for the specified file or module" and every subsequent token is a template, a file-path convention, or a command. This matches the anchor-5 'lean and efficient; every token earns its place' example.

5 / 5

Actionability

Provides complete code templates for all three test types, an exact output path convention (`__tests__/OriginalName.spec.ts(x)`), and a specific run command (`npx vitest run --reporter=verbose`). It misses anchor 5's copy-paste-ready bar because the component example uses `vi.fn()` without importing `vi` from vitest, and the templates rely on xxx placeholders without guidance on adapting them.

4 / 5

Workflow Clarity

The four steps (analyze → determine test type → create file → run vitest) form a clear sequence, and step 4's test run serves as a checkpoint — matching anchor 4's 'clear sequence with most checkpoints present'. There is no explicit feedback loop for handling failures (fix and re-run), which anchor 5 requires; the destructive/batch cap does not apply since test creation is non-destructive.

4 / 5

Progressive Disclosure

The body is well-organized with a `## Steps` structure and clearly labeled per-type subsections, and no external references are needed. At ~85 lines it exceeds the under-50-line simple-skill exception, and the three full code templates are inlined, so it sits at anchor 4 ('good structure; most content appropriately placed') rather than 5.

4 / 5

Total

17

/

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 concise, well-formed description that explicitly covers both what the skill does and when to use it, with concrete target-module keywords. Its main limitations are a single trigger condition and missing common synonyms like 'unit tests' or 'specs'.

DimensionReasoningScore

Specificity

The description names a single concrete action ("creates tests") but enumerates specific, distinguishing target types ("adapters, hooks/composables/stores, and components"), which goes beyond anchor 3's '1-2 concrete actions' coverage. It falls short of anchor 5's comprehensiveness since it doesn't mention test kinds, mocking, or running the tests.

4 / 5

Completeness

Both parts are explicitly present: what ("creates tests for adapters, hooks/composables/stores, and components") and when ("Use when a module needs test coverage"). The 'when' is a single generic condition rather than the multiple concrete trigger phrases anchor 5 requires.

4 / 5

Trigger Term Quality

Includes natural terms users would say — "test coverage", "tests" — plus the module-type keywords "hooks", "composables", "stores", "components". A few natural terms are missing (e.g., "unit tests", "specs", "vitest"), keeping it below anchor 5.

4 / 5

Distinctiveness Conflict Risk

The enumerated frontend module types give it a distinct niche versus generic testing skills, satisfying anchor 4's 'mostly distinct; minor overlap risk'. The broad trigger "a module needs test coverage" could still overlap with general test-writing skills, so it doesn't reach anchor 5's minimal conflict risk.

4 / 5

Total

16

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

frontmatter_unknown_keys

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

Warning

Total

14

/

16

Passed

Repository

fernandezbaptiste/specialist-agent

Path

packs/react/skills/dev-create-test/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.