Menu
Write React component tests using Testing Library. Test user interactions and DOM output, not implementation details.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Drive the project's task list unattended — pick the next dependency-unblocked task, dispatch a task-worker subagent to complete it, self-verify the result, then loop. Use when the user wants to work through tasks.md sequentially without supervision (e.g. overnight runs). By default continues past isolated task failures (parks the failed work non-destructively, skips its dependents, keeps going) and trips a circuit breaker only on systemic failure; pass --strict for stop-on-first-failure.
Write end-to-end tests using Playwright. Test user behavior, not implementation details. Also useful for non-test Playwright scripting.
Migrate an npm package from long-lived NPM_TOKEN credentials to OIDC trusted publishing on GitHub Actions, with npm provenance attestations. Use this skill whenever the user mentions migrating to trusted publishing, eliminating NPM_TOKEN, setting up OIDC for npm, adding provenance attestations, publishing from CI without a token, or converting an existing release workflow to use a trusted publisher — even if they describe it in their own words like "get rid of the npm token" or "publish from GitHub Actions securely". Also use it proactively when reviewing a release workflow that still uses `NODE_AUTH_TOKEN`/`NPM_TOKEN` and the user is auditing CI secrets.
Write React components following idiomatic patterns, hooks best practices, and performance optimizations
Write React components designed to be easily tested with Playwright and Testing Library — semantic HTML, clear boundaries, no test-specific hacks
Write StyleX styles correctly — longhand properties, nested pseudo-classes/media queries, no shorthands
| name | testing-library |
| description | Write React component tests using Testing Library. Test user interactions and DOM output, not implementation details. |
The more your tests resemble the way your software is used, the more confidence they can give you.
@testing-library/user-event version firstLook for it in package.json devDependencies:
v13 and below — direct synchronous calls:
userEvent.click(screen.getByRole('button', { name: /submit/i }))
userEvent.type(screen.getByLabelText(/email/i), 'user@example.com')
v14+ — setup instance, all async:
const user = userEvent.setup()
await user.click(screen.getByRole('button', { name: /submit/i }))
await user.type(screen.getByLabelText(/email/i), 'user@example.com')
getByRole() — buttons, headings, inputs, links, dialogsgetByLabelText() — form inputs with labelsgetByText() / getByAltText() — visible text, imagesgetByTestId() — last resort only (add a comment explaining why)Query variants: getBy* throws if missing · queryBy* returns null · findBy* async · getAllBy* returns array
screen.*, never container.querySelector()/submit/i) for resilience to text changesfindBy* or waitForuserEvent over fireEvent for standard interactionsfireEvent IS appropriate for: gesture sequences (mouseDown/Up), custom event data (clientX/Y), transition/media eventsexpect(el).toBeInTheDocument()
expect(el).toBeVisible()
expect(el).toBeDisabled() / .toBeEnabled()
expect(el).toHaveTextContent('foo')
expect(el).toHaveValue('bar')
expect(el).toHaveAttribute('href', '/x')
container.querySelector() — couples to HTML structuregetByTestId() as first choice — bypasses accessibility checkinggetByTitle() for non-title elements — not reliably accessiblefireEvent for standard clicks/typing