Ви перестаєте бути людиною, яка переносить інформацію з інструмента в інструмент. Повідомлення, мітинги й помилки потрапляють у Notion, отримують статус “чия черга” і повертаються до вас як підготовки, звіти й драфти. Останній крок лишається за вами: вирішити й надіслати.
Що де лежить, у 5 шарах
Джерела
Чати, пошта, календар, транскрипти мітингів, трекер, моніторинг помилок, логи і репозиторії. Через MCP-конектори (офіційний спосіб підключити Claude до Slack, Notion, Jira та інших інструментів) і локальні файли на Маку.
Хаб
Notion Control Tower: 11 баз, де кожен запис привʼязаний до проєкту й workspace (у Notion такі звʼязки називаються relations). Кожен запис знає свій проєкт, тож його можна фільтрувати, повʼязувати і шукати.
Мозок
Claude Cowork з глобальними інструкціями, файлами проєктів і бібліотекою скілів (скіл це записана інструкція для окремої рутинної роботи). Одна сесія Claude читає файл проєкту, Notion і ваші джерела разом.
Автопілот
Заплановані задачі на Маку і в хмарі: короткі промпти, що викликають скіл для названого проєкту і зберігають результат.
Другий агент
Gemini як стратег і рецензент над тією ж памʼяттю в Notion. Корисно, коли накопичилась історія, але не обовʼязково.
Над усім цим людина: пріоритети, рішення, клієнт, арбітраж між агентами.
Від повідомлення до вашого рішення
ЗБІР БУФЕР СИНТЕЗ ПАМʼЯТЬ РІШЕННЯ
чати ─────┐
пошта ────┼──▶ Threads ──┐
календар ─┘ ├──▶ prep-скіли ───────▶ Reports ──┐
мітинги ────▶ Meetings ──┤ inbox-responder ──▶ драфти ├──▶ ви: надіслати,
трекер ───────────────────┤ topic-manager ────▶ Topics │ вирішити,
помилки, логи ────────────┤ risk-register ────▶ Risks │ записати
репозиторії ──────────────┘ тижневі, місячні ─▶ Reports ──┘
конфіг проєкту керує кожним крокомКожен результат потрапляє в базу Reports з типом, скілом, датою і проєктом. Локальні копії лише дублікат. З часом Control Tower стає повним архівом усього, що згенерувала система, і в ньому можна шукати.
Короткий файл, який знає ваш проєкт
Конфіг (від “конфігурація”) і є цим файлом: markdown-файл у папці projects/, по 1 на проєкт. У ньому те, що правда про проєкт саме зараз, з датами “станом на”: матриця доступів, команда (разом із колишніми учасниками і датами), канали, трекер і режим доступу до нього, ритм мітингів, правила деплою, Notion ID, локальні шляхи, культурний профіль команди клієнта і журнал змін, який лише доповнюється.
Хтось пішов з команди чи клієнт забрав доступ? Правите рядок у файлі, і з наступного запуску всі підготовки, звіти й драфти працюють з новою реальністю. Ось скорочене демо:
# Orbit SaaS Launch status: active team: pm: Alex devs: [Mira, Tomas, Lena] slack: channels: [orbit-dev, orbit-client] task_tracker: type: jira api_access: false fallback_source: mail_buffer meetings: internal_sync: Mon/Wed/Fri 12:00 client_status: Thu 16:00 # as of 2026-10-11
Кожен спільний скіл починається з однакового Кроку 0:
- Визначити проєкт із запиту. Не названо? Спитати.
- Прочитати
projects/<slug>.md(slug це коротка назва проєкту, наприкладorbit). - Усі значення виду
{config.xxx}брати звідти. - Якщо задача стосується репозиторіїв, скоупу чи звітності, спершу прочитати матрицю доступів і статус залученості.
Єдиний рядок конфігу змінює 10 скілів. Позначте в моніторингу помилок “у скоупі 1 сервіс, решта належить клієнту”, і без жодної правки скілів скан стабільності перевіряє 1 сервіс замість 7, звіт клієнту перестає згадувати компоненти клієнта, а реєстр ризиків не створює на них ризиків.
Спільні скіли і скіли під конкретний проєкт
Більшість скілів працює для будь-якого проєкту (у документації це рушії). Кілька написано під стек конкретного клієнта (адаптери). Скіл без префікса проєкту (weekly-overview, slack-collector) це рушій: читає файли проєктів і працює для будь-якого проєкту. Скіл із префіксом (orbit-debug) це адаптер під стек цього клієнта, для іншого проєкту він не спрацює.
Фреймворк не вдає, що абстрагує всі трекери світу. Універсальне ядро (Notion-хаб, задачі, поштовий конвеєр, ритм, конфіги, рушії) це приблизно 80%. Решта це адаптери під проєкт, і в аутсорсі це норма. Адаптер стає рушієм лише тоді, коли той самий сценарій повторився на другому проєкті.
Коли клієнт не дає доступу до API
Клієнти працюють у своїх трекерах, а їхня безпека часто не видає токенів агентам. Конфіг фіксує це прямо: task_tracker.api_access: false плюс fallback_source. Рушії не падають, а переходять на доступне (поштовий буфер, action items з мітингів, ручний експорт у папці проєкту) і пишуть у звіті дату останнього експорту.
Межа проведена чітко. Деградація дозволена для похідних даних: статус тікета чи метрику можна перерахувати завтра. Для первинних даних вона заборонена: повідомлення чи мітинг, не записані сьогодні, зникли назавжди. Тому колектор приймається, лише якщо він повний.
3 ситуації від початку до кінця
Повідомлення клієнта стає тікетом
Ранковий колектор забирає вчорашній чат у Threads зі статусом. Поштовий колектор робить те саме для листів. inbox-responder пише драфт відповіді з контекстом із трекера і моніторингу помилок. Ви відкриваєте Control Tower, правите і надсилаєте драфт або коротким реченням перетворюєте тред на тікет.
Клієнтський мітинг, до якого не треба було готуватись
Десь за 55 хвилин до нього client-meeting-prep пише підготовку в Reports: тиждень у трекері, відкриті треди, ризики, питання з минулого разу. Після дзвінка ви кидаєте посилання на мітинг у чат і отримуєте двомовний звіт з рішеннями й action items на тій самій сторінці. У понеділок скіли тем і тижневого огляду його підхоплюють.
За тиждень назбирались помилки
Щотижневий скан стабільності (у налаштуваннях автора в ніч на пʼятницю) читає невирішені помилки і тиждень логів, вибирає топ-3 з трейсами, пише звіт і заводить тікети на нові дефекти. Зранку звіт і тікети вже чекають, а підготовка до пʼятничного ревʼю їх містить.