Orca CLI: агентний конвеєр від завдань до workspace

Як завдання стає роботою окремого агента

Мене тут цікавить не сам інтерфейс Orca, а зв’язка Orca CLI та automations: картка, переміщена до Select for development, може стати входом для окремого запуску агента. В офіційному огляді та довіднику Orca CLI описано операції з worktree, терміналами, файлами, diff, вбудованим браузером і звітами про перебіг роботи. Окрема документація щодо scheduled automations підтверджує запуск завдань для репозиторію або наявного workspace.

Я завантажив Orca й погрався з ним кілька годин. Негайного бажання переносити туди весь робочий процес не виникло, зате сценарій із Markdown-канбаном добре показує, навіщо взагалі потрібен CLI поверх середовища розробки. Orca стає не ще одним екраном з агентом, а виконавчим шаром між завданням і репозиторієм.

Запропонований конвеєр має такий вигляд:

• завдання з’являється в канбані Obsidian і змінює статус;
• для нього створюється ізольований workspace з окремою гілкою;
• мініагент виконує роботу та готує changelog;
• статус і результат повертаються до Markdown-файлу;
• злиття та розгортання залишаються окремими етапами.

Ключове застереження: офіційні матеріали Orca підтверджують роботу з ізольованими worktree, автоматизаціями та Markdown-артефактами, але не готову інтеграцію з Obsidian. Станом на 24 серпня 2026 року такого зв’язку в зібраній документації не описано. Отже, відстеження змін канбану та оновлення vault доведеться організувати як зовнішній шар, а не вважати вбудованою функцією.

Чому файловий канбан важливіший за інтерфейс

Цей підхід справді змінює роботу з кількома проєктами, але не робить її магічно автономною. Звичайний Markdown-файл перетворюється на чергу завдань, а ізольовані workspaces зменшують ризик змішування контексту, гілок і незавершених змін між паралельними агентами.

Я б насамперед перевіряв ідемпотентність: чи не створить повторна подія другий workspace для тієї самої картки? Далі йдуть відновлення після падіння агента, конфлікти гілок, синхронізація статусів і критерій готовності. Інакше гарний конвеєр швидко вироблятиме не код, а колекцію забутих робочих дерев.

Це не революція особистої продуктивності, а практична оркестрація вже знайомих складових: Git, Markdown, розкладів і агентів. Найцікавіше питання лишається відкритим: як довго такий файловий control plane зберігатиме простоту, коли завдань і репозиторіїв стане справді багато?

Раніше ми розбирали, як паралельні агенти Claude Code перевіряють PR і знаходять race conditions у workflow. Цей підхід добре доповнює ізольовані workspace, де кожному агенту потрібне окреме середовище для свого завдання.