What this prompt does
This prompt produces a small library of production-ready React custom hooks in TypeScript, fully typed and tested. Instead of one hook, it asks for a set defined by you, each implemented with SSR safety, effect cleanup, memoization where appropriate, JSDoc usage examples, unit tests, and Storybook stories. The aim is shared logic a team will actually trust and reuse rather than copy-pasting fetching and debouncing into every component.
The variables size and populate the library. [hook_count] sets how many hooks to build and [hooks_list] names them — useDebounce, useFetch, useLocalStorage, useInfiniteScroll, and so on — so the AI generates exactly the utilities you need. [test_runner] (commonly Vitest) determines the testing setup. The prompt demands SSR-safe implementations that check for window/document, cleanup in useEffect return values, and handling for unmounted components and race conditions, because those are precisely where shared hooks quietly introduce bugs. Tests plus Storybook stories are what turn a folder of hooks into a maintainable internal package.
When to use it
- Bootstrapping a shared hooks package so fetching and debouncing aren't reinvented per component
- Adding SSR-safe storage and media-query hooks to a Next.js or Remix app
- Standardizing data-fetching with a typed useFetch instead of ad-hoc effects
- Giving a team well-documented, tested hooks they can adopt with confidence
- Building infinite-scroll or click-outside behavior once and reusing it everywhere
- Establishing TypeScript-first conventions (generics, overloads) for hook authoring
Example output
You get one file per hook listed in [hooks_list], each a typed function with generics where useful, SSR guards, and cleanup logic, plus JSDoc blocks showing usage. A barrel file re-exports them all. Alongside sit unit tests written for your [test_runner] and Storybook stories demonstrating each hook interactively. Edge cases — unmounted components, race conditions in fetches — are handled rather than ignored, so the hooks behave under real conditions instead of just the happy path.
Pro tips
- Keep
[hooks_list]focused on genuinely reusable logic; one-off hooks belong next to their component, not in a shared library - Make
[hook_count]match the list exactly so the AI doesn't pad with hooks you'll never import - Verify the SSR guards if you render server-side; a hook that touches window without a check will crash during hydration
- Check that useFetch actually aborts in-flight requests on unmount — race-condition handling is easy to claim and easy to get wrong
- Use the generated Storybook stories as living docs, and keep them updated when a hook's API changes
- Pin your
[test_runner]to what your project already uses so the generated config drops in without conflicts
