1.1 Ласкаво просимо до курсу
Модуль 1 · Мислення циклами- Зрозуміти, що таке цикл (loop) у Claude Code і навіщо його «проєктувати», а не просто промптити
- Освоїти чотири типи циклів: turn-based, /goal, /loop і /schedule, проактивні рутини
- Навчитися масштабувати роботу через dynamic workflows — від десятків до сотень агентів
- Розрізняти способи паралельної роботи й тримати якість та витрату токенів під контролем
Від промптингу до проєктування циклів
Більшість користувачів Claude Code працюють так: написав промпт → почекав → перевірив → написав наступний. Це нормально й часто достатньо. Але коли задачі стають більшими або повторюваними, ти перетворюєшся на вузьке місце: агент чекає на тебе після кожного ходу.
Промптинг — це коли ти водій: крутиш кермо на кожному повороті, тиснеш газ, гальмуєш. Проєктування циклів — це коли ти стаєш інженером маршруту: ти задаєш пункт призначення й правила («доїдь, доки бак не порожній», «зупинись, коли прибудеш»), а машина їде сама. Твоя робота зміщується з «керувати кожним рухом» на «визначити, що таке готово».
Що ти навчишся будувати
- Цикл, що сам себе перевіряє перед тим, як сказати «готово» (skills-верифікація)
- Цикл, що ітерує до вимірюваної цілі — «Lighthouse ≥ 90 або зупинись після 5 спроб»
- Цикл, що прокидається за розкладом і реагує на PR чи нові баг-репорти
- Оркестрацію десятків агентів, що паралельно правлять 500 файлів і перевіряють одне одного
Структура курсу
| Модуль | Про що | Уроки |
|---|---|---|
| M1: Мислення циклами | Що таке цикл, 4 ознаки, агентний цикл | 3 |
| M2: Ручне керування | Turn-based, skills-верифікація, /goal | 4 |
| M3: Автоматичні цикли | /loop, /schedule, рутини | 3 |
| M4: Dynamic Workflows | Оркестрація агентів у масштабі | 3 |
| M5: Паралельність та якість | Паралельні агенти, якість, токени | 3 |
Передумови
- Claude Code — базовий рівень: писати промпти, дозволяти інструменти
- Термінал — запускати команди, розуміти вивід
- Загальне розуміння агента — що LLM може читати файли, редагувати код, ганяти тести
Не потрібно знати наперед про /goal чи workflows — почнемо з нуля.
Часті запитання
1.2 Що таке цикл (loop)
Модуль 1 · Мислення циклами- Дати точне визначення циклу в Claude Code
- Побачити чотири ознаки, за якими цикли розрізняють
- Зрозуміти головне правило: не ускладнюй без потреби
Зараз багато говорять про «проєктування циклів» замість промптингу, і якщо пошукати в мережі, знайдеш десяток різних відповідей. На команді Claude Code визначення просте й чітке:
Цикл — це коли агент повторює цикли роботи, доки не виконана умова зупинки.
Цикл схожий на пральну машину. Її треба запустити (натиснути кнопку). Далі вона крутить програму — набирає воду, пере, полоще, віджимає, знову й знову. І зупиняється за умовою — коли програма завершена. Ти не стоїш над нею й не кажеш «а тепер полощи». Ти лише обрав програму й натиснув старт. Проєктувати цикл — це обрати правильну «програму» для задачі.
Чотири ознаки, за якими розрізняють цикли
- Як запускається — промптом, часом чи подією.
- Як зупиняється — сам Claude, окрема модель-оцінювач, чи ти.
- Який примітив Claude Code задіяно (turn, /goal, /loop, рутина, workflow).
- Який тип задачі для нього доречний.
Не всі задачі потребують складних циклів. Починай з найпростішого рішення і бери ці патерни вибірково. Складний цикл там, де вистачило б одного промпта, — це змарновані токени й час.
Чотири типи — оглядово
| Тип | Запуск | Зупинка |
|---|---|---|
| Turn-based | Твій промпт | Claude вважає задачу виконаною |
| /goal | Твій промпт | Ціль досягнута або ліміт ходів |
| /loop · /schedule | Інтервал часу | Ти скасовуєш або робота завершена |
| Проактивний | Подія або розклад | Кожна задача — за своєю ціллю |
1. Як команда Claude Code визначає «цикл»?
2. Що НЕ є ознакою, за якою розрізняють цикли?
3. Яке головне правило вибору циклу?
1.3 Агентний цикл
Модуль 1 · Мислення циклами- Побачити, що кожен твій промпт — це вже цикл
- Розібрати кроки агентного циклу
Найпростіший цикл ти запускаєш щоразу, коли пишеш промпт. Ти керуєш кожним ходом вручну, а всередині одного ходу Claude робить повний міні-цикл. Це називають агентним циклом.
Дай кухарю замовлення — і він не робить один рух. Він читає рецепт (збирає контекст), готує (діє), куштує (перевіряє), досолює (повторює за потреби) і подає страву (відповідає). Ти сказав «що», а внутрішній цикл «як» він прокрутив сам.
Кроки агентного циклу
Наприклад, ти просиш зробити кнопку «лайк». Claude:
У turn-based циклі перевірку тримаєш ти. Це гнучко для коротких задач, але саме тут ти й стаєш вузьким місцем. У наступному модулі побачимо, як віддати частину перевірки самому агенту — через skills — і як віддати саме рішення «коли зупинитись» через /goal.
2.1 Turn-based цикл
Модуль 2 · Ручне керування циклом| Запуск | Твій промпт. |
| Зупинка | Claude вважає, що виконав задачу, або потребує ще контексту. |
| Для чого | Коротші задачі поза регулярним процесом чи розкладом. |
| Керування | Конкретні промпти + skills для верифікації, щоб зменшити кількість ходів. |
Кожен промпт запускає ручний цикл, де ти керуєш кожним ходом. Claude збирає контекст, діє, перевіряє свою роботу, повторює за потреби й відповідає. Ти читаєш результат і пишеш наступний хід.
Коли брати turn-based
- Задача коротка й одноразова («додай кнопку», «поясни цей файл»)
- Ти досліджуєш або ще вирішуєш, як має виглядати результат
- Тобі важливо бачити кожен крок і скеровувати
Які з цих задач найкраще лягають на turn-based цикл (а не на автоматичний)?
- «Розберися, чому падає цей тест, і поясни мені»
- «Щоранку підсумовуй нові повідомлення в каналі»
- «Перейменуй змінну в цьому файлі»
1 і 3 — короткі, одноразові, ти хочеш бачити результат → turn-based. 2 — повторювана робота за розкладом → це вже time-based (/loop чи /schedule), про це в модулі 3.
2.2 Верифікація через skills
Модуль 2 · Ручне керування циклом- Зрозуміти, як віддати частину перевірки самому агенту
- Написати SKILL.md, що кодує «як виглядає добре»
Крок «перевірки» в turn-based циклі можна підсилити: закодуй свої ручні кроки перевірки як SKILL.md, щоб Claude перевіряв більше сам, від початку до кінця. Додай інструменти чи конектори, щоб він міг бачити, вимірювати й взаємодіяти з результатом.
Уяви, що ти передаєш роботу молодшому колезі й даєш йому свій чекліст код-рев'ю: «відкрий сторінку, клікни кнопку, глянь у консоль, зроби скріншот до/після». Тепер він перевіряє себе твоїми очима, не чекаючи на тебе. Skill — це і є такий чекліст, який агент застосовує сам. Чим кількісніші перевірки (нуль помилок, оцінка ≥ 90), тим легше йому самоперевірятись.
Приклад: skill для перевірки UI-змін
Обери задачу, яку часто перевіряєш вручну (напр. «змінив SQL-запит» або «оновив текст лендінга»). Запиши 3–4 кількісні кроки перевірки, які агент міг би зробити сам.
verify-sql-change: 1) прожени запит на тестовій БД; 2) переконайся, що повертає > 0 рядків і час < 200 мс; 3) порівняй план виконання (EXPLAIN) — немає повного сканування таблиці; 4) прожени наявні тести — 0 фейлів.
2.3 /goal — цикл до умови
Модуль 2 · Ручне керування циклом| Запуск | Ручний промпт у реальному часі. |
| Зупинка | Ціль досягнута АБО досягнуто максимум ходів. |
| Для чого | Задачі з перевіримими критеріями виходу. |
| Керування | Конкретний критерій + явний ліміт: «stop after 5 tries». |
Іноді одного ходу замало. Агенти працюють краще, коли можуть ітерувати. /goal задає умову завершення, і Claude продовжує ітерувати сам — без твого промпта на кожен хід — доки умову не виконано.
Turn-based — це коли ти сам вирішуєш «досить бігти». /goal натягує фінішну стрічку: Claude біжить коло за колом, і щоразу, коли хоче спинитись, суддя (окрема модель-оцінювач) дивиться — стрічку перетнуто? Ні — біжи далі. Так Claude не зупиняється зарано на «начебто достатньо добре».
Приклад
Тут є все: вимірювана ціль (Lighthouse ≥ 90) і запобіжник (не більше 5 спроб). Саме тому детерміновані критерії — кількість пройдених тестів, поріг оцінки — працюють найкраще: судді легко сказати «так» або «ні».
- Міграція модуля на новий API, доки всі виклики компілюються й тести проходять
- Реалізація дизайн-доку, доки не виконані всі критерії приймання
- Розбити великий файл на модулі, доки кожен не стане менше певного розміру
- Пройти чергу помічених задач, доки вона не спорожніє
2.4 Як писати умову для /goal
Модуль 2 · Ручне керування циклом- Зрозуміти, як саме оцінювач судить умову
- Навчитися формулювати умову, яку неможливо «обдурити»
Оцінювач (за замовчуванням модель Haiku) не запускає команди й не читає файли сам. Він судить лише те, що Claude вже вивів у розмову. Тож формулюй умову так, щоб її міг довести сам вивід Claude. «Усі тести в test/auth проходять» працює, бо Claude запускає тести й результат потрапляє в діалог.
Хороша умова має три частини
- Одна вимірювана кінцева умова — результат тесту, код виходу білда, кількість файлів, порожня черга.
- Вказаний спосіб перевірки — як довести: «npm test exits 0» або «git status is clean».
- Обмеження, що не має змінитись — напр. «жоден інший тест-файл не редагується».
/goal без аргументів — статус: умова, скільки триває, скільки ходів оцінено, витрата токенів, остання причина від оцінювача. /goal clear — прибрати активну ціль (аліаси: stop, off, reset, none, cancel). Технічно /goal — обгортка над сесійним Stop-hook. Умова — до 4000 символів.
- Версія. Потрібен Claude Code v2.1.139+.
- Одна ціль на сесію. Задання цілі одразу стартує хід — окремий промпт не потрібен. Індикатор ◎ /goal active показує, скільки вона триває.
- Неінтерактивно. claude -p "/goal ..." проганяє цикл до кінця за один виклик; Ctrl+C — спинити достроково. Працює і в desktop-застосунку, і через Remote Control.
- Спорідненість. /goal — це обгортка над сесійним Stop-hook. Auto mode прибирає дозволи на кожен інструмент; /goal — на кожен хід. Вони доповнюють одне одного. Замість /goal можна написати власний Stop-hook у settings, якщо потрібна кастомна логіка.
- Резюм. Активна ціль відновлюється при --resume/--continue (умова переноситься; лічильник ходів, таймер і базлайн токенів скидаються).
- Оцінювач майже безкоштовний. Токени оцінювача рахуються на малій швидкій моделі й зазвичай мізерні проти основних ходів.
Перепиши на перевірну: «/goal зроби код чистішим».
«/goal split src/app.js so every file is under 200 lines, npm test exits 0, and git diff touches no file outside src/, or stop after 10 turns» — є вимірювана умова (розмір файлів), спосіб перевірки (тести), обмеження (лише src/) і запобіжник.
1. Навіщо кодувати перевірку у SKILL.md?
2. Що робить оцінювач /goal?
3. Яка умова /goal найнадійніша?
3.1 /loop — цикли за часом
Модуль 3 · Автоматичні цикли| Запуск | Заданий інтервал часу. |
| Зупинка | Ти скасовуєш, або робота завершилась (PR змерджено, черга порожня). |
| Для чого | Повторювана робота або взаємодія із зовнішніми системами. |
| Керування | Довші інтервали, або реагуй на події замість часу. |
Частина роботи повторювана: задача та сама, змінюються лише вхідні дані (напр. підсумовувати Slack щоранку). Інша залежить від зовнішніх систем — простий спосіб взаємодіяти: перевіряти на інтервалі й реагувати на зміни (напр. PR, що може отримати рев'ю або зафейлити CI).
/loop — це будильник, що дзвонить щоінтервал і щоразу проганяє той самий промпт. Він працює на твоєму комп'ютері: вимкнеш термінал — і будильник замовкне.
Кожні 5 хвилин Claude перевіряє PR, відповідає на коментарі рев'ю й лагодить CI — доки ти не спиниш або робота не завершиться.
Три режими /loop
Поведінка залежить від того, що ти вказав (потрібен v2.1.72+):
| Що вказано | Приклад | Що відбувається |
|---|---|---|
| Інтервал + промпт | /loop 5m check the deploy | Промпт біжить за фіксованим розкладом |
| Лише промпт | /loop check the deploy | Claude сам обирає інтервал (1 хв–1 год) щоітерації: коротше поки білд/PR активні, довше коли тихо; друкує обраний інтервал і причину |
| Лише інтервал / нічого | /loop | Біжить вбудований maintenance-промпт (або твій loop.md) |
Одиниці інтервалу: s/m/h/d. Можна передати й скіл: /loop 20m /review-pr 1234. Вбудований maintenance-промпт доробляє незавершене, доглядає PR поточної гілки (коментарі рев'ю, червоний CI, конфлікти) і робить прибирання — без незворотних дій, яких транскрипт уже не дозволив.
Файл .claude/loop.md (проєкт) або ~/.claude/loop.md (глобально) замінює вбудований maintenance-промпт на твій. Правки діють з наступної ітерації — можна доточувати, поки цикл біжить. Ігнорується, якщо ти даєш промпт прямо в команді. Понад 25 000 байтів обрізається.
Разові нагадування й керування
Для одноразового — просто природною мовою: remind me at 3pm to push the release branch → Claude ставить одноразову задачу, що видаляє себе після спрацювання. Список/скасування: «what scheduled tasks do I have?», «cancel the deploy check job» (під капотом CronList/CronDelete; до 50 задач на сесію, ID з 8 символів).
- Спинити під час очікування — Esc (у self-paced режимі Claude може завершити цикл і сам, коли задача виконана).
- Задачі спрацьовують лише поки Claude Code запущений і не зайнятий — закрив термінал, і цикл спинився. Можна перевести сесію у фон — /loop переїде у фонову сесію й працюватиме без термінала.
- Немає «наздоганяння»: якщо час минув, поки Claude зайнятий, задача спрацює один раз, коли звільниться, а не за кожен пропуск.
- Рекурентні задачі згасають через 7 днів після створення (останнє спрацювання → самовидалення). Треба довше — створи її заново до згасання, або бери рутини/десктоп-задачі.
3.2 /schedule — рутини в хмарі
Модуль 3 · Автоматичні цикли- Перенести цикл із ноутбука в хмару
- Знати три типи тригерів рутини
/loop живе на твоїй машині. Щоб цикл працював, навіть коли ноутбук закритий, перенеси його в рутину через /schedule. Рутина — це збережена конфігурація (промпт, репозиторії, конектори), що виконується на хмарній інфраструктурі Anthropic.
/loop — це коли ти сам за кермом і не відходиш. Рутина — це автопілот: увімкнув і пішов у справах, літак летить сам. Працює вночі, у вихідні, коли ти спиш.
Три типи тригерів
| Тригер | Запускається, коли… |
|---|---|
| Розклад | Настав час: щогодини, щоночі, щотижня (мін. інтервал — 1 година) |
| API | Хтось шле HTTP POST на ендпоінт рутини з bearer-токеном |
| GitHub | Стається подія в репо: напр. pull_request.opened |
Одна рутина може поєднувати кілька тригерів. Наприклад, рев'ю PR: щоночі + за викликом з деплой-скрипта + на кожен новий PR.
- Догляд за беклогом — щовечора читати нові задачі, розставляти лейбли, призначати власників, писати підсумок у Slack
- Тріаж алертів — моніторинг шле POST на API рутини, вона тягне стектрейс і відкриває чернетку PR з фіксом
- Код-рев'ю на замовлення — GitHub-тригер на pull_request.opened застосовує ваш чекліст рев'ю
Створення
Рутини — у режимі дослідницького прев'ю (research preview): поведінка й ліміти можуть змінюватись. Доступні на Pro/Max/Team/Enterprise з увімкненим Claude Code на вебі. Керувати: claude.ai/code/routines або /schedule list · update · run. Разові запуски не рахуються в денний ліміт рутин.
Три способи розкладу — коли що
Окрім /loop і хмарних рутин, є ще десктоп-задачі (локальні, на твоїй машині). Порівняння:
| Хмара (рутини) | Десктоп-задачі | /loop | |
|---|---|---|---|
| Де працює | Хмара Anthropic | Твоя машина | Твоя машина |
| Треба ввімкнена машина | Ні | Так | Так |
| Треба відкрита сесія | Ні | Ні | Так |
| Локальні файли | Ні (свіжий клон) | Так | Так |
| Мін. інтервал | 1 година | 1 хвилина | 1 хвилина |
Коротко: хмара — надійно без твоєї машини; десктоп — коли потрібні локальні файли/інструменти; /loop — швидкий полінг під час сесії.
- Автономно, без запитів дозволу. Рутина — повноцінна хмарна сесія: сама запускає команди, використовує skills із клонованого репо й конектори. Тому промпт має бути самодостатнім і чітко казати, що робити і що таке успіх.
- Клонує репо щоразу зі стандартної гілки; зміни пише у гілки з префіксом claude/. Пуш у наявні гілки — лише якщо ввімкнути «Allow unrestricted branch pushes».
- Діє від твого імені: коміти й PR несуть твій GitHub-акаунт, повідомлення Slack/Linear — твої конектори. Рутини належать твоєму акаунту й рахуються в денний ліміт.
- GitHub-тригер можна звузити фільтрами PR: автор, заголовок, base/head-гілка, лейбли, draft, merged (оператори equals / contains / matches regex…). Кожна подія = нова сесія.
- Зелений статус ≠ успіх. Він означає лише, що сесія стартувала й вийшла без інфрапомилки — відкрий прогін, щоб перевірити, що Claude реально зробив.
3.3 Проактивні цикли
Модуль 3 · Автоматичні цикли| Запуск | Подія або розклад, без людини в реальному часі. |
| Зупинка | Кожна задача — за своєю ціллю. Сама рутина працює, доки не вимкнеш. |
| Для чого | Повторювані потоки чітко визначеної роботи: баги, тріаж, міграції, оновлення залежностей. |
| Керування | Маршрутизуй рутини на менші/швидші моделі; найпотужнішу лишай для суджень. |
Проактивний цикл — це не окремий примітив, а складання попередніх. Примітиви (turn, /goal, workflows) разом з auto mode збираються в один довготривалий цикл, де людини немає в реальному часі.
- /schedule — рутина, що перевіряє нові репорти
- /goal — що таке «готово» + skills, щоб задокументувати перевірку
- Dynamic workflows — оркеструють агентів, що тріажать, лагодять і рецензують фікс
- Auto mode — щоб рутина не спинялась щоразу питати дозвіл
Обери одну повторювану роботу у своєму проєкті. Випиши: (1) тригер, (2) умову «готово» для однієї одиниці роботи, (3) що робити з кожним елементом.
Оновлення залежностей: (1) тригер — щотижня; (2) готово — «PR відкрито, тести зелені»; (3) для кожної застарілої залежності: підняти версію, прогнати тести, за успіху відкрити PR, інакше позначити як «потребує уваги».
1. Чим /schedule відрізняється від /loop?
2. Який тригер рутини НЕ існує?
3. Проактивний цикл — це…
4.1 Що таке dynamic workflow
Модуль 4 · Dynamic Workflows- Зрозуміти, що таке workflow і чим він відрізняється від субагентів
- Знати, коли задача «переросла» звичайний підхід
Dynamic workflow — це JavaScript-скрипт, що оркеструє субагентів у масштабі. Claude пише скрипт під задачу, а рантайм виконує його у фоні, поки твоя сесія лишається вільною.
Один субагент — це майстер, що робить деталь від початку до кінця. Workflow — це конвеєрна лінія: ти проєктуєш саму лінію (скрипт), а десятки роботів-агентів працюють паралельно на своїх станціях. Ти не стоїш біля кожного — ти читаєш фінальний звіт з кінця конвеєра.
Хто тримає план — і чому це важливо
Із субагентами оркестратор — сам Claude: він щоходу вирішує, кого запустити, і кожен результат осідає в його контексті. У workflow план у коді: цикл, розгалуження й проміжні результати тримає скрипт, тож у контексті Claude лишається лише фінальна відповідь. Це ще й дає повторюваний патерн якості — незалежні агенти можуть адверсарно перевіряти знахідки одне одного перед звітом.
- Аудит усього коду на одну проблему
- Міграція 500 файлів
- Дослідження, де джерела треба звірити одне проти одного
- Складний план, який варто накидати з кількох незалежних кутів
| Субагенти | Workflows | |
|---|---|---|
| Хто вирішує наступний крок | Claude, щоходу | Скрипт |
| Де проміжні результати | У контексті Claude | У змінних скрипта |
| Масштаб | Кілька за хід | Десятки-сотні за прогін |
4.2 Як запустити workflow
Модуль 4 · Dynamic WorkflowsТи не пишеш скрипт сам — Claude пише його за твоїм описом. Є кілька способів попросити:
- Додай ключове слово ultracode у промпт — або попроси звичайними словами «use a workflow»
- Увімкни /effort ultracode — і Claude планує workflow для кожної суттєвої задачі сесії
- Запусти готовий вбудований: /deep-research <питання> — розгортає пошук з кількох боків, крос-чекає джерела й повертає звіт із цитатами
Приклади промптів
Claude Code покаже заплановані фази й спитає дозвіл. Можна переглянути сирий скрипт перед стартом. Прогін іде у фоні — сесія лишається вільною; спостерігати за ним можна через /workflows.
Дозволи. Субагенти workflow завжди працюють у режимі acceptEdits й успадковують твій allowlist, незалежно від режиму сесії. Команди shell/web/MCP поза allowlist можуть перепитати посеред прогону — тож перед довгим прогоном додай потрібні команди в allowlist.
- Версія й доступ. Workflows потребують v2.1.154+, доступні на всіх платних тарифах + API (та Bedrock/Vertex/Foundry); на Pro вмикаються в /config.
- ultracode глибше. /effort ultracode = xhigh-міркування + авто-оркестрація. Один запит може перетворитись на кілька workflow поспіль (зрозуміти код → зробити зміну → перевірити). Діє на всю сесію, скидається з новою; повернутись до звичайного — /effort high.
Напиши промпт для workflow, який перевірить кожен ендпоінт у src/api/ на відсутність rate-limiting і адверсарно звірить кожну знахідку.
«use a workflow to audit every endpoint under src/api/ for missing rate-limiting, one agent per file, then adversarially verify each finding before reporting it»
4.3 Скрипт, ліміти, вартість
Модуль 4 · Dynamic Workflows- Впізнавати форму workflow-скрипта
- Знати ліміти рантайму й як не спалити токени
Скрипт зазвичай не треба редагувати, але корисно впізнавати форму. Два ключові виклики: agent() спавнить одного субагента, pipeline() — по одному на елемент списку.
- До 16 паралельних агентів одночасно (менше на слабких CPU)
- Максимум 1000 агентів на один прогін — запобіжник від нескінченних циклів
- Прогін резюмується в тій самій сесії, якщо ти його спинив (готові агенти віддають кеш, решта біжить наживо)
- Без вводу посеред прогону — паузу дають лише дозволи агентів; для «підпису» між етапами роби кожен етап окремим workflow
- Сам скрипт не має доступу до файлів чи shell — читають, пишуть і запускають команди агенти, а скрипт лише координує їх
Один прогін може з'їсти помітно більше токенів, ніж та сама робота в розмові. Тому спершу проганяй на малому зрізі — одна тека замість усього репо, вузьке питання замість широкого. /workflows показує витрату кожного агента наживо, і будь-якого агента можна спинити. Кожен агент бере модель твоєї сесії, якщо скрипт не спрямує етап на іншу — тож перевір /model перед великим прогоном і проси Claude ставити дешевшу модель на легші етапи. Щоб масштаб був малим за замовчуванням, задай розмір workflow у /config (small <5 / medium <15 / large <50 агентів).
Коли workflow робить те, що треба, збережи його як команду /<назва> для майбутніх сесій: у /workflows обери прогін і натисни s. Два місця збереження: .claude/workflows/ у проєкті (спільне з усіма, хто клонує репо) або ~/.claude/workflows/ вдома (лише для тебе).
Параметри. Збережений workflow приймає вхід через глобальну args — можна передати питання чи список шляхів на виклику: «Run /triage-issues on issues 1024, 1025, 1030». Список передається як структуровані дані.
Скрипт видно. Кожен прогін пише свій скрипт у файл під ~/.claude/projects/ — його можна відкрити, порівняти з попереднім прогоном, відредагувати й перезапустити з відредагованої версії.
1. Де в workflow живуть проміжні результати?
2. Скільки агентів максимум на один прогін?
3. Як безпечно оцінити вартість великого workflow?
5.1 Паралельні агенти — що обрати
Модуль 5 · Паралельність та якість- Розрізняти чотири способи паралельної роботи
- Вибирати за принципом «хто координує і чи торкаються задачі тих самих файлів»
| Підхід | Що дає | Бери, коли |
|---|---|---|
| Субагенти | Воркери в одній сесії: роблять побічну задачу у власному контексті й повертають підсумок | Побічна задача завалила б головну розмову логами/пошуком |
| Agent view (claude agents) research preview | Один екран, щоб запускати й моніторити фонові сесії (кожна автоматично у своєму worktree) | Кілька незалежних задач: віддати й перевіряти статус |
| Agent teams експерим., вимкнені за замовч. | Скоординовані сесії зі спільним списком і повідомленнями, під керівництвом ліда (спілкуються між собою напряму) | Хочеш, щоб Claude розбив проєкт і тримав воркерів у синхроні |
| Dynamic workflows | Скрипт, що ганяє багато агентів і крос-чекає їх | Задача більша за жменю субагентів; треба звірка знахідок |
| Worktrees | Окремий git-checkout на сесію | Задачі торкаються тих самих файлів — ізолюй їх |
claude agents — усі фонові сесії й хто потребує уваги. /tasks — усе фонове поточної сесії. /workflows — прогони workflow, фаза й скільки агентів завершило.
- /batch — skill, що розбиває одну велику зміну на 5–30 субагентів в ізольованих worktree, і кожен відкриває свій PR. Це упаковане використання субагентів + worktrees, не окремий стиль.
- Форк-субагент — субагент, що успадковує весь твій контекст розмови замість починати з чистого. Спосіб спавну, а не окрема поверхня.
- Усі воркери — це сесії Claude. Щоб залучити інший інструмент, відкрий його Claude як MCP-сервер.
- Обережно з токенами. Кілька сесій чи субагентів одночасно множать витрату — звіряй з /usage.
5.2 Якість і токени
Модуль 5 · Паралельність та якістьЯкість виходу циклу залежить не від «розумності» одного ходу, а від системи навколо циклу. І токени треба тримати в межах — інакше масштаб з'їсть бюджет.
- Чистий код у репо — Claude слідує наявним патернам і конвенціям
- Спосіб самоперевірки — закодуй «як виглядає добре» у skills
- Доступні доки — у фреймворків/бібліотек є актуальні best practices
- Другий агент на рев'ю — свіжий контекст менш упереджений (вбудований /code-review або застосунок Code Review for GitHub)
- Кодуй урок у систему — не спиняйся на фіксі одного випадку, покращ систему для всіх майбутніх ітерацій
- Правильний примітив і модель — дрібне не потребує кількох агентів; частина задач — дешевша модель
- Чіткі критерії успіху й зупинки — щоб Claude дійшов до рішення раніше (але не зарано)
- Пілот перед великим прогоном — workflow може спавнити сотні агентів
- Скрипти для детермінованого — запустити скрипт дешевше, ніж щоразу міркувати кроки (напр. PDF-skill везе готовий скрипт заповнення форми, який Claude просто запускає щоразу, а не переписує код)
- Не частіше, ніж треба — інтервал під темп змін того, що стежиш
/usage — розбивка за skills, субагентами й MCP. /goal без аргументів — ходи й токени. /workflows — токени кожного агента (агента можна спинити будь-коли).
5.3 Підсумок і фінальний тест
Модуль 5 · Паралельність та якість| Цикл | Ти віддаєш | Коли брати | Тягнись до |
|---|---|---|---|
| Turn-based | Перевірку | Досліджуєш або вирішуєш | skills верифікації |
| Goal-based | Умову зупинки | Знаєш, який вигляд має «готово» | /goal |
| Time-based | Тригер | Робота йде за розкладом | /loop · /schedule |
| Proactive | Промпт | Робота повторювана й чітко визначена | усе вище + workflows |
Подивись на роботу, яку вже робиш. Обери одну задачу, де вузьке місце — це ти, і спитай, яку частину можна віддати: чи можеш написати перевірку? Чи ціль достатньо чітка? Чи робота приходить за розкладом? Запусти цикл, поспостерігай, де він застрягає або переробляє, і не бійся ітерувати.
1. Ти хочеш, щоб агент довів Lighthouse до 90. Який цикл?
2. Робота має йти, навіть коли ноутбук закритий. Що беремо?
3. Треба відмігрувати 500 файлів так, щоб зміни не конфліктували. Що?
4. Як віддати агенту перевірку, щоб він не чекав на тебе?
5. Як не спалити токени на великому workflow?
Тепер ти вмієш проєктувати цикли: від ручного ходу до сотні паралельних агентів. Обери одну задачу цього тижня й віддай її циклу.