Создание динамического каталога приложений GitHub с помощью Claude для поиска open-source ПО

Проблемы интерфейса GitHub и поиск бесперебойного доступа к ПО

На платформе GitHub хранится колоссальный объем по-настоящему качественного бесплатного программного обеспечения с открытым исходным кодом. Однако в качестве интерфейса для поиска и установки приложений это один из худших вариантов, существующих на сегодняшний день. Здесь нет возможности просматривать программы по категориям, отсутствует кнопка установки, а в половине случаев файл README написан так, будто вы уже заранее знаете, что такое инструментарий сборки. Устав от этого, я использовал Claude для создания обходного пути — надстройки над GitHub, напоминающей магазин приложений.

GitHub отчаянно нуждается в улучшении пользовательского опыта, ведь поиск хорошего софта не должен требовать степени в области компьютерных наук. Если вы, как и я, любите бесплатное ПО с открытым исходным кодом (FOSS), выступаете за него и пользуетесь им ежедневно, у вас, вероятно, сложились несколько противоречивые отношения с GitHub. Главное достоинство GitHub заключается в том, что именно там обычно находится исходный код только что открытого вами приложения с открытым исходным кодом. Даже если у такого приложения есть собственный сайт с описанием функций, GitHub позволяет изучить код, проверить текущие проблемы, отмеченные другими пользователями, и оценить, насколько отзывчивым является разработчик проекта.

Ограничения поиска и позиционирование платформы

В то же время GitHub отвратительно справляется с задачей помощи обычным пользователям в обнаружении этих потрясающих проектов. Например, вы не можете зайти на GitHub, ввести в поиск «альтернатива Notion» и рассчитывать на что-то похожее на интерфейс магазина приложений. Конечно, на GitHub существуют темы репозиториев, и проекты можно отмечать тегами вроде «заметки» или «менеджер паролей», но такая категоризация полностью зависит от того, как мейнтейнер решил описать и пометить свой репозиторий.

Поиск GitHub также может осуществляться по названиям репозиториев, описаниям, коду и другим метаданным, но изначально он создан для разработчиков, ищущих софт, а не для обычных пользователей, ищущих конкретные приложения. Справедливости ради стоит отметить, что GitHub и не задумывался как магазин приложений. На нем размещается всё: от приложений и библиотек, необходимых для их создания, до наборов данных, книг и даже стихотворений. Это платформа для хостинга Git-репозиториев и предоставления инструментов контроля версий, совместной работы и отслеживания ошибок. Поиск приложений никогда не был главной целью.

Проблема установки и создание решения с помощью Claude

Тем не менее, поскольку на платформе хранится так много отличного софта, должен существовать более удобный способ сделать его доступнее. Поиск — это лишь половина проблемы. Даже после того как вы нашли хорошее приложение, процесс установки не имеет простых вариантов. Некоторые проекты снабжены превосходной документацией по установке, в то время как другие представляют собой сплошную стену технического жаргона. Для технически подкованного пользователя это лишь незначительное неудобство, но для нетехнического человека оно может стать непреодолимым тупиком.

Я сталкивался с этим лично, когда рекомендовал FOSS-приложения друзьям и близким. Я нахожу действительно полезный инструмент с открытым исходным кодом на GitHub, отправляю им ссылку, а они понятия не имеют, что делать дальше. Поэтому я захотел решить эту проблему. Я решил использовать Claude для создания интерфейса, который располагается поверх GitHub и воспринимает огромную коллекцию FOSS-проектов скорее как магазин приложений. Это упрощает поиск программ, понимание того, чем на самом деле занимается проект, оценку его пригодности для вас и, по возможности, установку без необходимости изучать принципы работы Git.

Как я использую Claude для решения проблемы и преодоления жаргона

Идея довольно проста: я открываю Claude и говорю ему, какое приложение мне нужно. Это может быть альтернатива конкретной программе — скажем, Notion или Todoist, — или просто категория интересующего меня софта, например, хорошее приложение для заметок с открытым исходным кодом. На основе моих пожеланий Claude начинает поиск в интернете. Во-первых, Claude сверяется с собственной базой знаний для поиска приложений, наиболее полно отвечающих моим требованиям, а затем перепроверяет их на GitHub, чтобы убедиться, что они по-прежнему поддерживаются, обновляются и работают. Это формирует первый набор приложений.

Во-вторых, программа производит поиск по AlternativeTo — огромной краудсорсинговой базе данных программного обеспечения и его альтернатив — для формирования второго набора. В-третьих, она запускает общий веб-поиск для обнаружения статей, рекомендаций и других источников, которые могли пропустить первые два метода. Затем Claude использует все три источника для отбора примерно 10–15 приложений и представляет их мне в простом макете. Для каждого приложения я могу видеть его название, краткое описание, скриншоты (при наличии) и полезные показатели, такие как количество звезд и форков на GitHub. Одно это решает проблему с интерфейсом GitHub, с которой я сталкивался.

После этого я могу просто сказать Claude: «Я хочу установить это приложение». Затем Claude изучает исходный код и страницу текущих проблем проекта на предмет наличия подозрительных элементов, прежде чем я продолжу работу. Разумеется, это не заменяет антивирусный сканер или полноценный аудит безопасности, и ложноотрицательные результаты вполне возможны. Но я считаю это полезным дополнительным уровнем проверки, а не установкой приложения вслепую. Если исходный код выглядит нормально, Claude затем проверяет, способна ли моя система запустить это приложение. Определенные программы требуют специфических зависимостей и не установятся без них.

Автоматизация зависимостей и установка приложений

Некоторые проекты на GitHub говорят об этом не слишком прямо, но Claude обычно способен самостоятельно определить, какие зависимости необходимы, основываясь на типе проекта.

Если вы используете Claude Code, весь этот процесс можно полностью автоматизировать. Данный инструмент разработан так, чтобы иметь доступ к вашей системе и запускать команды терминала, что означает возможность проверить наличие необходимых зависимостей и установить недостающие.

Если вместо этого вы применяете веб-приложение Claude, оно сгенерирует команды для терминала, однако запускать их придется самостоятельно.

После завершения проверки зависимостей Claude переходит к установке самого приложения.

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

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

Ниже представлен промпт для настройки навыка, а также всех сопутствующих файлов и скриптов, необходимых для этого рабочего процесса:

Создайте навык под названием «github-installer», который превращает GitHub в магазин приложений с возможностью просмотра и установки.

Условия срабатывания и этапы работы навыка

Когда срабатывает навык

Любой запрос на поиск ПО по категории или в качестве альтернативы известной программе — например, «найди альтернативу Notion», «инструмент для создания скриншотов с открытым исходным кодом», «что-то вроде Todoist, но с возможностью саморазвертывания». Также срабатывает по запросу «установить [название приложения] с GitHub».

Шаг 1. Уточнение запроса

Перед началом поиска необходимо установить три параметра (задавайте вопросы только в том случае, если они неочевидны):

• Операционная система и дистрибутив/версия.
• Графическое приложение (GUI), инструмент командной строки (CLI) или сервис для саморазвертывания.
• Любые критические требования (dealbreakers): программа должна активно поддерживаться, работать исключительно оффлайн, не требовать использования Docker и так далее.

Не задавайте вопросы более чем в один раунд. Делайте выводы на основе того, что уже известно.

Шаг 2. Поиск из трех независимых источников

Запустите все три метода поиска, а затем объедините результаты. Не останавливайтесь после проверки только одного источника.

1. Проверенные базовые знания. Перечислите кандидатов, которых вы уже знаете, а затем подтвердите через API GitHub, что каждый из них все еще существует и поддерживается. Удалите всё, что не удалось проверить — не предлагайте приложение, подлинность которого вы не подтвердили.
2. AlternativeTo. Выполните поиск по сайту alternativeto.net для конкретного приложения или категории, отфильтровав результаты по признаку открытого исходного кода. Обратите внимание на количество голосов сообщества.
3. Открытый веб-поиск. Ищите недавние подборки, обсуждения на Reddit и Hacker News, а также списки из категории «awesome-lists». Отдавайте приоритет источникам за последние 18 месяцев.

Объедините результаты в сокращенный список без дубликатов, состоящий из 10–15 позиций. Если после проверки уцелело менее 6 вариантов, скажите об этом прямо вместо того, чтобы искусственно дополнять список.

Шаг 3. Сбор реальных данных для каждого кандидата

Для каждого репозитория обратитесь к API GitHub и соберите следующие данные:

• количество звезд (stars), форков (forks) и открытых проблем (open issues);
• дата последнего коммита в ветку по умолчанию (default branch);
• лицензия и статус архивации репозитория;
• теги (topics);
• файл README.

Используйте команду gh api, если установлен и аутентифицирован интерфейс командной строки GitHub CLI, поскольку лимит для неаутентифицированных запросов составляет 60 в час, и 15 репозиториев вместе с их файлами README быстро исчерпают этот лимит. Если утилита gh недоступна, используйте curl и предупредите пользователя об ограничениях.

Помечайте как неподдерживаемые (unmaintained) любые заархивированные репозитории или проекты без коммитов в течение 12 месяцев и более. Включайте их в общую галерею, но отмечайте четко и заметно; не удаляйте их молча.

Скриншоты. Проанализируйте каждый файл README на предмет URL-адресов изображений и извлеките первые два или три изображения, похожие на скриншоты приложения. Пропускайте значки (shields.io, img.shields, badgen), логотипы и иконки.

Преобразуйте относительные пути в абсолютные ссылки формата raw.githubusercontent.com/{owner}/{repo}/{default_branch}/{path}, чтобы они корректно загружались вне интерфейса GitHub. Если у репозитория нет подходящих скриншотов, отобразите карточку-заглушку вместо бибтого изображения.

Шаг 4. Создание галереи

Сгенерируйте единый автономный HTML-файл, содержащий весь CSS инлайн, без внешних зависимостей и этапов сборки.

• Адаптивная сетка карточек (responsive card grid), по одной карточке на приложение.
• Скриншот располагается в верхней части каждой карточки, а остальные скриншоты доступны через простой просмотр по клику, если их больше одного.
• Под изображением находятся: название приложения, описание в одно предложение простым языком (перепишите технический жаргон из README, не копируйте его дословно), а также строка метаданных с указанием звезд, форков, даты последнего коммита и лицензии.
• Цветной значок статуса поддержки: активный (active) / медленный (slow) / неподдерживаемый (unmaintained).
• Кнопки со ссылками на репозиторий и домашнюю страницу проекта.
• Возможность сортировки по количеству звезд и дате последнего коммита.
• Темная тема, большое количество свободного пространства (whitespace), без использования тяжелых фреймворков.

В среде Claude Code: запишите файл в рабочий каталог и откройте его в браузере по умолчанию. В веб-приложении Claude: верните результат в виде HTML-артефакта.

Шаг 5. Предварительная проверка безопасности и работоспособности (Smell Test)

Когда пользователь выбирает приложение, выполните быструю проверку перед любым вмешательством в систему.

Это не является аудитом безопасности — сообщайте об этом пользователю явно и каждый раз.

Проверка зависимостей, установка и ключевые правила работы

В репозиториях следует искать обфусцированный или минифицированный код там, где должен находиться читаемый исходный код; инсталляционные скрипты, выполняющие пайплайн curl в оболочку или запрашивающие sudo без видимых на то причин; сетевые вызовы к доменам, не имеющим отношения к проекту; открытые тикеты с упоминанием вредоносного ПО, проблем с цепочкой поставок или взлома учетной записи мейнтейнера; очень новый репозиторий с подозрительно большим количеством звезд; а также лицензию, которая отсутствует или противоречит файлу README. Необходимо отчитываться о том, что именно было проверено, а что проверить не удалось. Если что-то выглядит подозрительно, следует остановиться и дать объяснения, вместо того чтобы продолжать работу.

Шаг 6 — Проверка зависимостей

Изучите файл README и файлы сборки проекта (такие как package.json, Cargo.toml, requirements.txt, PKGBUILD и другие), чтобы определить зависимости времени выполнения. Проверьте, какие из них уже присутствуют в системе.

При использовании Claude Code запускайте проверки напрямую.

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

Дистрибутивный пакет, Flatpak или официальный бинарный релиз всегда предпочтительнее сборки из исходного кода. Сборку из исходного кода следует выполнять только в том случае, если упакованный вариант отсутствует, причем нужно обязательно сообщить пользователю выбранный маршрут и причину такого выбора.

Шаг 7 — Установка

При работе в Claude Code устанавливайте недостающие зависимости и само приложение, демонстрируя каждую команду перед ее запуском. Запрещается выполнять деструктивные команды без предварительного подтверждения.

В веб-приложении передайте точные команды, готовые для копирования и вставки, под конкретный дистрибутив пользователя, а также предложите графическую альтернативу (GUI), если таковая существует.

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

Правила и создание навыка

Категорически запрещается выдумывать URL-адрес репозитория, количество звезд или скриншот. Абсолютно каждое число в галерее поступает из живого ответа API. Никогда не утверждайте, что приложение прошло аудит безопасности. Всегда отдавайте предпочтение проектам с реальной лицензией, а не нелицензированным дампам кода. Если лучшим инструментом для работы не является открытое ПО, прямо заявляйте об этом, вместо того чтобы рекомендовать слабое FOSS-решение исключительно ради соответствия заданию.

Создание навыка израсходует значительную часть ваших токенов. Автор находился на тарифном плане Pro за 20 долларов, и это поглотило 80% лимита его сеанса. Тем не менее, это единоразовая процедура, которая гарантирует, что каждый будущий поиск приложений будет оптимизирован для получения наилучших результатов и меньшего расхода токенов.

Перед созданием данного навыка обязательно активируйте навык Skill-Creator для достижения наилучших результатов. Также настоятельно рекомендуется использовать модель Opus 5 или даже Fable 5 для создания этого навыка, чтобы получить самую качественную и детальную версию из возможных. После этого для запуска навыка можно будет использовать модель Sonnet.

Делаем техническую сторону более доступной

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

К счастью, языковые модели, такие как Claude, эффективно решили эту проблему. Они делают технические аспекты доступными, объясняя, что представляет собой проект, сообщая, соответствует ли он вашим потребностям, и пошагово проводя вас через процесс его реального запуска в вашей системе.