mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-01 06:23:28 +08:00
180 lines
7.4 KiB
Markdown
180 lines
7.4 KiB
Markdown
---
|
|
name: search-first
|
|
description: >
|
|
Research-before-coding workflow. Search for existing tools, libraries, and
|
|
patterns before writing custom code. Systematizes the "search for existing
|
|
solutions before implementing" approach. Use when starting new features or
|
|
adding functionality.
|
|
metadata:
|
|
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
|
|
|
|
## Scope and Approval Rules
|
|
|
|
Default to read-only research: inspect the repo, package metadata, docs, and public examples before recommending a dependency or integration. Do not install packages, configure MCP servers, publish artifacts, open PRs, or make external write actions from this skill unless the user has explicitly approved that action in the current task.
|
|
|
|
When a candidate requires credentials, paid services, network writes, or project-wide config changes, return a recommendation and approval checkpoint instead of applying it directly.
|
|
|
|
## 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? → Search through relevant modules/tests first
|
|
1. Is this a common problem? → Search npm/PyPI
|
|
2. Is there an MCP for this? → Check MCP configuration and search
|
|
3. Is there a skill for this? → Check available skills
|
|
4. Is there a GitHub implementation/template? → Run GitHub code search for maintained OSS before writing net-new code
|
|
|
|
### Full Mode (subagent)
|
|
|
|
For non-trivial functionality, delegate to a research-focused subagent:
|
|
|
|
```
|
|
Invoke subagent with prompt:
|
|
"Research existing tools for: [DESCRIPTION]
|
|
Language/framework: [LANG]
|
|
Constraints: [ANY]
|
|
|
|
Search: npm/PyPI, MCP servers, 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 → Check 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
|
|
|
|
## When to Use This Skill
|
|
|
|
- Starting new features
|
|
- Adding dependencies or integrations
|
|
- Before writing utilities or helpers
|
|
- When evaluating technology choices
|
|
- Planning architecture decisions
|