Методология: как мы отбираем и проверяем записи

Источники

Кандидатов мы ищем на GitHub по темам экосистемы (mcp-server, claude-skills, agent-skills, claude-code-plugin и похожим) и в публичных каталогах скиллов и MCP-серверов. Из чужих каталогов берем только ссылку на первоисточник.

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

Как мы отбираем

Решаем по содержимому репозитория, описание проекта служит только подсказкой. Смотрим дерево файлов и ищем то, что можно поставить: SKILL.md, plugin.json или marketplace.json, package.json или pyproject.toml, запуск MCP-сервера, команды в README. Много звезд для нас довод за включение в каталог, поэтому такие репозитории мы разбираем особенно внимательно.

В каталог не попадают:

• репозитории, которых нет, которые в архиве или пусты;
• проекты, которые не относятся к скиллам, MCP-серверам, плагинам или CLI для агентов: обычные библиотеки, сайты, списки ссылок без своего кода;
• проекты, README которых не объясняет, что они делают и как их поставить;
• малоизвестные проекты, в которых больше 18 месяцев нет коммитов;
• дубли опубликованных записей и форки без изменений;
• сборники, в которых только чужие скиллы;
• инструменты для взлома, обхода защиты, кражи данных и рассылки спама.

Как пишется карточка

Текст карточки редакция готовит по README, SKILL.md и манифестам автора: что делает инструмент, кому он нужен, когда он не подходит, какие у него ограничения, как его удалить. Черновики мы пишем с помощью ИИ и сверяем с файлами репозитория. Команды установки берем только из документации автора. Если автор команды не дает, так и пишем.

Английский текст карточки редакция пишет вместе с русским. Если английского текста нет, сайт переводит русский автоматически по отраслевому словарю, а до перевода английская страница показывает русский текст с пометкой.

Данные из GitHub и счетчики

• Звезды, форки, лицензию, признак архива и дату последнего коммита фоновая задача берет из GitHub API и проходит весь каталог раз в сутки. Дата последней проверки видна на карточке.
• Звезды относятся ко всему репозиторию и подписаны «★ репозитория». У скиллов из одного монорепозитория число звезд общее.
• Счетчик копирований показывает, сколько раз команду скопировали кнопкой на сайте.
• Счетчик установок показывает число разных устройств за 30 дней по событиям CLI и MCP, без запусков в CI. На карточке число появляется от 10 установок.

Как мы следим за актуальностью

Каждую запись с GitHub система проверяет раз в сутки. Проблема считается подтвержденной после двух проверок подряд с разницей около суток, поэтому разовый сбой GitHub ничего не меняет.

• Репозиторий удален: запись снимается с публикации, ее адрес ведет в раздел каталога.
• Репозиторий переименован или перенесен: ссылка обновляется сама.
• Автор отправил репозиторий в архив или не обновлял его больше года: запись остается с пометкой на карточке, место в выдаче не меняется.
• Сменилась лицензия, резко упали звезды, пропала папка скилла: решение принимает редакция.
• Если проверка сама сбоит на заметной части каталога, изменения останавливаются до восстановления.

Уровень доступа

Уровень доступа показывает, что инструмент добавляет к возможностям агента. Качество кода он не оценивает. Агент и так читает файлы вашего проекта, поэтому чтение этих файлов само по себе уровень не повышает.

Уровень и причины ставит редакция по README, способу запуска и нужным правам. Автоматического аудита кода пока нет.

• Минимальный: инструкции, правила и справочные материалы. Инструмент ничего не запускает и никуда не ходит.
• Расширенный: инструмент запускает код или ходит в сеть, а данные внешних сервисов только читает.
• Широкий: инструмент пишет или удаляет данные, выполняет команды либо работает с секретами, деньгами, почтой или персональными данными.

Как доступ влияет на установку

Если доступ широкий или уровень еще не определен, на карточке нет установки в один клик в Cursor и VS Code. Запись с широким доступом CLI ставит только после явного согласия, а перед вопросом показывает причины.

Рецепты установки

Рецептом мы называем машиночитаемое описание установки: какие компоненты ставятся (скилл, MCP-сервер, плагин, CLI, правила для агента), из какого коммита и какие переменные нужны. Произвольные команды из README в рецепт не попадают.

Рецепт мы собираем в три слоя:

• манифесты репозитория на зафиксированном коммите: server.json, marketplace.json, plugin.json, package.json, pyproject.toml и папки со SKILL.md;
• команды и поля MCP из карточки: npx skills add, claude mcp add, JSON-конфиги, /plugin install, установка пакетов через npm, pip, brew, cargo и go;
• разбор README моделью ИИ, если первые два слоя ничего не дали или противоречат друг другу. Каждый путь из ответа модели мы ищем в дереве репозитория, а каждый пакет в npm, PyPI или Docker Hub. Если хотя бы одного нет, рецепт не принимаем.

Проверки рецепта

• Коммит фиксируется по SHA. Файлы скилла получают общий отпечаток sha256, чтобы сверка видела любую правку.
• Схема отклоняет рецепт, в котором есть значения, похожие на секреты, или пути, ведущие за пределы репозитория.
• Секретов в рецепте нет: вместо значения стоит имя переменной окружения.
• Каждый ответ API с рецептом подписан ключом Ed25519, а CLI проверяет подпись до установки.

Статусы рецепта

• auto: рецепт собран из манифестов и данных карточки, источники совпали, ИИ не участвовал.
• ai: рецепт собрала модель ИИ по README, пути и пакеты найдены. Ручной проверки не было, поэтому карточка и CLI показывают предупреждение.
• verified: рецепт проверил человек из редакции. Это единственный статус, который означает ручную проверку, и автоматически его не получает ни одна запись.
• review: сверка нашла изменение, важное для безопасности. Пока редакция его не проверит, сайт, API и CLI отдают последнюю принятую версию.
• unsupported: автоматической установки нет, карточка показывает ручную инструкцию автора.

Сверка с репозиторием

Фоновая задача сверяет рецепты примерно раз в неделю, а после правки карточки вне очереди. Коммит не менялся: обновляется только дата сверки. Коммит новый, но файлы компонентов те же: рецепт получает новый коммит. Изменились команда запуска, пакет, аргументы, переменные, сетевые адреса или скрипты в папке скилла: новый коммит не принимается, рецепт уходит в review.

Команда npx skillfoxx update ставит только версию, прошедшую эту сверку.

Что значит «сверено» и «проверено»

Строка «Сверено с репозиторием» на карточке означает автоматическую сверку рецепта с коммитом. Ручного аудита кода за ней нет. Надпись «Рецепт проверен вручную» стоит только у рецептов со статусом verified.

Что мы не гарантируем

• Безопасность и работоспособность стороннего кода.
• Что автор не изменит репозиторий, пакет в реестре или удаленный сервер после нашей сверки. Пакеты npm и PyPI без указанной версии и удаленные MCP-серверы автор может обновить в любой момент.
• Полноту причин уровня доступа: мы читаем README, манифесты и файлы запуска, код построчно не проверяем.
• Совместимость с каждой версией каждого агента.

Выбор редакции

Отметку ставит редакция при подготовке карточки. Ее получают проекты известных вендоров и широко используемые проекты. Отметка выражает мнение редакции и ничего не измеряет. Купить ее нельзя.

Как Foxx AI подбирает инструменты

Foxx AI предлагает только записи каталога. Сначала сайт отбирает кандидатов по совпадениям с зависимостями, фреймворками и файлами проекта и по смыслу текста запроса. Затем модель OpenAI объясняет, чем подходит каждая запись. Записи в подборе проходят те же правила отбора, что и весь каталог, и платных мест в нем нет.

На странице записи Foxx AI отвечает о самом инструменте только по данным карточки и README. Если ответа в них нет, так и говорит и дает ссылку на репозиторий.

Инциденты

Если у записи находят серьезную уязвимость или вредоносный код, мы открываем инцидент и при необходимости снимаем запись с публикации. Пока открыт инцидент высокой или критической серьезности, ни CLI, ни MCP запись не ставят. Сообщить о проблеме можно кнопкой на странице записи.