Ви наперед знаєте, що він робитиме, а чого ні, тож можете довіряти звіту, не перевіряючи все наново. Більшість правил зʼявились тому, що колись щось пішло не так на реальному проєкті: загублений клієнтський тред, скіли, що застаріли після зміни команди, звіт, який виглядав повним, а не був.
На що можна розраховувати
- Рутина працює без людини. Збір, підготовки, огляди, скани, звіти, гігієна борди, метрики, ризики і настрій клієнта йдуть за розкладом і лягають туди, куди ви дивитесь зранку.
- Увесь контекст проєкту в одному місці. Не “десь є”, а в структурованих базах, де кожен запис привʼязаний до свого проєкту.
- Єдина правда про стан проєкту. Конфіг (короткий файл на кожен проєкт) це єдине джерело правди. Скіли (записані інструкції, за якими працює Claude) читають його, а не тримають факти в собі.
- Нові проєкти без переписування ядра. Новий конфіг, сторінки в Notion, розклад. Спільні скіли підхоплюють його навіть без API трекера.
- Зроблено так, щоб передати. Усе, що стосується конкретного проєкту, лежить у конфігу, тож інший ПМ може підняти власну копію. Перша передача колезі ще попереду.
Чого він не обіцяє
- Не замінює ПМа. Знімає рутину, а не судження. Пріоритети, складні розмови з клієнтом і люди лишаються за вами.
- Не гарантує правильності без перевірки. Кожен звіт це драфт з посиланнями на джерела.
- Не працює без дисципліни. Конфіг, не оновлений у день зміни стану, за тиждень робить скіли неправими.
- Не дає кожному проєкту однакової глибини. Повний доступ до API і доступ лише через браузер отримують те саме ядро, але різну автоматизацію.
13 принципів
| # | Принцип | Одним рядком |
|---|---|---|
| 1 | Claude Cowork у центрі | Єдиний агент з повним контекстом кожного проєкту |
| 2 | Notion як хаб, а не сховище файлів | Бази, повʼязані між собою, тож проєкти живуть разом і не змішуються |
| 3 | Конфіг перемагає | Він важливіший за будь-який скіл, звіт чи старий документ. Факти мають дату “станом на” |
| 4 | Ніколи не вгадуй проєкт | Проєкт не названо, скіл питає |
| 5 | Скіли це записані інструкції | Markdown з тригерами, кроками, форматом і місцем збереження, народжений з рутини |
| 6 | Рушії окремо від фактів проєкту | Без префікса це рушій (працює для будь-якого проєкту). З префіксом це скіл під конкретний проєкт |
| 7 | Результат завжди десь записаний | Кожен звіт лягає в базу Reports |
| 8 | Звичайна мова | “Підготуй мене до дейлі” досить, 2 мовами |
| 9 | Починай з малого | Спершу 1 скіл, потім наступний, коли перший приніс користь |
| 10 | Повний контекст і знання його меж | Збирай усе, до чого є доступ, і кажи, чого бракує |
| 11 | 80% ядра і 20% адаптерів | Адаптери це скіли під стек конкретного клієнта. Не намагайся абстрагувати всі трекери світу |
| 12 | Виживати без API клієнта | Зафіксуй режим доступу, деградуй гідно |
| 13 | Памʼять має дисципліну | У кожного факту єдине місце. Дублювання означає розсинхрон |
Небезпечно не те, що якихось даних немає. Небезпечно, коли звіт виглядає повним, а він ні.
Чого навчив рік щоденної роботи
- Починай з малого, ітеруй. Автоматизувати все одразу означає 10 звітів, яким ніхто не вірить.
- Відокрем рушії від фактів проєкту. Коли команда скоротилась, а половина репозиторіїв пішла клієнту, довелось переписувати десятки скілів, що “знали” стару реальність. Коли факти переїхали в конфіг, зміна стану стала правкою в єдиному файлі.
- Скіл народжується з рутини. Ловіть момент “я знову питаю те саме”.
- Перевірка важливіша за генерацію. Кожен звіт автопілота це драфт з джерелами.
- Культура клієнта це дані. Без культурного калібрування аналіз настрою безглуздий.
- Повнота не міняється на зручність. Частковий збір гірший за жоден: система виглядає повною, а звіти стоять на дірявій вибірці.
- Внутрішній канал ніколи не йде клієнту, навіть переказом.
- Мітка часу не фільтр. Черга визначається тим, де лежить запис, тож пізні дані не зникають тихо.
Помилки, які все ламають
| Антипатерн | Замість цього |
|---|---|
| Факт проєкту всередині скіла | Покласти в конфіг і посилатися |
| Скіл тихо бере проєкт за замовчуванням | Спитати |
| Рушій падає, бо в трекера немає API | Зафіксувати режим доступу, fallback, дата експорту |
| Будувати рушій з першого адаптера | Тримати адаптер, доки сценарій не повториться на другому проєкті |
| Ваші задачі розкидані по трекерах клієнтів | Усе в спільному Tasks Tracker |
| Звіт ніде не збережено | Report Storage обовʼязковий |
| Промпт розкладу переказує скіл | Посилатися на скіл, задавати лише проєкт, період і режим |
| Автопілот до 3 ручних запусків | Спершу заробити довіру руками |
| Автоматична відправка клієнту | Драфт, потім людина |
| Видалити колишнього учасника з конфігу | Перенести в колишні учасники, з датою |
Безпека і приватність
- Жодних секретів у скілах, конфігах чи репозиторіях. Лише назва змінної. Значення живуть у локальному файлі секретів, читаються в рантаймі і ніколи не друкуються.
- Клієнтські чати й пошта йдуть лише через ваші акаунти. Claude у хмарі Anthropic читає чати, пошту й нотатки мітингів, які ви підключили, через конектори, у які ви увійшли самі, щоб писати драфти і звіти. Результати лягають у ваш власний Notion. Звук дзвінків розпізнається на вашому Маку, і використовується лише текстовий транскрипт. Більше нічого не додається, якщо ви не вмикаєте опційного другого агента. Перш ніж підключати клієнтський канал, перевірте, чи контракт з клієнтом дозволяє AI-інструменти. Як Anthropic поводиться з даними, дивіться в політиці приватності Anthropic. Звіти про настрій клієнта позначені як внутрішні: тримайте їх у закритій базі або на диску, бо мітка не завадить комусь поширити сторінку.
- Контекст клієнта внутрішній. Транскрипти, цитати, імена і звіти про настрій ніколи не йдуть клієнту. Зовнішні звіти використовують ролі замість людей.
- Права агента вузькі: правило 5 хвилин. Без вашого підтвердження агент пише лише туди, де результат можна скасувати за 5 хвилин: сторінка Notion, драфт, коментар у власному треді, тікет у власному проєкті трекера. Усе, що так швидко не скасуєш (повідомлення клієнту, зміна на борді клієнта, продакшен, видалення), чекає на вас.