From johnlindquist-claude
Design, implement, and maintain high‑value TypeScript test suites using popular JS/TS testing libraries. Use this skill whenever the user is adding tests, debugging failing tests, or refactoring code that should be covered by tests.
npx claudepluginhub joshuarweaver/cascade-ai-ml-engineering --plugin johnlindquist-claudeThis skill uses the workspace's default tool permissions.
This skill guides you to build pragmatic, maintainable test suites for TypeScript code. Focus on behavioral coverage, fast feedback, and alignment with the project's existing tooling.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
This skill guides you to build pragmatic, maintainable test suites for TypeScript code. Focus on behavioral coverage, fast feedback, and alignment with the project's existing tooling.
The user is a TypeScript‑focused developer. They likely care about correctness, refactoring safety, and not drowning in flaky or brittle tests.
Use this skill when:
Do not invent a new test stack if the repo already has one. First detect and follow the existing setup.
Always align with the repo first (check package.json, devDependencies, config files):
When you must choose, prefer:
vitest) or Jest (jest)vitest is present, use it. Else if jest is present, use that.@testing-library/react with Vitest or JestIf the repo uses a less common stack (Mocha, Ava, Node’s built‑in test runner), respect that choice and adapt.
Follow these principles:
When asked to add or improve tests, follow this workflow:
Detect the existing stack
package.json for jest, vitest, @playwright/test, cypress, @testing-library/*jest.config.*, vitest.config.*, playwright.config.*, cypress.config.*test, unit, or e2e scripts in package.jsonLocate the right place for the test
__tests__ directories, follow that*.test.ts or *.spec.ts, do the sameComponent.test.tsx) if that’s the existing conventionWrite the test in a TS‑friendly way
.test.ts / .test.tsx (or .spec) as per repo conventionany in tests when possible; use real types or minimal interfaces to keep tests robustawait with async test functions, avoid dangling promisesFollow library‑specific best practices
Vitest / Jest
describe / it or test with clear namesvi.fn() / jest.fn() for spies and mocksvi.mock() / jest.mock() and keep mocks at the top of the filevi.useFakeTimers() / jest.useFakeTimers())React Testing Library
render, screen, and user interactions (userEvent)getByRole, getByLabelText)Playwright / Cypress
data-testid or semantics consistently as locatorsAdd regression tests for reported bugs
it("does not crash when X is null (regression #123)"))Running tests
npm test, pnpm test, npx vitest, npx jest, npx playwright testpackage.json scripts following existing stylemakeUser, makeOrder) instead of duplicating setup.await promises; avoid passing async callbacks to APIs that don’t expect them.tsconfig for tests when possible (tsconfig.test.json if present)as anyIf the user asks you to generate tests, prefer fewer, high‑value tests that mirror real usage over large, mechanical test suites.