Спільна робота Claude Code через GitHub Issue: два агенти на різних комп'ютерах
Коли програму треба налагодити на чужому комп'ютері, ви стаєте кур'єром між двома терміналами. Є нудне і надійне рішення: дати агентам спільне місце для листування.
Типова ситуація: ви зробили з Claude Code невелику програму для свого бізнесу, і її треба встановити на комп'ютер бухгалтера, партнера чи підрядника. У вас Mac, у нього Windows. У кожного свій Claude Code і своя підписка, і сесії одна одну не бачать. Щось не запускається, і починається найгірша частина роботи.
Пів години кур'єрської роботи
Ви копіюєте логи з чужого термінала собі, свої відповіді назад. Логи приходять обрізаними або переказаними, і лагодити за ними нічого: половина помилки завжди залишається за краєм виділення. Людина на тому боці не розробник, вона не знає, що саме важливо. Ви втрачаєте час, вона втрачає терпіння.
Рішення: спільна скринька для агентів
Рішення виявилось нудним і надійним:
- Створити спільний приватний репозиторій на GitHub.
- Дати другій стороні права на запис.
- Відкрити одне issue, а в його тексті описати протокол спілкування.
Протокол простий: пишемо зрозумілою мовою і пояснюємо, що робимо; підписуємося іменем; логи кладемо повністю, а не переказом; ключі, паролі і персональні дані не пишемо взагалі.
Далі агенти спілкуються самі через консольний клієнт GitHub:
gh issue comment 1 --body "Запустив установку, повний лог нижче..."
gh issue view 1 --comments
Кожен агент на своїй машині отримує команду «перевір issue і відповідай», читає, що написав колега, виконує потрібні дії і відповідає.
Що виявилось найкориснішим
Сповіщення без налаштувань. GitHub надсилає листи про активність в issue. Тож люди з обох боків можуть читати діалог двох агентів прямо в пошті. Агенти працюють між собою годинами, а ви просто спостерігаєте і втручаєтесь, лише коли треба ухвалити рішення.
Якість передачі. Через месенджер такого не носять: повний розбір по кроках, таблиця прогонів, готове технічне завдання на виправлення. А зміни йдуть окремими гілками в репозиторії, тож ви дивитесь на конкретний дифф, а не вірите на слово.
Історія залишається. Через місяць, коли щось зламається знову, весь хід налагодження лежить в одному місці.
Дві чесні застороги
- Агент сам у скриньку не заглядає. Він заходить туди за командою «перевір issue». Тримати його в циклі опитування дорого і не потрібно, поки люди поруч.
- Запрошення в репозиторій треба прийняти. Інакше на всі команди приходить «not found», і це виглядає як поломка, хоча це лише неприйняте запрошення.
Бот-консультант розпитає про процеси і запропонує перший крок. Або напишіть мені напряму, обговоримо вашу задачу.
А якщо обидві сесії на одному комп'ютері
Свіжі версії Claude Code вміють передавати повідомлення між сесіями напряму, але лише між вашими власними сесіями на одній машині. Коли йдеться про двох різних людей, дві підписки і різні комп'ютери, а тим паче Windows на іншому боці, спільний репозиторій залишається найпростішим робочим варіантом.
Як це застосувати в бізнесі
Цей прийом корисний не лише для налагодження. Те саме працює, коли:
- ваш підрядник і ви разом доробляєте внутрішній інструмент;
- агент на сервері і агент на вашому ноутбуці мають координувати роботу;
- потрібно, щоб людина без технічних знань могла простежити, що відбувається.
Головний принцип: агентам потрібне спільне місце з історією, повними даними і чіткими правилами. Месенджер для цього не підходить, а issue в репозиторії підходить ідеально.
Шаблон протоколу для issue
Ось текст, який я кладу в опис issue перед початком роботи. Його достатньо скопіювати і підставити імена:
Правила листування агентів:
1. Пишемо українською, пояснюємо, що робимо і навіщо.
2. Кожен коментар підписуємо: "Агент Ігоря" або "Агент Олени".
3. Логи вставляємо повністю, у блоці коду, без скорочень.
4. Ключі, паролі, токени, персональні дані не пишемо ніколи.
5. Зміни в коді лише окремою гілкою, з описом у коментарі.
6. Якщо потрібне рішення людини, пишемо "ПИТАННЯ ДО ЛЮДИНИ" першим рядком.
Останній пункт особливо корисний: людина може налаштувати фільтр у пошті й отримувати сповіщення лише тоді, коли агенти справді чекають на неї.
Коли це варто впроваджувати в команді
Для разового налагодження спільний репозиторій може здатися надмірним. Але в компанії, де з'являються власні внутрішні інструменти, такі ситуації повторюються щомісяця: новий співробітник встановлює програму, бухгалтер оновлює звіт, підрядник додає інтеграцію. Кожного разу хтось стає кур'єром між терміналами.
Тому я раджу один раз створити приватний репозиторій для внутрішніх інструментів і тримати там і код, і issue з налагодженням. Через пів року це стає базою знань: як встановлювали, що ламалось, як лагодили. Новій людині не треба нічого пояснювати усно, достатньо дати посилання на історію. А агенту на будь-якому комп'ютері достатньо команди «прочитай issue і продовж».
Читайте також: Перенесення контексту Claude у новий чат без втрат, Мозковий штурм з ШІ: 5 агентів замість одного і Claude Code порівняння моделей: ціна задачі, не токена.
Коротко
- Не будьте кур'єром між двома терміналами.
- Приватний репозиторій плюс одне issue з протоколом вирішують задачу.
- Повні логи і зміни гілками замість переказів.
- Сповіщення GitHub дозволяють людям стежити за роботою агентів з пошти.
Потрібно встановити чи налагодити інструмент у команді, де всі на різних комп'ютерах? Напишіть мені в Telegram, допоможу організувати процес.
Що саме я роблю для компаній, описано в розділі послуги, а швидко оцінити вашу ситуацію допоможе бот-консультант ITIVNIK.
Бот-консультант розпитає про процеси і запропонує перший крок. Або напишіть мені напряму, обговоримо вашу задачу.