Как мы проверяем проект Формально проект проходит простую (smoke) проверку: тест-харнесс в контейнере убеждается, что в репозитории есть ключевые файлы инструмента — скиллы extract-price и tracker , файл правил KNOWLEDGE.md, helper send.py и README.md. Логика трекера живёт в Claude-скиллах, поэтому глубокой автоматической проверки кода нет.
Главный целевой критерий: инструмент собран в подходе вайбкодинга — в идеале весь код и скиллы написаны с помощью агента, а трекер реально проходит полный цикл: цены → сохранение прогона → сравнение → Telegram.
Статус проверки можно посмотреть в репозитории GitHub. Вывод проверки находится во вкладке Actions в workflow hexlet-check .
Подробнее об автоматической проверке можно почитать здесь.
Что должно работать В проекте должен корректно отрабатывать полный цикл трекера:
Извлечение цены: скилл extract-price по одному URL возвращает объект контракта { regular_price, sale_price, has_credit } (а не текст в свободной форме), нормализует число и отдаёт null при ошибке. Сбор таблицы: скилл tracker за один запуск обходит весь зашитый список URL, вызывает extract-price для каждого и собирает единую таблицу прогона. Сохранение прогонов: свежий прогон сохраняется в отдельный приватный репозиторий tracker-data как файл YYYY-MM- DD.json через GitHub MCP. Сравнение с прошлым: tracker читает предыдущий прогон из tracker-data , считает diff и оставляет только значимые изменения по правилам из KNOWLEDGE.md. Доставка в Telegram: значимые изменения приходят отдельным сообщением; если изменений нет — корректное «Значимых изменений цен нет».
Требования к оформлению Ожидаемая структура репозитория проекта:
.claude/
├── skills/
│ ├── extract-price/SKILL.md
│ └── tracker/SKILL.md
├── agents/
│ └── tg-summary.md (опционально)
├── KNOWLEDGE.md
├── send.py
└── .env (в .gitignore)
tracker-data/ отдельный приватный репозиторий
└── YYYY-MM-DD.json один прогон в деньСкиллы лежат в .claude/skills/, у каждого заполнены поля name и description . Есть файл KNOWLEDGE.md с правилами значимости изменений (порог цены, появление/исчезновение скидки, изменение рассрочки, состав списка). Есть helper send.py — только стандартная библиотека Python, без внешних зависимостей; токен и chat id берутся из переменных окружения или из .env. Прогоны хранятся в отдельном приватном репозитории tracker-data , а не в репозитории со скиллами. Опционально: сабагент tg-summary на дешёвой модели Haiku для оформления текста сводки.
Что проверить самому Автопроверка тривиальная, поэтому перед сдачей пройдитесь по проекту сами:
Нет секретов в репозитории. Токен бота ( TELEGRAM_BOT_TOKEN ) и chat id ( TELEGRAM_CHAT_ID ) лежат только в .env (он добавлен в .gitignore) или в Secrets окружения — и нигде не зашиты в SKILL.md, send.py или README.md. Проверьте историю коммитов: токен не должен был попадать в репозиторий ни разу. Если попал — отзовите его в @BotFather командой /revoke и заведите новый. Данные прогонов — отдельно. Файлы YYYY-MM-DD.json с ценами лежат в приватном tracker-data , а не в основном репозитории со скиллами. Личное не светится. Chat id, личные ссылки и аккаунты не оставлены в скиллах и README.md.
Контракт цены соблюдён. На реальных страницах extract-price возвращает именно объект { regular_price, sale_price, has_credit } . Полный цикл проверен вживую хотя бы дважды (чтобы появился diff): прогон сохранился в tracker-data , а в Telegram пришла сводка значимых изменений.
Что дальше После того как трекер заработал, его можно развивать как продукт.
Больше ниш и списков: несколько наборов товаров и отдельные tracker -скиллы под разные категории. Запуск по расписанию: автоматический прогон по графику (cron / Routines), чтобы сводки приходили без ручного запуска. Другие каналы доставки: кроме Telegram — email, Slack, push-уведомления. Аналитика динамики: графики изменения цен по накопленной истории прогонов в tracker-data . Умные правила: пороги под конкретный товар, «цель по цене» и оповещение при её достижении.