Search-First Development

Оптимизация Claude Code с помощью навыка Search-First. Автоматизируйте поиск существующих библиотек и MCP-серверов, чтобы не изобретать велосипед в своих проектах.

Продуктивность и workflow ★ 172,651 GitHub (172,651 ★)

Навык поиска перед реализацией оптимизирует процесс разработки ПО, обеспечивая выделенный этап исследования перед началом любой реализации. Он действует как специализированный интеллектуальный слой для Claude Code, сканируя менеджеры пакетов, такие как npm и PyPI, серверы Model Context Protocol (MCP) и репозитории GitHub, чтобы найти проверенные решения для поставленной задачи. Оценивая существующие инструменты на соответствие ограничениям проекта с помощью структурированной матрицы решений, он предотвращает раздувание зависимостей и «изобретение велосипеда», гарантируя, что ваша кодовая база остаётся легковесной, поддерживаемой и соответствующей лучшим практикам отрасли.

Ключевые особенности

01Делегирование субагентам для глубокого анализа сложных сторонних интеграций

02Стандартизированная матрица решений для принятия, расширения или создания решений

03Протоколы безопасности исследований с доступом только на чтение и явными контрольными точками для подтверждения

04Автоматическая оценка кандидатов на основе поддержки, лицензии и документации

05172 651 звезда на GitHub

06Параллельное исследование npm, PyPI, MCP-серверов и GitHub

Примеры использования

01Проверка наличия существующих утилит или помощников перед созданием новых в репозитории

02Оценка сторонних библиотек для сложных задач, таких как проверка ссылок или обработка изображений

03Поиск доступных MCP-серверов для обработки интеграций с внешними API

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. APPROVAL CHECKPOINT / IMPLEMENT         │
│     Recommend package / MCP / custom code   │
│     Apply only after explicit approval      │
└─────────────────────────────────────────────┘

Decision Matrix

Signal	Action
Exact match, well-maintained, MIT/Apache	Adopt — recommend the package and request approval before install or config changes
Partial match, good foundation	Extend — recommend the package plus a thin wrapper, then wait for approval before applying
Multiple weak matches	Compose — propose 2-3 small packages and the integration plan before installing anything
Nothing suitable found	Build — explain why custom code is warranted, then implement only within the approved task scope

How to Use

Quick Mode (inline)

Before writing a utility or adding functionality, mentally run through:

Does this already exist in the repo? → Search through relevant modules/tests first
Is this a common problem? → Search npm/PyPI
Is there an MCP for this? → Check MCP configuration and search
Is there a skill for this? → Check available skills
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 — recommend `textlint-rule-no-dead-link` and ask before installing it
Result: Zero custom code if approved, 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 — recommend `got`/`httpx` directly with retry config and ask before changing dependencies
Result: Zero custom code if approved, 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 — recommend `ajv-cli` plus a project-specific schema, then wait for approval before install/write
Result: 1 package + 1 schema file if approved, 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

🔍 Что это

Search-First Development — это рабочий процесс, который превращает «исследование перед кодом» в системный навык для агента-разработчика. Вместо того чтобы сразу писать новую функцию или утилиту, агент сперва проверяет, не существует ли уже готового решения: пакета на npm/PyPI, MCP-сервера, другого навыка или GitHub-репозитория. Подход радикально сокращает количество самописного кода, ускоряет разработку и снижает риск багов, опираясь на проверенные сообществом инструменты.

⚙️ Как работает

1️⃣ Need Analysis — анализ потребности

Агент чётко формулирует, какую именно функциональность нужно добавить, и фиксирует технологические ограничения проекта (язык, фреймворк, версии).

2️⃣ Parallel Search — параллельный поиск 🔎

Запускается исследователь (subagent), который одновременно опрашивает несколько источников:

npm / PyPI — ищет подходящие пакеты;
MCP сервера — проверяет, есть ли готовый инструмент для данной задачи;
GitHub — ищет код, шаблоны или библиотеки;
Другие навыки — могут ли существующие сценарии решить проблему.

3️⃣ Evaluate — оценка кандидатов

Каждый найденный вариант оценивается по шкале:

Функциональность (точность совпадения);
Обслуживаемость (частота обновлений, коммиты);
Сообщество (звёзды, contributors);
Документация;
Лицензия (MIT/Apache — предпочтительно);
Зависимости (размер и транзитивность).

4️⃣ Decide — решение по матрице

Сигнал	Действие
Точное совпадение, хорошо поддерживается, лицензия MIT/Apache	Adopt — рекомендовать пакет и запросить одобрение на установку
Частичное совпадение, хорошая основа	Extend — рекомендовать пакет + тонкую обёртку, ждать одобрения
Несколько слабых кандидатов	Compose — предложить комбинацию из 2-3 маленьких пакетов и план интеграции
Ничего не подходит	Build — объяснить, почему нужен собственный код, и реализовать только в рамках текущего таска

5️⃣ Approval Checkpoint / Implementation 🔒

Перед любой записью (установка пакета, изменение конфигурации, создание PR) агент обязательно получает явное одобрение пользователя. Для действий с платными сервисами, паролями или сетевыми изменениями возвращается чек-поинт с рекомендацией — без автоматического применения.

🎯 Когда использовать

Новая функциональность — добавление «проверки битых ссылок», «HTTP-клиента», «валидатора схем»;
Добавление зависимостей — перед тем как прописать npm install или pip install;
Перед написанием утилит — если кажется, что нужен хелпер, сначала поищите готовый;
Планирование архитектуры — на этапе выбора стека и паттернов интеграции;
Интеграция с внешними сервисами — проверка, не существует ли уже MCP-сервер для нужного API.

💡 Примеры из практики

Пример 1: «Добавить проверку битых ссылок в Markdown»

Поиск: npm "markdown dead link checker"
Найдено: textlint-rule-no-dead-link (оценка 9/10)
Решение: Adopt — рекомендовать пакет и запросить одобрение перед npm install
Итог: ноль строк самописного кода, готовое battle-tested решение

Пример 2: «Добавить HTTP-клиент с повторными попытками»

Поиск: PyPI httpx retry, npm http client retry
Найдено: got (Node) с плагином retry, httpx (Python) со встроенными retry
Решение: Adopt — рекомендовать и попросить одобрение
Итог: 0 строк кода обёртки, конфигурация в несколько строк

Пример 3: «Добавить линтер для конфигурационных файлов»

Поиск: npm "config linter schema"
Найдено: ajv-cli (оценка 8/10)
Решение: Adopt + Extend — рекомендовать ajv-cli + написать один файл схемы, ждать одобрения
Итог: 1 внешний пакет + 1 файл схемы вместо десятков строк валидации

🚫 Антипаттерны

❌ Jumping to code — писать утилиту, не проверив, существует ли она;
❌ Ignoring MCP — не смотреть, не предоставляет ли уже MCP-сервер нужную возможность;
❌ Over-customizing — оборачивать библиотеку так тяжело, что пропадают все её преимущества;
❌ Dependency bloat — ставить массивный пакет ради одной маленькой функции.

🧩 Интеграция с другими агентами

Планировщик (planner agent) должен запускать исследователя перед фазой Architecture Review, чтобы избежать изобретения велосипедов в плане.
Архитектор (architect agent) использует результат поиска для выбора стека и обнаружения готовых reference-архитектур.
Iterative-retrieval skill — комбинируется для глубинного поиска: сначала широкий обзор (npm/PyPI/MCP), затем детальная оценка лучших кандидатов, затем проверка совместимости с проектом.

💎 Важно знать

Режим read-only по умолчанию — исследование проводится без изменений в проекте. Любой запрос на установку или конфигурацию возвращается как рекомендация с запросом одобрения.
Шорткаты — для типовых задач (линтер, форматтер, HTTP-клиент, валидация) в навыке уже указаны конкретные имена пакетов (например, eslint, pytest, httpx, zod). Их можно искать напрямую, не тратя время на формулировку запроса.
Быстрый режим — для простых нужд достаточно мысленно пройти чек-лист: "Есть ли это в репозитории? Это частая проблема? Есть ли MCP? Есть ли другой навык? Есть ли шаблон на GitHub?"
Полный режим — для сложных задач делегируйте поиск исследовательскому subagent'у с указанием языка и ограничений.

Установка одной командой.

npx skillfish add affaan-m/everything-claude-code search-first

Источник: https://mcpmarket.com/tools/skills/search-first-development-3