CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

react-testing

React component testing with React Testing Library, Vitest/Jest, MSW for network mocking, accessibility assertions with axe, and the decision boundary between component tests and Playwright/Cypress end-to-end runs. Use when writing or fixing tests for React components, hooks, or pages.

Quality

88%

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

The canonical home for this skill is react-testing in affaan-m/ECC

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 high-quality, pattern-dense reference: nearly all guidance is executable code with sharp opinionated rules (query priority tiers, anti-patterns, RTL-vs-E2E decision boundary) and validation-minded defaults like onUnhandledRequest: 'error'. The main improvements are trimming the TDD section that duplicates a cross-referenced skill and offloading the Examples and coverage-config sections into reference files to shorten the always-loaded body.

Suggestions

Trim or collapse the TDD Workflow section to a pointer to the tdd-workflow skill and its RED/GREEN/REFACTOR recap — Claude already knows this process and it is cross-referenced anyway (lowest dimension: conciseness).

Move the three full example test files in the Examples section into a references/ file (e.g. references/examples.md) and keep one-line signposts in the body, reducing the always-loaded ~420-line body (progressive_disclosure).

Consolidate the workflow guidance into a single sequenced 'write a test' checklist with explicit verify checkpoints (pick runner -> set up MSW -> write failing test with accessible queries -> verify it fails for the right reason -> implement), rather than distributing it across sections (workflow_clarity).

DimensionReasoningScore

Conciseness

The body is dense with directives and executable code and mostly assumes competence ('Never setTimeout + assertion — flaky', 'Pick one. Do not run RTL + Vitest AND Playwright CT in the same repo'). However, the TDD Workflow section re-explains RED/GREEN/REFACTOR — a process Claude already knows and which is cross-referenced to a separate tdd-workflow skill — so there are minor instances of over-explanation that could be trimmed. This fits 'Efficient; minor instances of over-explanation that could be trimmed' rather than the fully lean anchor.

4 / 5

Actionability

Nearly every section gives copy-paste-ready, complete code: full MSW server setup with lifecycle hooks, userEvent test bodies, renderHook usage with wrapper, jest-axe assertions, a test-utils.tsx, a vitest.config.ts coverage block, and exact CLI commands ('vitest run --coverage', 'jest path/to/file.test.tsx'). Examples cover the common cases end-to-end, matching 'Fully executable; copy-paste ready code or commands; specific examples cover the common cases'.

5 / 5

Workflow Clarity

The TDD Workflow section gives a clear sequenced process with an explicit validation checkpoint — 'Verify it fails for the right reason' — plus a refactor step, and the MSW setup establishes a validate-early feedback loop via 'onUnhandledRequest: "error"' so unmocked requests fail loudly. This matches 'Clear sequence with most checkpoints present; minor validation gaps'; it is not a fragile multi-step operation skill, so the destructive-operation cap does not apply, but the workflow guidance is secondary to the pattern catalog, keeping it below the explicit-loop anchor.

4 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), so the skill is a single ~420-line file. Section headers are clear and consistent, cross-links are well-signaled one level deep ('Cross-link: [skills/accessibility/SKILL.md]', 'See [e2e-testing skill](../e2e-testing/SKILL.md)', plus a Related section), and the decision-boundary guidance points onward appropriately. The gap keeping it below 5: all content is inlined in one long SKILL.md — the Examples section (three full test files) and coverage-config block are natural candidates for a references file, fitting 'Good structure; most content is appropriately placed; references mostly clear; minor organization gaps'.

4 / 5

Total

17

/

20

Passed

Description

92%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: third-person, specific, and complete with an explicit 'Use when' trigger clause covering components, hooks, and pages. It names the concrete toolset and even pre-empts overlap with E2E testing skills by stating the decision boundary. The only gap is a handful of natural synonyms ('unit tests', 'test suite') that would push trigger coverage from good to exhaustive.

DimensionReasoningScore

Specificity

The description names multiple concrete capabilities — 'React component testing with React Testing Library', 'MSW for network mocking', 'accessibility assertions with axe', and 'the decision boundary between component tests and Playwright/Cypress end-to-end runs' — with comprehensive coverage of the domain. This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage'; nothing is generic filler, and a score of 4 would understate the breadth of specific tools and tasks enumerated.

5 / 5

Completeness

It explicitly answers both questions: what it does (first sentence enumerating capabilities) and when to use it via a literal 'Use when writing or fixing tests for React components, hooks, or pages.' clause. This matches the anchor 'Clearly and explicitly answers both what AND when with concrete trigger phrases'; a 4 would require the 'when' to be less explicit, which it is not.

5 / 5

Trigger Term Quality

Strong natural phrasing users would actually say: 'writing or fixing tests', 'React components, hooks, or pages', plus library names (Vitest, Jest, MSW, Playwright, Cypress). A few common natural terms are missing — e.g. 'unit tests', 'test suite', 'snapshot tests', or file patterns like '.test.tsx' — so it falls just short of the anchor 'comprehensive coverage of natural terms including synonyms and file extensions', but is clearly above 'good keyword coverage; a few natural terms missing' being the best fit at 4.

4 / 5

Distinctiveness Conflict Risk

It carves out a clear niche (component-level React testing) and even disambiguates the boundary against adjacent skills by naming 'the decision boundary between component tests and Playwright/Cypress end-to-end runs' and scoping triggers to 'React components, hooks, or pages'. Minimal conflict risk with generic testing skills; matches 'Clear niche with distinct triggers; minimal conflict risk'.

5 / 5

Total

19

/

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

frontmatter_unknown_keys

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

Warning

relative_links

Relative link issues: 7 suspicious

Warning

Total

14

/

16

Passed

Repository

affaan-m/ECC

Path

.kiro/skills/react-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.