# Dynamic Workflows у Copilot: коли хороший промпт стає частиною engineering process > GitHub Copilot отримав Dynamic Workflows у public preview: повторювані AI-процеси, які описуєш природною мовою, версіонуєш у репозиторії і запускаєш командою. Розбираємо, чим workflow відрізняється від промпта і де межі. - Автор: Юра Скиба (https://cookiesoftware.io) - Опубліковано: 2026-10-15 - Категорія: AI в роботі розробника - Canonical: https://cookiesoftware.io/blog/github-copilot-dynamic-workflows --- GitHub додав Dynamic Workflows у public preview для Copilot CLI і застосунку Copilot: ти описуєш повторюваний процес природною мовою, Copilot генерує workflow-визначення, яке можна зберегти в репозиторії (`.github/extensions/`) і запускати знову й знову – з approval перед стартом, явними permissions і лімітом AI-кредитів. Головна думка: це перехід від «вдалого промпта в чиїйсь голові» до версіонованого командного процесу. Розбираємось, як це працює і чого воно не вирішує. ## Промпт vs workflow Промпт відповідає на питання «що зробити зараз?». Workflow відповідає на питання «як наша команда робить це завжди?». Це різні рівні зрілості. Коли команда щотижня копіює той самий 40-рядковий промпт у Copilot чи Claude – «запусти release checks, знайди failures, проаналізуй причину, запропонуй fix, зупинись перед deploy» – це вже не промпт. Це процес, який випадково живе в буфері обміну замість репозиторію. Dynamic Workflows якраз і переносять його в репозиторій. ## Як це працює Створення максимально просте – описуєш бажане природною мовою прямо в сесії: ```text Create a dynamic workflow named review-changed that lists changed files, asks an agent to review them, and summarizes the findings. ``` Copilot генерує визначення workflow. За замовчуванням воно живе в session-specific extension, але його можна скопіювати у два місця з різною зоною дії: `~/.copilot/extensions/` (особисті) або `.github/extensions/` (репозиторій – доступно всій команді). Останнє – найважливіша деталь усієї фічі: **workflow у `.github/extensions/` версіонується разом із кодом**. Він проходить code review, має історію змін і діфи. Твій процес release-перевірок тепер можна рев'юїти так само, як код. Запуск – командою з явними дозволами: ```bash copilot workflow run review-changed --args '{"input":"value"}' --allow-tool=read ``` Або просто згадкою в сесії: «Run the java-security-checks dynamic workflow on the java files in the current directory, with an AI credit limit of 500». Перед стартом Copilot попросить approval; ліміти кредитів опціональні, але рекомендовані. Моніторинг – через `/workflows` у CLI або кнопку Workflows у застосунку. Технічна примітка: фіча в public preview, у CLI вмикається експериментальним прапорцем (`--experimental` або `/experimental on`), а ширше розповсюдження workflow-ів робиться через plugins. ## Де найбільше користі Найкращі кандидати – процеси, які повторюються, мають чіткі кроки і зараз живуть у чиїйсь голові: - **release preparation** – чеки, ченджлог, верифікація; - **flaky test triage** – зібрати падіння, класифікувати, знайти патерн; - **security checklist** – прогнати перед релізом те, що «всі знають, але забувають»; - **dependency upgrades** – рутинна частина, з ескалацією на людину для мажорних; - **incident first response** – зібрати контекст, поки людина прокидається; - **PR review за правилами команди** – ваші конвенції, не загальні поради. Помічаєш патерн? Це все процеси, де цінність не в геніальності окремого кроку, а в тому, що жоден крок не пропущено. Машини в цьому традиційно кращі за людей о шостій вечора п'ятниці. ## Межі, про які варто думати одразу **Workflow не повинен ховати responsibility.** Якщо крок може видалити дані або задеплоїти production – потрібен explicit approval, і добре, що механізм approvals тут вбудований. Це та сама логіка розділення, що й у [multi-model оркестрації HydraFusion](/blog/github-copilot-hydrafusion-max): автоматизуй механіку, лишай людині рішення з незворотними наслідками. **Поганий процес, автоматизований AI, залишається поганим процесом.** Просто тепер він працює швидше і з більшою впевненістю в голосі. Перед тим як пакувати процес у workflow, чесно спитай: а він узагалі правильний? Автоматизація фіксує процес у бурштині – разом із його вадами. **Workflow – це код, і його треба тестувати.** Прогнати на реальних задачах, подивитись, де агент помиляється, виправити формулювання. Без цього ти отримаєш [той самий клас проблем, що й з будь-яким агентом без evals](/blog/ai-agent-evals): «ніби працює» – до першого цікавого випадку. ## Executable onboarding Окремий приємний ефект: раніше onboarding нової людини означав README «ось як ми робимо release» – який застарівав через місяць. Тепер документація може бути executable: новачок не читає про процес, а запускає його і дивиться, як агент проходить ті самі кроки, які проходила б команда. Це споріднено з ідеєю, яку я описував у [статті про Claude Code](/blog/claude-code-dlia-react): конвенції проєкту, записані для агента, виявляються найчеснішою документацією – бо вони або працюють, або ні, без проміжних станів «ну, малось на увазі». ## Чому перші workflow розчаровують - **Запакувати все одразу.** Почни з одного процесу, який болить найчастіше. Двадцять workflow-ів без власника – це двадцять нових джерел підтримки. - **Без лімітів.** AI credit limit – не бюрократія: workflow, що зациклився на дорогому кроці, вміє неприємно здивувати рахунком. - **Широкі permissions «щоб працювало».** `--allow-tool=read` для рев'ю достатньо. Дозвіл на запис дається кроку, а не процесу цілком. - **Жодного власника.** Workflow без відповідального деградує так само, як CI-конфіг без власника – просто тихіше. ## Один процес команди → один workflow Знайди в команді процес, який за останній місяць ви робили тричі і щоразу хтось питав «а як ми це робимо?». Опиши його Copilot-у природною мовою, збережи workflow у `.github/extensions/`, прожени на реальному кейсі й подивись, де агент спіткнувся. Місце, де він спіткнувся, – це майже завжди місце, де ваш процес був недоописаний і для людей теж. Хороший промпт – це корисно. Хороший процес, який команда може запускати знову і знову, – уже engineering.