# Skill: Search for existing solutions before writing any new code

> Lets an AI coding agent systematically check four "ready-made shelves" before generating custom code -- applies to every coding task where a library, package, tool, or in-project pattern might already solve the problem.

Source: sodigi·learn -- vibecoding/snachala-ishi · https://sodigi.io/learn/vibecoding/snachala-ishi

## When to use
- Any time a user asks for a new feature, utility, or integration.
- Before implementing validation, data processing, UI components, or third-party integrations.
- When the user says "build me X" without specifying whether ready-made options should be checked.
- Especially when the task sounds common or "mundane" -- the more routine the task, the higher the chance a battle-tested solution already exists.

## Core rules
- Never write custom code for something that already exists until all four shelves have been checked in order: (1) the user's own project, (2) libraries/packages, (3) tools/MCP/extensions, (4) open-source examples online.
- Prefer popular, recently updated, well-documented libraries over hand-rolled code.
- "Popular + alive + well-documented + precise fit" = grab the ready-made option.
- "Nothing genuinely found after proper search" OR "truly unique requirement" OR "existing option is enormous for a tiny task" = write custom code.
- Do not grab an abandoned library (last commit years ago, few users) -- that is a landmine.
- Do not haul in a large framework for a single small function (reverse reinvention trap).
- Always show the user a short comparison list (2-3 options) with reasoning before committing to one.

## Procedure
1. Before writing any code, pause and announce: "Let me check what already exists."
2. **Shelf 1 -- own project:** search the existing codebase for similar functionality, components, or utilities. If found, reuse or extend.
3. **Shelf 2 -- libraries/packages:** search npm / PyPI / crates.io / relevant registry. Filter by: download count, last publish date, open issues, documentation quality.
4. **Shelf 3 -- tools/MCP/extensions:** check whether a ready-made MCP tool, plugin, or integration handles the whole task without any coding.
5. **Shelf 4 -- open source / examples:** search GitHub for a template or example. Use it as a starting point rather than a blank slate.
6. Present a short list: "Here are 2-3 options I found: [names, one-line description, why each is good/risky, my recommendation]."
7. After user confirms the choice, wire in the chosen solution. Write custom code only for the gaps the ready-made option cannot cover.

## Ready-to-use prompt
```
I need [describe the feature or function].

Before you write any code, do this:
1. Check whether similar code already exists somewhere in this project.
2. Search for popular, well-maintained libraries or packages for this need.
   Pick ones that are actively used and updated recently.
3. Show me 2-3 options as a short list: what you found, why each is good,
   which one you recommend and why.
4. Only after I confirm: plug in the chosen solution.
   Write your own code only where nothing ready-made genuinely exists.
```

## Pitfalls
- Saying "build X" without the word "find" -- the agent defaults to writing from scratch.
- Grabbing the first search result without checking freshness or popularity -- abandoned code will fail at the worst moment.
- Importing a large framework for one small function -- match size to task.
- Not asking the agent to explain what it picked -- surprises emerge weeks later.
- Duplicating something that already exists in the project's own codebase -- the most common and most expensive form of reinvention.
- Accepting the agent's "I didn't find anything" too quickly without verifying it searched properly across all four shelves.