frontend-test-writerlisted

Write tests for frontend Next.js/React code on demand — components, hooks (incl. TanStack Query hooks), Zod schemas, and API-binding behavior. Use this ONLY when the user explicitly asks to test frontend code — "write tests for the products grid", "test the useProductsQuery hook", "add component tests for product-card.tsx", "cover the create-product form", "test this binding". It is a standalone utility, run manually whenever the user wants — never auto-chained from frontend-feature-planner or frontend-module-builder. It reads ARCHITECTURE.md (conventions), MODULE_REGISTRY.md (what to mock vs use), the target file(s), and the FEATURE_PLAN's testing checklist if present, detects the test framework + RTL setup from package.json, and writes matching test files. It never modifies source files and never touches the registry. It is NOT for backend tests (that is backend-test-writer). Frontend / Next.js / React / Vitest+RTL scope only.
vipincode/exr-agent-skills · ★ 0 · Web & Frontend · score 57

Install: claude install-skill vipincode/exr-agent-skills

# frontend-test-writer Write tests for a frontend target the user points at — a component, a hook, a schema, a feature module, or a feature name. A pure, on-demand utility: the user calls it explicitly and it does one thing. **It is never invoked by the other skills, never modifies source, and never edits MODULE_REGISTRY.md.** ## Step 1 — Read context (do not assume) **First resolve the project dir** for this (`frontend`) domain via `../LAYOUT.md` (read `.claude/workspace.json`; fall back to the repo root if a root `ARCHITECTURE.md` for a Next.js/React app exists with no manifest). The contract files, `package.json` (framework detection), and the target files are all **relative to that project dir**. 1. The **target file(s)** the user named — read the real implementation, not an assumption of it. If they named a module or feature, read its template/components/hooks/api/schema. You test what the code actually does. 2. `ARCHITECTURE.md` — the conventions that shape assertions: the response envelope (so a mocked API response matches reality), the BFF/axios path, that server state goes through TanStack Query, that forms use the shared `*Field`, that types come from Zod. 3. `MODULE_REGISTRY.md` — to know which collaborators are real shared pieces, so you mock the *real* dependency (the `api` axios instance, a shared component, `useAuth`) rather than inventing a fake that drifts from how it actually behaves. 4. **If a `_docs/FEATURE_PLAN_<name>.md` exists** for the target, read