메뉴
Write React component tests using Testing Library. Test user interactions and DOM output, not implementation details.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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