Taimoorkhan1122Taimoorkhan1122/boring-react/skills/react-quality-engineering/SKILL.md

react-quality-engineering

Skill1 starsChanged 3 months agoMITView on GitHub

Design, write, run, and review tests for React, Next.js, or Vite frontends. Use for Vitest/Jest, React Testing Library, MSW, Playwright, E2E, accessibility testing, visual regression, responsive/adversarial UI testing, flaky tests, test data, CI quality gates, or frontend verification plans.

In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- react-component-engineeringSkill
- react-motion-engineeringSkill
- react-production-engineeringSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 10 are distinctive, and 4 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Verify user-observable behavior with the cheapest reliable test layer.
line 13
Very specific:
Test success plus meaningful empty/error/pending/permission/race states.
line 21
Distinctive:
Use user-facing locators and realistic interactions.
line 22
Distinctive:
Add accessibility and responsive/adversarial coverage for important UI.
line 24
Distinctive:
Do not duplicate every assertion across every layer.
line 36
Distinctive:
Test behavior, not private functions, internal state, component tree shape, or arbitrary CSS selectors.
line 40
Distinctive:
Prefer role + accessible name, then label/text.
line 41
Very specific:
Do not fix Playwright timing with arbitrary waitForTimeout sleeps.
line 42
Very specific:
Do not use networkidle as a universal readiness signal.
line 43
Distinctive:
Keep E2E tests independently runnable and data-isolated.
line 44
Very specific:
Prefer MSW over mocking fetch/Axios internals for frontend network behavior.
line 45
Distinctive:
Never update visual snapshots blindly to make CI green.
line 47
Distinctive:
Test pyramid/coverage choice: references/testing-strategy.md
line 52
Distinctive:
If tests cannot be run, provide the exact intended verification and mark it not run.
line 63

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

React Quality Engineering

Verify user-observable behavior with the cheapest reliable test layer. Do not make implementation details the contract.

Apply react-production-engineering for architecture and react-component-engineering for semantic/accessibility implementation.

Workflow

Identify the behavior/risk and choose the lowest-cost test layer that can prove it.
Reuse the repository's test stack and conventions.
Test success plus meaningful empty/error/pending/permission/race states.
Use user-facing locators and realistic interactions.
For browser tests, rely on readiness assertions and isolation—not sleeps.
Add accessibility and responsive/adversarial coverage for important UI.
Diagnose flaky tests at the root cause before adding retries.
Report what was executed, what failed, and what remains unverified.

Test layer selection

Unit: pure domain/format/validation logic.
Component: React Testing Library for rendered behavior and interaction.
Integration: component + MSW for network states and mutations.
E2E: Playwright for critical user journeys and browser integration.
Manual: keyboard/screen-reader-critical behavior and subjective visual hierarchy.

Do not duplicate every assertion across every layer.

Non-negotiable rules

Test behavior, not private functions, internal state, component tree shape, or arbitrary CSS selectors.
Prefer role + accessible name, then label/text; use test IDs only when a user-facing locator is unsuitable.
Do not fix Playwright timing with arbitrary waitForTimeout sleeps.
Do not use networkidle as a universal readiness signal.
Keep E2E tests independently runnable and data-isolated.
Prefer MSW over mocking fetch/Axios internals for frontend network behavior.
Automated accessibility checks do not prove WCAG conformance; important flows need keyboard/manual verification.
Never update visual snapshots blindly to make CI green.
Retries are a safety net after diagnosis, not a root-cause fix.

When to load references

Test pyramid/coverage choice: references/testing-strategy.md
React Testing Library: references/testing-library.md
MSW/network states: references/msw.md
Playwright/E2E: references/playwright.md
Accessibility testing: references/accessibility-testing.md
Visual/responsive testing: references/visual-regression.md
Flakiness diagnosis: references/flaky-tests.md
CI/release gates: references/ci-quality-gates.md

Completion contract

If tests cannot be run, provide the exact intended verification and mark it not run. Never imply green CI from code inspection alone.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free