--- name: find-tool description: Use when the user needs to find a tool, library, skill, MCP server, OSS project, or paid SaaS that solves a specific task. Goes through a fixed search route — first the local toolkit catalog, then skill marketplaces (SkillHub, claudeskills.club), MCP catalogs (mcpmarket, glama, smithery), GitHub awesome-lists and direct GitHub search, Reddit, X, AI-news sources, paid SaaS aggregators. Always verifies freshness of every candidate (last commit / release date) and flags deprecated projects. Returns a categorized shortlist with a clear top-pick recommendation, then asks whether to install. Triggers on "найди инструмент под X", "поищи скилл для Y", "есть ли что-то под Z", "есть ли MCP для W", "поищи готовое для V", "что есть на рынке для U", "find a tool for X". Not for general advice — use only when the user wants concrete tool candidates, with names, links, and freshness data. Not for installing a tool the user already named. --- # find-tool ## Core purpose Когда пользователь говорит «найди инструмент под X», скилл проходит фиксированный маршрут поиска по всем релевантным источникам и возвращает структурированный шортлист кандидатов. Цель — чтобы пользователь не повторял каждый раз «загляни сюда, потом сюда, потом проверь свежесть». Маршрут зашит в скилл, расширение маршрута идёт через обновление reference-карты (`playbooks/tool-sources.md`). Скилл ищет инструменты любой природы — Claude-скиллы, MCP-серверы, OSS-программы и библиотеки, платные SaaS — и не зацикливается на одном типе. Часто лучшее решение задачи это связка («скилл-обёртка над OSS-CLI», «MCP-сервер платного API»). --- ## Invocation modes - `/find-tool <задача>` — полный режим. Пройти все 7 шагов карты источников, проверить свежесть каждого кандидата, вернуть шортлист с рекомендацией. По умолчанию. - `/find-tool quick <задача>` — быстрый режим. Только Шаги 0-2 карты (свой каталог + маркетплейсы + Anthropic-стек). Без awesome-листов, GitHub-поиска, Reddit и X. Используем когда нужен быстрый ответ и задача типовая. Если пользователь не указал режим — по умолчанию `quick` для типовых задач (PDF→Excel, сжатие изображений, OCR), полный режим — для специфичных или нишевых задач, где маркетплейсы вряд ли что-то покажут. В обоих режимах **обязательная проверка свежести** для top-кандидатов: дата последнего коммита/релиза и наличие deprecation-нотиса. --- ## Reference files Загружай при каждом вызове: - [playbooks/tool-sources.md](../../playbooks/tool-sources.md) — карта источников: типы инструментов, порядок поиска по 7 шагам, кто из авторов высокосигнальный, как оценивать качество, что делать с найденным. Это основной reference. Если в ней упомянут шаг или источник, который скилл не знает — значит карту обновили, иди по новой версии. Также используй: - `dzen-toolkit/INDEX.md` и `<категория>/INDEX.md` — для Шага 0 (свой каталог). - `dzen-toolkit/<категория>/candidates/` — описания уже найденных, но не установленных кандидатов. --- ## Алгоритм работы ### Фаза 1. Уточни задачу Перед поиском убедись что понял задачу. Если запрос абстрактный («найди что-то для аналитики») — задай 1-2 уточняющих вопроса: какой вход (файлы, API, Slack-сообщения), какой выход (Excel, dashboard, отчёт), какой сценарий использования (раз в неделю vs ad-hoc, локально vs в облаке). Без этого поиск даст шум. Не задавай больше двух уточняющих вопросов — если задача всё ещё неясна, ищи под самую вероятную интерпретацию и в ответе явно зафиксируй «искал под такую формулировку, скажи если другое». ### Фаза 2. Шаг 0 — свой каталог Прежде чем идти наружу, всегда смотри `dzen-toolkit/INDEX.md` и каталоги кандидатов. Если что-то близкое уже: - **Установлено** — сразу скажи пользователю «вот это уже стоит, попробуй сначала его». Часто этого достаточно — внешний поиск не нужен. - **В кандидатах** — surface как кандидата, расскажи что он делает, почему отложен, и спроси «ставим под эту задачу или ищем что-то ещё?». - **Парковано** (`skills/parked/`) — был на установке, но снят. Не предлагай заново без особой причины — узнай у пользователя почему он там. ### Фаза 3. Поиск по внешним источникам Иди по карте `tool-sources.md` сверху вниз. В режиме `quick` останавливайся после Шага 2. В полном режиме — до Шага 7. Параллельность: WebSearch-запросы можно пускать параллельно. WebFetch для проверки конкретных репозиториев — тоже. Не тратьте время на последовательные запросы там, где они независимы. Запросы формулируй с **датой**: «PDF table extraction 2026», «mcp server slack 2026». Свежесть результатов критична, особенно в AI-нише. Под каждый шаг применимы свои источники — см. карту. Не зацикливайся на одном типе инструмента: если задача про парсинг PDF, ищи и Claude-скиллы, и OSS-CLI, и платные API параллельно. ### Фаза 4. Проверка свежести и качества top-кандидатов Для каждого кандидата, который попадает в шортлист: 1. **Свежесть.** Открой страницу проекта на GitHub (через WebFetch) или PyPI/npm. Посмотри дату последнего релиза. Если больше 3 месяцев — флагнуй «может быть несвежим», если больше 6 месяцев — флагнуй сильно. 2. **Deprecation.** Прочитай README первой страницы. Ищи слова «deprecated», «archived», «moved to», «successor». Если есть — выясни какой проект-наследник и переключайся на него. 3. **Платные зависимости.** Если в README инструмент явно требует платный API (DataForSEO, Semrush, Ahrefs, OpenAI ключи и так далее) — отметь это в карточке. 4. **Бенчмарки.** Если задача из категории, где есть независимые бенчмарки (PDF-парсинг, OCR, embeddings) — найди свежий бенчмарк (за 2025-2026) и сошлись на него. Применяй критерии оценки качества из карты `tool-sources.md`. Звёзды на гитхабе — слабый сигнал сами по себе. ### Фаза 5. Сборка отчёта Выходной формат — markdown-отчёт со следующей структурой: ``` ## Что искали [Одна строка: задача, как ты её понял] ## Что уже есть в твоём каталоге [Если что-то близкое нашлось в Шаге 0 — здесь. Иначе «ничего подходящего»] ## Рекомендация [1-3 top-кандидата. По каждому: имя, тип, ссылка, дата последнего апдейта, 2-3 строки почему именно этот, известные минусы] ## Остальные кандидаты, разложенные по типу ### Claude-скиллы [имя — короткое описание — ссылка — дата апдейта — флаг свежести] ### MCP-серверы [то же] ### OSS-инструменты / CLI [то же] ### Платные SaaS / API [то же — с ценой если известна] ### Библиотеки / SDK [то же] ## Что я бы делал [Одна-две фразы: какой кандидат пробовать первым и почему именно его, учитывая контекст пользователя — solo-founder, не-инженер, локально лучше чем облако когда возможно] ## Дальше - Поставить top-кандидата [имя]? - Или положить в кандидаты несколько штук, не ставить сейчас? - Или искать дальше с другими ключевыми словами? ``` В отчёте **не используй** длинные пути к файлам, JSON-блоки, code-снипеты в команде установки. Пользователь — solo-founder, не инженер. Описывай словами «это бесплатный локальный инструмент, ставится за минуту, я ставлю сам если скажешь». Команды для установки сам пишу через Bash, не отдаю пользователю. ### Фаза 6. Действие после ответа Когда пользователь выбрал кандидата — действуй по правилам из `tool-sources.md` («что делать с найденным»): 1. **Ставим** — кладём в `dzen-toolkit/<категория>/<имя>/`, симлинкаем в `~/.claude/skills/` если это скилл, обновляем `INDEX.md` категории и главный `INDEX.md`. 2. **В кандидаты** — кладём описание в `dzen-toolkit/<категория>/candidates/<имя>.md` по стандартному формату (что делает, когда применять, когда не лезть, что нужно на входе, почему пока не ставим, как ставится, плюсы и минусы). 3. **Ничего пока** — спрашиваем хочет ли пользователь зафиксировать сам факт поиска (короткой записью в `playbooks/tool-sources.md` или session-note), чтобы в следующий раз не переискивать с нуля. --- ## Антипаттерны — чего не делать - **Не возвращать список без рекомендации.** Шортлист без top-pick — это «решай сам», что противоречит цели скилла. Всегда выделяй 1-3 победителей и одну строку «что я бы делал». - **Не доверять только звёздам.** 25k★ проект, не обновлявшийся год, хуже чем 200★ свежий и активный. - **Не цитировать README автора как бенчмарк.** Цифры от автора всегда подозрительны. Ищи независимые сравнения. - **Не пропускать deprecation-проверку.** Один из самых частых факапов — рекомендовать инструмент, преемник которого уже выпущен под другим именем (классический пример — `llama_cloud_services` → `llama-cloud`). - **Не загромождать отчёт.** 15 кандидатов разной степени релевантности с одинаково длинными описаниями — это шум. Резкая иерархия: top-3 разверну́ты, остальные — одна строка. - **Не игнорировать свой каталог.** Если в `dzen-toolkit` уже есть установленное или кандидат — это первое что показываем, не последнее. - **Не запускать установку самовольно.** Скилл возвращает рекомендацию и спрашивает «ставим?». Установка — отдельный шаг, после явного «да». --- ## Сигнал качества: повторное использование Если пользователь часто запускает `/find-tool` под одну и ту же область (PDF, видео, маркетинг, аналитика) — это сигнал, что стоит сделать предметный скилл-каталог под эту область. Surface это пользователю на 3-м похожем запросе: «у тебя уже три раза была задача по PDF — может оформить отдельный playbook или специализированный скилл?».