| name | reuse-first |
| description | The search-before-you-build workflow for this library. Use whenever you are about to add a new function, class, type, or kit, or when asked to implement any capability — to avoid duplicating one of the 15,000+ existing exports. |
Reuse-first workflow
This is a reusable function library. The most expensive mistake here is shipping a function that
already exists under a different name. Every "implement X" request starts with "does X already
exist?"
1. Search before writing — always
Generate several candidate terms (verb, noun, synonyms), then:
npm run search "rate limit"
npm run find "createRateLimiter"
npm run find:function
grep -rn "export .*Throttle" --include='*.ts'
Also scan the catalogs, which index public exports:
FUNCTION-CATALOG.md, MASTER-INDEX.md, QUICK-REFERENCE.md, NAVIGATION.md.
For anything non-trivial, delegate the search to the kit-explorer subagent (or run
/find-kit "<capability>") so the file reading stays out of your main context and you get back
just the verdict + import paths.
2. Decide: reuse / extend / compose / build
- EXISTS → import it (
import { x } from '@reuse/<domain>/<area>') and stop.
- PARTIAL → extend or compose existing kits rather than starting fresh.
- NOT FOUND (only after trying synonyms + catalogs) → build it, following the
kit-conventions skill, in the right domain (core/domain-shared if cross-cutting).
3. Place it where others will find it
A new function only counts as "reusable" if it's discoverable and importable:
- Wire it up the
index.ts barrel chain to the domain root.
- Give it complete JSDoc with an
@example.
- Update the catalog if it's a notable public export.
Anti-patterns
- Writing a util "real quick" without searching → silent duplicate.
- Searching only the exact name you have in mind → miss the synonym that already exists.
- Building in a leaf folder without barrel-exporting → invisible, gets duplicated again later.