reuse-first
Skill1 starsChanged 4 months agoMITView on GitHub
Use before writing any new utility, helper, or shared function. Searches the codebase for an existing equivalent first, so the agent extends what already exists instead of adding a fifth copy of the same function. Trigger when implementing a feature that needs a helper, when about to create a file in utils/lib/common/shared, or on requests like "add a function that does X".
5 other projects use a version of this.
Adopted by
Most recently taken up by
- Leksgg/claude-skillstheir own version, first seen Oct 20, 2026
- tentenco/skillstheir own version, first seen Sep 10, 2026
- bhagyamudgal/skillstheir own version, first seen Sep 9, 2026
- phatnguyen03022001/agent-skillstheir own version, first seen Aug 24, 2026
- AlemTuzlak/skillstheir own version, first seen Aug 3, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- AlemTuzlak/skills★ 45same name
- tentenco/skills★ 5same name
- bhagyamudgal/skills★ 2same name
- phatnguyen03022001/agent-skills★ 2same name
- Leksgg/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository2 other files it gives its agents.
- duplication-reviewSkill
- duplication-sweepSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Before writing any function that is not specific to one call site: formatters, parsers, validators, date handling, retry logic, HTTP …
- Distinctive: line 19
Search by behavior, not by the name you were going to use.
- Very specific: line 44
Do not create a second junk drawer: No new utils/ if one exists.
- Distinctive: line 49
Stop and search again if you notice yourself:
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
- Say the operation in plain words. "Convert cents into a display string." Not
formatCurrency. - 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. - 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. - Look in the obvious homes anyway, even if grep came back empty:
utils/,lib/,common/,shared/,helpers/,internal/, and the nearest package root. - Look outward before writing. Does the standard library do this? Does a dependency already in
package.json/go.mod/requirements.txt/Cargo.tomldo 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. Nohelpers/sitting next to an existingutils/. - 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.tsbesidestrings.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)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.