search-first
by affaan-msearch-first is a research-before-coding workflow for finding existing tools, libraries, and patterns before you write custom code. Use the search-first skill to evaluate options, compare tradeoffs, and choose adopt, extend, or build custom with less guesswork.
This skill scores 74/100, which means it is worth listing for directory users as a practical research-before-coding workflow, but it is not yet a high-confidence install because it lacks supporting repo assets and explicit installation guidance.
- Clear trigger criteria for when to use the skill, including new features, dependencies, integrations, and utility creation.
- Concrete multi-step workflow with parallel search, evaluation, and decision stages that reduces guesswork for agents.
- Good operational depth in the SKILL.md body, with explicit criteria for comparing candidate solutions.
- No install command or support files are provided, so users must infer adoption and runtime expectations from SKILL.md alone.
- The repository appears to be single-file and documentation-only, which limits trust signals and makes integration fit harder to assess.
Overview of search-first skill
What search-first is
The search-first skill is a research-before-coding workflow for finding existing tools, libraries, and implementation patterns before you write custom code. It is useful when you want the assistant to act like a careful scout, not a guess-first coder.
Who should use it
Use the search-first skill if you are starting a new feature, evaluating a dependency, adding an integration, or building a helper that may already exist. It is a strong fit for the search-first for Skill Scaffolding use case when you want to reuse proven patterns instead of inventing a new one.
Why it matters
Its main value is decision quality: it pushes the assistant to search across npm, PyPI, GitHub, web sources, and related skills before recommending code. That reduces duplicate work, improves dependency choices, and makes “build vs adopt vs wrap” decisions more defensible.
How to Use search-first skill
Install and trigger it
For search-first install, add the skill with npx skills add affaan-m/everything-claude-code --skill search-first. Trigger it when the task sounds like “add X,” “find a library for Y,” or “is there already a better way to do this?” The search-first usage pattern works best when you explicitly ask for research before implementation.
Give it a decision-shaped brief
A weak brief says “build a file parser.” A stronger brief says: “Need a TypeScript file parser for Node 18, must support streaming, no native deps, MIT license preferred, and I want 3 adopt-or-build options with tradeoffs.” That format gives the skill enough context to search well and compare candidates instead of returning generic suggestions.
Read the right files first
Start with SKILL.md, then inspect README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders if they exist. In this repo, SKILL.md is the main source of truth, so you can move quickly without hunting through extra support files.
Use the workflow as a prompt template
A practical search-first guide prompt should ask for: the need, constraints, candidate search, evaluation criteria, and a clear decision. Example: “Research existing options for X, compare 3 candidates, score them on maintenance, docs, license, and fit, then recommend adopt, extend, or build custom.” That structure helps the researcher agent return usable output instead of a loose list.
search-first skill FAQ
Is search-first only for large projects?
No. It is often most valuable on small tasks that can quietly create tech debt, such as a helper function, UI utility, or dependency choice. The cost of skipping research is usually highest when the change looks simple.
How is it different from a normal prompt?
A normal prompt may ask for ideas; the search-first skill asks for a research workflow and a decision. That difference matters because the output is meant to support adoption decisions, not just answer “what could I code?”
Is it beginner-friendly?
Yes, if you can describe your goal and constraints. Beginners benefit because the skill narrows the search space and surfaces existing options they might not know to look for. It is less helpful if you want instant code without tradeoff analysis.
When should I not use it?
Skip it when the task is obviously custom, time-critical, or tightly local to your codebase and no external solution would reasonably apply. If you already know the exact package or pattern you want, direct implementation may be faster than a full search.
How to Improve search-first skill
Provide constraints that change the search
The biggest quality gain comes from naming hard constraints up front: language, runtime, framework, license, bundle size, security rules, platform limits, and whether native dependencies are allowed. These details help the skill filter candidates instead of surfacing popular but unusable options.
Ask for comparisons, not just recommendations
A better search-first usage request asks for a short shortlist and a recommendation with reasons. For example: “Compare 3 libraries, explain why each may fail, then choose one for production and one fallback.” That produces more actionable research than a single-name answer.
Watch for shallow novelty bias
A common failure mode is picking the newest or most visible project without checking maintenance, docs, or integration cost. Improve the search-first skill by asking it to include adoption friction, ecosystem fit, and what would make you reject a candidate.
Iterate after the first pass
If the first result is too broad, tighten the next prompt with one missing constraint or one acceptance test. For search-first for Skill Scaffolding, that might mean adding the target language, the repo structure, or the exact kind of scaffold you want to reuse.