Reuse first

Reuse First

Agents add code. They rarely check whether that code already exists. This skill runs the check before anything gets written.

When this applies

Before writing any function that is not specific to one call site: formatters, parsers, validators, date handling, retry logic, HTTP wrappers, string manipulation, config readers, error types. If it sounds generic, it probably already exists somewhere in the repo.

Skip it for genuinely local code: a handler body, a one-off transform used in exactly one place, test setup.

The search

Search by behavior, not by the name you were going to use. The existing version is almost never called what you would have called it.

1. Say the operation in plain words. "Convert cents into a display string." Not formatCurrency.
2. Grep the operation's whole vocabulary, not one guess. For that example: currency, cents, money, amount, price, toDisplay, format.*amount. Run several. Greps are cheap, duplicate code is not.
3. Grep the distinctive constant. Code that does the same job usually contains the same magic value: a regex, a 100, a date format string, a header name, an epsilon. This finds things that no name-based search will.
4. Look in the obvious homes anyway, even if grep came back empty: utils/, lib/, common/, shared/, helpers/, internal/, and the nearest package root.
5. Look outward before writing. Does the standard library do this? Does a dependency already in package.json / go.mod / requirements.txt / Cargo.toml do this? An installed library beats a hand-rolled helper.

State what you searched for. If you searched five ways and found nothing, say that. It is a real signal, not a formality, and it tells the reviewer how much to trust the "nothing exists" claim.

The decision

What you found	What to do
Exact match	Call it. Do not write a second one.
Close, roughly 80% right	Extend the existing one. Add a parameter or an overload, and update its callers if the signature changes.
Several partial matches scattered around	Stop and tell the human. This is a consolidation decision, not a feature task.
Genuinely nothing	Write it, then follow the rules below.

Extending beats forking. One function with two callers and an extra parameter is cheaper to maintain than two functions that quietly drift apart over six months.

If you do write something new

• Put it where the next search will find it. Same directory as its siblings, named after what it does.
• Name it in this repo's vocabulary. Match local convention over your own preference, even if you find the local convention slightly worse.
• Do not create a second junk drawer. No new utils/ if one exists. No helpers/ sitting next to an existing utils/.
• Write it down in the PR description: what you searched for, what you did not find, and where the new thing lives. That single paragraph is what makes the next person's search succeed instead of producing copy number three.

Red flags in your own output

Stop and search again if you notice yourself:

• Writing a function whose body you could have pasted from elsewhere in the same diff
• Adding a second implementation because "the existing one is in the wrong place" (move it instead)
• Creating a file whose name is a synonym of an existing file, like stringUtils.ts beside strings.ts
• Reimplementing something the language already ships
• Reaching for copy-paste-and-tweak because the existing function is almost right (that is the case for extending it)