У новому великому гайді засновник і підприємць Остін Марчезе показує, як із Claude Code зібрати не просто проєкт чи разовий воркфлоу, а постійно працюючу систему, що сама себе живить і покращує. Завершальний акцент цієї системи — правильна організація рутин у десктоп‑додатку Claude Code: автоматичний ingestion даних, окремий контур для системних апдейтів та обов’язковий людський review.
Саме ця «жива» операційна частина часто і відрізняє красиву архітектуру на папері від інструмента, який тихо, але стабільно працює кілька разів на тиждень без участі автора.
Локальні рутини як основа: навіщо тягнути все в десктоп
Ключем до автоматизації Марчезе називає функцію routines у десктопному застосунку Claude Code. Рутини тут — це не просто збережені промпти, а механізм планування завдань, які запускаються за розкладом усередині самого застосунку.
Він одразу фокусується на локальному режимі. Пропонується явно переключити розділ routines у стан «local». Причина проста й дуже практична: локальні рутини мають прямий доступ до файлової системи. Це дозволяє вільно читати, змінювати, створювати файли в межах проєкту, не турбуючись про окрему інфраструктуру чи складні сценарії версіонування.
У такій моделі Claude Code перетворюється на локального оркестратора: саме він за розкладом запускає потрібні скіли, торкається реальних файлів проєкту й акуратно оновлює те, що складає ядро вашої бази знань і системи скілів.
Один orchestration‑скіл для ingestion: мінімум точок лому
Щоб не плодити зайву складність, Марчезе пропонує об’єднати весь регулярний притік даних у єдину точку входу — orchestration‑скіл /data_ingestion.
Цей скіл сам по собі нічого не вигадує: його завдання — послідовно викликати три вже налаштовані утилітарні скіли, які з’являються раніше в системі:
- синхронізація історії сесій Claude (
sync claude sessions), - підвантаження даних з особистої екосистеми (
sync ecosystem data), - обробка зовнішнього curated‑контенту (
sync curated content).
Orchestration‑підхід дозволяє винести всю логіку «як саме ми качаємо і обробляємо нові дані» в окремі дрібні скіли, а рутині дати одну просту команду: запусти /data_ingestion. Якщо в майбутньому зміниться спосіб інтеграції з поштою чи інструментами — оновлюється відповідний скіл, а не вся розкладка.
Після створення /data_ingestion Марчезе налаштовує дві окремі рутини для цього скіла: одна запускається у вівторок, інша — у п’ятницю о 9:00 ранку. Обидві фактично роблять те саме — викликають /data_ingestion, але рознесені в часі, щоб підтримувати стабільний потік свіжих даних.
Він підкреслює один принцип, який варто запам’ятати: будь‑яка рутина має посилатися на скіли, а не дублювати в собі промпти чи деталізовану логіку. Так оновлення відбувається в одному місці — у скілі, — і автоматично підхоплюється всіма рутинами.
Окремий трек для покращень: чому ingestion і зміни системи не змішують
Другий стовп операційної моделі — рутина для покращення системи. Тут у гру вступає скіл /improve_system, який аналізує вже інгестовані дані, пропонує зміни в базі знань, коригує чи доповнює скіли та кладе все це в структурований формат із bucket‑логікою (автоапрув, потребує підпису, потребує додаткового контексту).
Для цього створюється окрема рутина, яка запускає /improve_system наприкінці дня у вівторок і в п’ятницю — після того, як ранішній ingestion уже відпрацював. Таким чином формується чіткий ланцюжок: спочатку нові дані потрапляють у систему, пізніше в той самий день вони стають матеріалом для аналізу та пропозицій щодо покращення.
Принципово важливий момент — ці дві рутини спеціально рознесені. Марчезе пояснює, що сприймає рутини як окремі процеси, і ingestion даних та системні покращення — це дві різні сутності. Коли кожен із них живе в окремій рутині, простіше зрозуміти, що саме зламалося, якщо щось пішло не так: чи провалилося підвантаження даних, чи збій виник на етапі аналізу та змін.
Така декомпозиція важлива ще й з точки зору контролю: можна тимчасово зупинити покращення, не торкаючись регулярного збору даних, або навпаки — відлагоджувати ingestion, зберігаючи відпрацьовану логіку /improve_system.
Людина в лупі: третя рутина як запобіжник від «автоматичного дрейфу»
Третій обов’язковий елемент — рутина human review. Йдеться вже не про код чи промпти, а про звичку й процес для власника системи.
Сенс у тому, що навіть із грамотно побудованими bucket‑ами для змін та напівавтоматичним ухваленням простих апдейтів, критичні рішення в системі мають проходити через людину. Цей human review і є тим рівнем, де перевіряється, що саме буде змінено в скілах, шаблонах чи структурі знань, а що варто відкласти або відхилити.
Марчезе нагадує: у вже налаштованому процесі все зводиться до дуже простої дії — поставити галочки там, де зміни приймаються, і там, де вони відхиляються. Це не вимагає переписування промптів чи глибокого технічного втручання, але зберігає людське судження для важливих рішень.
Для тих, хто схильний ігнорувати такі рутинні огляди, пропонується навіть винести це в окремий допоміжний скіл — умовний /human_improve_system. Його можна використати як «ведучого» в процесі рев’ю або пов’язати зі сповіщеннями в Slack, які нагадуватимуть, якщо ви затягуєте з фідбеком. Логіка проста: якщо людина випадає з циклу, система починає дрейфувати, навіть якщо формально «самооновлюється».
У підсумку всі три рутини формують повноцінний цикл:
дані регулярно потрапляють у проєкт;
система періодично аналізує цей масив і пропонує покращення;
людина в зручному форматі затверджує або відхиляє суттєві зміни.
Висновок: самовдосконалення працює лише тоді, коли ним хтось керує
Побудувати складну структуру скілів і знань у Claude Code — половина справи. Щоб ця система перестала бути разовим експериментом і перетворилася на «двигун», який реально працює щотижня, потрібна чітка операційна рамка: локальні рутини, єдиний orchestration для ingestion, окремий трек для покращень і формалізована участь людини.
Марчезе наполягає: саме користувач «веде» систему. Автоматизація бере на себе механіку, але не відповідає за напрямок. Розділення процесів на окремі рутини, посилання лише на скіли й обов’язковий human review створюють баланс між комфортом повної автоматизації та необхідністю зберігати контроль над тим, як саме змінюється ваш інструмент.
Джерело
YouTube: How to Build A Self-Improving System with Claude Code