Бот Hermes как менеджер: я и подрядчик пишем одному боту
Содержание
Я нанял редактора вычитывать мою открытую книгу book.vibecoding.phd. Его зовут Свят. Работаем мы с ним через одного Telegram-бота на Hermes. Свят пишет боту, я пишу тому же боту, и бот работает у нас менеджером проекта.
Свят пишет боту обычными словами. GitHub (сервис, где лежит текст книги и вся история правок) ему не нужен, как и знать, как собирается книга. Я не пересылаю ему файлы и не считаю часы. Правка Свята доходит до меня готовым pull request со скриншотом главы, и мне остаётся решить одно: влить или нет.
Pull request (PR) это заявка на правку. Изменения лежат в отдельной ветке, то есть в копии текста рядом с основной. Их видно построчно, и в основной текст они попадают, только когда владелец нажмёт «влить».
Что такое менеджер-бот, простыми словами
Hermes это агент от Nous Research, который живёт на сервере и разговаривает в Telegram. У него есть память, скиллы (файлы с инструкциями, что и как делать) и доступ к инструментам. Модель, то есть нейросеть, которая думает за бота, подключается любая. У меня это Claude Opus.
Обычно такой бот работает на одного человека. В этой работе нас двое, и роли у нас разные:
- я владелец проекта: ставлю задачи, меняю правила, вливаю правки;
- Свят исполнитель: берёт задачу, правит главу, смотрит результат;
- бот менеджер: раздаёт задачи, превращает правки в pull request, зовёт меня, когда нужно решение, и считает время.
Два человека, один бот посередине. Правки в книгу вносит только бот, вливаю только я.
Как правка Свята доходит до меня
Задачи Свята лежат в GitHub с меткой «редактура», по одной на главу. В GitHub задача называется issue. Сейчас там восемь глав части «Основы». Свят их не видит в GitHub, он пишет боту:
Бот отвечает списком: название главы, ссылка на неё и статус, «не начата» или «PR ждёт вливания». Номеров задач и слова «issue» в ответе нет. Это моё правило: подрядчику не нужен жаргон GitHub.
Дальше Свят правит главу. Первую главу, «Сессия с агентом», он вычитал у себя в документе. Агент перенёс правки в книгу одним PR: два заголовка стали понятнее, длинные абзацы разбиты, в определениях появились тире. 11 строк добавлено, 7 убрано.
В описании PR агент сам написал, что поменял при переносе от себя. Короткие тире стали длинными. Команда /compact в документе развалилась на два куска, а в книге осталась одной. И отдельной строкой для меня: в остальных главах тире почти нет, а здесь это решение Свята, перенесено как есть. Тестовая ссылка на превью, собранную копию книги с правкой, в тот раз не открылась, и агент так и написал в PR вместо того, чтобы промолчать. Я прочитал, влил, глава на сайте.
Путь одной правки от «мои задачи» до главы на сайте.
Как это устроено изнутри
Внутри бот это папка с файлами. Главный файл, SOUL.md, говорит боту, кто он: менеджер книги. Остальное разложено по скиллам:
| Скилл | Что делает |
|---|---|
manager |
заводит задачи в GitHub и пишет в них ход работы |
book-request |
ведёт запрос человека из допуска: уточнить, сделать PR, позвать меня |
book-chapter |
правит текст глав и сборку книги |
book-time |
считает время людей и агента за день |
book-agent |
держит мои решения: кто в допуске, какая модель, кто владелец бота |
Самый важный из них book-request. Это четыре шага на каждую просьбу Свята:
- Уточнить. Просьба ясна, бот делает сразу. Неясна, задаёт от одного до трёх коротких вопросов одним сообщением.
- Сделать PR. Ветка
book/<название>, скриншот собранной страницы в описании. В основную ветку бот не пишет. - Дать Святу тестовую ссылку на собранную книгу из этого PR, проверенную до отправки. Ссылка не открылась, Свят получает скриншот.
- Написать мне в личку: кто просил, что сделано, ссылка на PR. Святу ответить, что PR ждёт меня.
Шаг 4 и есть менеджерская работа. Свят не ждёт меня в чате и не пишет мне «посмотри». Бот сам приносит мне готовое к решению.
Я пишу тому же боту
Со мной бот разговаривает по-другому. Он узнаёт меня по списку допуска (кому можно писать боту), и мои сообщения идут мимо book-request. Я ставлю задачи, меняю правила, спрашиваю, сколько ушло времени.
Каждое моё правило лежит в скилле с датой, а в book-request ещё и с пометкой «слово founder’а». Список задач Свята, например, появился 1 ноября, и в book-request он записан так:
serejaris/corp-book с меткой редактура. На «мои задачи», «что делать», «что дальше» и в начале нового разговора без конкретной просьбы прислать этот список.Через месяц я вижу, откуда взялось правило, и могу его снять.
Допуск, выкладку и лимиты меняю только я. Это записано в SOUL.md, и Свят попросить бота об этом не может.
Учёт времени без таймера
Свят работает почасово, а таймтрекера у нас нет. Время снимает сам бот. Раз в сутки по расписанию он запускает скрипт, который читает базу разговоров Hermes (сообщения и расход модели по каждой сессии) и сохраняет отчёт за вчера в репозиторий книги, папку проекта в GitHub.
В отчёте три таблицы:
- люди с агентом: сколько минут, сколько сообщений и в какие промежутки каждый говорил с ботом;
- агент: сколько минут он работал в разговоре и сколько сам по расписанию;
- модель: сколько запросов ушло и сколько это стоит по прайсу, по оценке самого Hermes.
В отчёте только минуты, ставок и денег там нет. Цифры руками не правят. Спорный блок обсуждаем комментарием в задаче дня со ссылкой на отчёт.
Что я бы сделал так же с первого дня
Список задач подрядчика держать в GitHub с одной меткой. Бот читает её одной командой, а я вижу то же самое, что видит Свят.
Запретить боту основную ветку. Каждая правка через PR, вливает владелец. Тогда подрядчика можно пускать к боту без страха за проект.
Попросить бота в описании PR писать, что он поменял от себя. Перенос правок из документа в код всегда что-то трогает, и эту строку я читаю первой.
Похожие штуки собираю в Personal Corp, подробнее.