test-writerlisted

Write tests on demand for whatever the user points at — backend services, controllers, routes, and integration paths, or frontend components, hooks, schemas, and bound screens. Use this ONLY when the user explicitly asks for tests — "write tests for auth.service.ts", "test the product module", "add component tests for product-card.tsx", "cover the create-product form", "test the useProductsQuery hook", "test this binding", "write tests for the slice I just built". It is a standalone utility run manually — never auto-chained from module-planner or module-builder, though module-builder will suggest it once a slice lands. It infers the domain from the target's path, reads ARCHITECTURE.md for conventions (the real response envelope, error model, data-fetching approach) and MODULE_REGISTRY.md for which collaborators are real shared pieces worth mocking faithfully, detects the installed test framework and mocking setup from package.json rather than assuming one, and reads the slice's Testing checklist from _docs/fe
vipincode/exr-agent-skills · ★ 0 · Testing & QA · score 57

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

# test-writer Write tests for a target the user points at — a file, a module, a feature, a slice, or just a 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`.** `module-builder` suggests running it after a slice lands, but suggesting is where that ends — the user decides. The domain is a detail, not a fork in the workflow: the shape of the work is identical either way (read the real code → detect the setup → write matching tests). Infer backend vs frontend from the target's path and the project it sits in, and pick up the matching patterns reference. A slice that spans both gets both. ## Step 1 — Read context (do not assume) Resolve the project dir for the target's domain via `../LAYOUT.md` (`.claude/workspace.json`; legacy fallback is a root `ARCHITECTURE.md`). The contract files, `package.json`, and the target files are all relative to it. 1. **The target file(s)** — read the real implementation, not an assumption of it. If the user named a module, feature, or slice, read its actual pieces: service/controller/routes on the backend, template/components/hooks/api/schema on the frontend. **You test what the code does, not what it was supposed to do** — a test written from the plan alone will pass against code that doesn't exist. 2. **`ARCHITECTURE.md`** — the conventions that shape assertions. Backend: the response envelope (so you ass