Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.
---
name: search-first
description: Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.
origin: ECC
---
# /search-first ā Research Before You Code
Systematizes the "search for existing solutions before implementing" workflow.
## Trigger
Use this skill when:
- Starting a new feature that likely has existing solutions
- Adding a dependency or integration
- The user asks "add X functionality" and you're about to write code
- Before creating a new utility, helper, or abstraction
## Workflow
```
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā 1. NEED ANALYSIS ā
ā Define what functionality is needed ā
ā Identify language/framework constraints ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā 2. PARALLEL SEARCH (researcher agent) ā
ā āāāāāāāāāāāā āāāāāāāāāāāā āāāāāāāāāāāā ā
ā ā npm / ā ā MCP / ā ā GitHub / ā ā
ā ā PyPI ā ā Skills ā ā Web ā ā
ā āāāāāāāāāāāā āāāāāāāāāāāā āāāāāāāāāāāā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā 3. EVALUATE ā
ā Score candidates (functionality, maint, ā
ā community, docs, license, deps) ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā 4. DECIDE ā
ā āāāāāāāāāāā āāāāāāāāāāāā āāāāāāāāāāā ā
ā ā Adopt ā ā Extend ā ā Build ā ā
ā ā as-is ā ā /Wrap ā ā Custom ā ā
ā āāāāāāāāāāā āāāāāāāāāāāā āāāāāāāāāāā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¤
ā 5. IMPLEMENT ā
ā Install package / Configure MCP / ā
ā Write minimal custom code ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
```
## Decision Matrix
| Signal | Action |
|--------|--------|
| Exact match, well-maintained, MIT/Apache | **Adopt** ā install and use directly |
| Partial match, good foundation | **Extend** ā install + write thin wrapper |
| Multiple weak matches | **Compose** ā combine 2-3 small packages |
| Nothing suitable found | **Build** ā write custom, but informed by research |
## How to Use
### Quick Mode (inline)
Before writing a utility or adding functionality, mentally run through:
0. Does this already exist in the repo? ā `rg` through relevant modules/tests first
1. Is this a common problem? ā Search npm/PyPI
2. Is there an MCP for this? ā Check `~/.claude/settings.json` and search
3. Is there a skill for this? ā Check `~/.claude/skills/`
4. Is there a GitHub implementation/template? ā Run GitHub code search for maintained OSS before writing net-new code
### Full Mode (agent)
For non-trivial functionality, launch the researcher agent:
```
Task(subagent_type="general-purpose", prompt="
Research existing tools for: [DESCRIPTION]
Language/framework: [LANG]
Constraints: [ANY]
Search: npm/PyPI, MCP servers, Claude Code skills, GitHub
Return: Structured comparison with recommendation
")
```
## Search Shortcuts by Category
### Development Tooling
- Linting ā `eslint`, `ruff`, `textlint`, `markdownlint`
- Formatting ā `prettier`, `black`, `gofmt`
- Testing ā `jest`, `pytest`, `go test`
- Pre-commit ā `husky`, `lint-staged`, `pre-commit`
### AI/LLM Integration
- Claude SDK ā Context7 for latest docs
- Prompt management ā Check MCP servers
- Document processing ā `unstructured`, `pdfplumber`, `mammoth`
### Data & APIs
- HTTP clients ā `httpx` (Python), `ky`/`got` (Node)
- Validation ā `zod` (TS), `pydantic` (Python)
- Database ā Check for MCP servers first
### Content & Publishing
- Markdown processing ā `remark`, `unified`, `markdown-it`
- Image optimization ā `sharp`, `imagemin`
## Integration Points
### With planner agent
The planner should invoke researcher before Phase 1 (Architecture Review):
- Researcher identifies available tools
- Planner incorporates them into the implementation plan
- Avoids "reinventing the wheel" in the plan
### With architect agent
The architect should consult researcher for:
- Technology stack decisions
- Integration pattern discovery
- Existing reference architectures
### With iterative-retrieval skill
Combine for progressive discovery:
- Cycle 1: Broad search (npm, PyPI, MCP)
- Cycle 2: Evaluate top candidates in detail
- Cycle 3: Test compatibility with project constraints
## Examples
### Example 1: "Add dead link checking"
```
Need: Check markdown files for broken links
Search: npm "markdown dead link checker"
Found: textlint-rule-no-dead-link (score: 9/10)
Action: ADOPT ā npm install textlint-rule-no-dead-link
Result: Zero custom code, battle-tested solution
```
### Example 2: "Add HTTP client wrapper"
```
Need: Resilient HTTP client with retries and timeout handling
Search: npm "http client retry", PyPI "httpx retry"
Found: got (Node) with retry plugin, httpx (Python) with built-in retry
Action: ADOPT ā use got/httpx directly with retry config
Result: Zero custom code, production-proven libraries
```
### Example 3: "Add config file linter"
```
Need: Validate project config files against a schema
Search: npm "config linter schema", "json schema validator cli"
Found: ajv-cli (score: 8/10)
Action: ADOPT + EXTEND ā install ajv-cli, write project-specific schema
Result: 1 package + 1 schema file, no custom validation logic
```
## Anti-Patterns
- **Jumping to code**: Writing a utility without checking if one exists
- **Ignoring MCP**: Not checking if an MCP server already provides the capability
- **Over-customizing**: Wrapping a library so heavily it loses its benefits
- **Dependency bloat**: Installing a massive package for one small feature