Часті запитання

Deep Work Plan перетворює репозиторій на структуроване середовище, де агент програмування може надійно виконувати тривалу роботу. Він встановлюється як агентський скіл і один раз проводить онбординг репозиторію (індекс `AGENTS.md`, дерево `docs/`, набір скілів і команд `.agents/`, вихідна область `.dwp/` у gitignore), а відтак будь-яка мета стає планом: атомарні завдання, кожне з критеріями приймання та валідаційним gate, виконуються по одному, комітуються після проходження і відновлюються з диску будь-яким агентом. План завершується Final Review, який перевіряє безпеку та валідує кінцевий стан. Методологія розповсюджується за ліцензією MIT і працює з будь-яким агентом програмування, що читає репозиторій.

Читати методологію

Для розробників і команд, які доручають агентам програмування справжню багатокрокову роботу й хочуть, щоб вона була завершена. Це доречно, коли завдання охоплює кілька сесій, кілька родин файлів чи кількох агентів; коли колега має змогу підхопити роботу там, де агент зупинився; або коли «готово» має означати «перевірено», а не «агент так сказав». Однорядкове виправлення плану не потребує, і методологія це прямо каже: її правило пропорційної строгості рекомендує натомість записати мету, критерії та gate безпосередньо в контексті завдання.

Швидкий старт

Це вибір форми подання, а не компроміс щодо строгості. План за замовчуванням — Lite: компактний README із прив’язаними записами завдань, який уже є виконуваним, а не частковим чернетковим варіантом. Якщо ви одразу просите план Full, `create` пише Full-файли завдань безпосередньо; а коли деталізація інструкцій, залежності чи контракти завдання більше не вміщуються в компактний придатний для перегляду запис, план розгортається до Full. Пізніше підвищення зберігає кожне завершене завдання. Обидва формати несуть однакові критерії приймання, валідаційні gate, докази та обов’язковий Final Review.

Читати методологію

Методологія, упакована у встановлюваний скіл. Немає сервера, облікового запису, пропрієтарного формату чи окремого середовища виконання — понад агент програмування, яким ви вже користуєтеся. Встановлюються інструкції, які читає агент, невеликий набір shell-сценаріїв для виявлення контексту та перевірки відповідності й конвенції, які приймає ваш репозиторій. Усе, що породжує план, — це Markdown і JSON у вашому репозиторії, читабельні без жодного інструмента.

Читати специфікацію

З будь-яким агентом, що читає файли репозиторію. Скіл дотримується відкритого стандарту Agent Skills та конвенції `AGENTS.md`, тож Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot та інші підхоплюють його через звичайне для них завантаження скілів і інструкцій. Власне оцінювання методології показує план, розпочатий агентом одного вендора і продовжений агентом іншого, в обох напрямках. Покриття встановленням і поведінкові докази перелічено для кожного агента в матриці сумісності, і те й інше ніколи не змішують.

Переглянути набір

Три кроки. Спочатку встановіть skill Deep Work Plan у вашому агенті для кодування — найшвидший шлях: `npx skills add DailybotHQ/deepworkplan-skill` (або клонуйте репозиторій скіла й запустіть `./setup.sh`). Далі один раз проведіть onboarding репозиторію, щоб агент адаптував `AGENTS.md`, `docs/`, набір `.agents/` і область `.dwp/`, яку git ігнорує, до вашого стеку: вкажіть https://deepworkplan.com/init.md або запустіть `/deepworkplan-onboard`. Нарешті плануйте й виконуйте роботу за допомогою легких команд: `/dwp-create <goal>` будує план; `/dwp-execute` запускає його завдання за завданням проти кожного gate; `/dwp-refine` редагує план у процесі виконання (обсяг, завдання або підвищення плану Lite до Full); `/dwp-resume` продовжує після перерви; `/dwp-status` повідомляє про прогрес без виконання; `/dwp-verify` формує об’єктивний звіт про відповідність; `/dwp-upgrade` переносить установлену skill на новий реліз, не зачіпаючи наявні плани. Агенти, що перехоплюють `/`, часто використовують `#` замість цього (наприклад `#dwp-execute`). Ендпоінт впровадження та швидкий старт проходять тим самим шляхом детальніше.

Швидкий старт

Агентський скіл встановлюється там, де ваш агент завантажує проєктні або користувацькі скіли. Далі онбординг адаптує сам репозиторій: він створює або узгоджує `AGENTS.md`, `docs/`, `.agents/` та робочу область `.dwp/` у gitignore. Скіл навчає агента методу; репозиторій зберігає контекст, набір і докази плану, потрібні іншим агентам для продовження.

Переглянути потік впровадження

Git рекомендований для репозиторіїв, бо його історія — частина поверхні відновлення та перегляду, але методологія може також працювати в робочій області агента без репозиторію Git. У такому разі потрібен машиночитний шар стану, включно з контрольними точками `state.json` та записами gate, щоб відновлення не залежало від журналу чату.

Читати про архетипи репозиторіїв

Скіл описує, як агент виконує повторювану процедуру. План DWP описує конкретну зміну через обсяг, критерії приймання, валідаційні gate та докази. Специфікація продукту описує поточну поведінку продукту і еволюціонує через дельти після впровадження; скіли й плани також є специфікаціями, але вони описують процедури та зміни, а не підтримують цей канонічний контракт продукту.

Читати специфікацію

Це виконувані перевірки-твердження, які агент запускає сам. Участь людини обрамляє виконання: людина ухвалює план перед виконанням і переглядає підсумковий diff на етапі pull request; усе між цим відбувається автономно. Кожне завдання називає конкретні команди — як правило, власний gate якості репозиторію, — вибрані з торкнутої поверхні завдання: тести зміненої поведінки та її споживачів, з розширенням до повного набору, коли зміна є спільною або її не вдається обмежити. Завдання позначається завершеним, лише коли ці команди завершуються успішно, а завдання, що змінюють поведінку, мусять розширювати тести. У разі невдачі агент спершу полагоджує те, що потрапляє у власні межі завдання, і повторює gate; невдача, яку не вдається усунути в цих межах, залишає завдання позначеним заблокованим і зупиняє виконання.

Основний цикл

З трьох боків. Завдання пишуться як поведінка, а не як правки: критерій приймання каже, що система має робити, тож перейменований файл або замінена реалізація його не скасовує. Кожен gate перезапускається проти репозиторію в його поточному стані, тож хибне припущення гучно падає на наступному запуску замість того, щоб тихо дрейфувати, і саме ця невдача є сигналом до уточнення. А підтримання документації в синхроні — частина роботи: завдання, що змінює поведінку, оновлює також документацію та агентський набір, які її описують, усередині власного gate. Кожен запуск має залишати репозиторій придатнішим для агентів, ніж він його знайшов.

Читати методологію

Так; уточнення частково виконаного плану — повноцінна операція. Визначення завдань і стан виконання зберігаються окремо: план — це контрольний список на диску плюс невеликий файл стану, тож зроблене лишається зафіксованим незалежно від тексту завдань. Коли завдання виявляється хибним, агент позначає його заблокованим і зупиняється, а не протискує крізь нього. Далі ви редагуєте, перевпорядковуєте, розбиваєте або відкидаєте завдання, що ще не виконувалися, а завершені завдання лишаються завершеними. Відновлення відбудовує стан з диску та фактичного репозиторію і перезапускає важливі gate, тож ніщо, що змінилося тим часом під поверхнею, не прослизне непоміченим.

Основний цикл

План — це безперервна перевірка. Агент працює над одним невеликим завданням за раз і мусить валідувати його, перш ніж рухатися далі, тож відхилитися він може на крок, а не на три. Кожне завдання несе критерії приймання плюс точні команди, що їх доводять, а прогрес записується в репозиторій у процесі роботи, зі статусом для кожного завдання, тож дрейф стає видимим для вас, для наступної сесії та для наступного агента. План не завершений, доки не провалідовано все, включно з Final Review. Чесне застереження: методологія не може завадити агентові одразу написати слабкий критерій приймання — вона робить дрейф гучним, а не безшумним.

Основний цикл

Ні те, ні інше. План генерується один раз із мети, а далі підтримується як частина роботи. План навмисно не перезаписується з diff коду, бо специфікація, що женеться за кодом, стає відстаючим дзеркалом — а це саме той дрейф, для вбивства якого методологія й існує. Він еволюціонує цілеспрямовано: gate перезапускаються проти поточного репозиторію, невдалий gate спричиняє уточнення, і агент виконує це уточнення під час запуску, тоді як ви ухвалюєте наперед і переглядаєте в кінці. Документація та тести еволюціонують поруч із кодом за самою конструкцією, бо їхнє оновлення лежить усередині gate кожного завдання.

Читати методологію

Прогрес живе на диску, а не в чаті. Прапорці README, журнал кожного завдання, обмежений робочий індекс та машиночитний файл стану оновлюються на кожній межі завдань, а файл стану фіксує контрольну точку перед кожною запланованою паузою. Нова сесія — або інший агент — читає цей компактний індекс, узгоджує його з репозиторієм та історією git і продовжує з першого незавершеного завдання, не перероблюючи завершену роботу. Відновлюваний навіть перерваний процес створення плану: ідентичність плану та задуманий список завдань записуються раніше за будь-який файл завдання, тож напівстворений план можна завершити або відкинути, а не відновлювати здогадками.

Основний цикл

Єдине обов’язкове завершальне завдання кожного плану. По черзі: перевірка безпеки повного накопиченого набору змін плану, включно з необхідним локальним оглядом diff скілом AI Diff Reviewer, де критичні знахідки блокують завершення, доки їх не виправлено або явно не прийнято; валідація кінцевого стану — тобто повний придатний набір тестів, lint, перевірки типів та форматування репозиторію на фінальному коді; та узгоднення рішень щодо skills, які зафіксувало кожне завдання. Після цього агент звітує про результати, докази та обмеження і один раз пропонує Executive Report, генеруючи його лише на запит.

Специфікація

Провалений gate — це насамперед сигнал до полагодження: агент виправляє те, що потрапляє у власні межі завдання, і запускає gate повторно. Невдача, що виходить за ці межі, залишає завдання зафіксованим як заблоковане, і агент зупиняється, перш ніж заявляти про завершення. Ви можете переглянути докази, виправити код або уточнити завдання, а потім відновити роботу; невдала команда — сигнал усунути розбіжність, а не дозвіл послабити gate.

Читати агентський протокол

Він прямо про це каже. Перевірник завершується кодом виходу 2 і явним вердиктом `UNVERIFIED` — він ніколи не друкує «пройдено», якого фактично не перевіряв. Якщо в середовищі немає здатного інтерпретатора або перевірка не може виконатися, чесний результат — «не перевірено», а не «відповідає»; зелений результат завжди означає, що кожна перевірка виконалася і пройшла. Та сама дисципліна пронизує всю методологію: жоден потік не послаблює і не підроблює gate, щоб заявити про завершення.

Контракт відповідності

Так, якщо план заздалегідь схвалено, він несе необхідний шар стану і надає агенту обмежені повноваження. Запуск без нагляду має зупинитися й зафіксувати блокер, коли реальність розходиться з планом, gate не проходить поза межами запланованого обсягу виправлення або потрібне нове схвалення чи нові облікові дані.

Читати протокол роботи без нагляду

Так — архетип хаба-оркестратора існує саме для цього. Хаб-репозиторій тримає план, що координує, а кожен дочірній репозиторій виконує власний план у власному ізольованому робочому просторі `.dwp/`, тож дочірній репозиторій ніколи не пише в стан планів хаба. Завершеність дочірнього плану читається з власного стану верхнього рівня кожного плану, а не пошуком рядків усередині нього, і хаб записує, де він перебуває, перш ніж переходити кудись. Кожен дочірній репозиторій лишається звичайним DWP-репозиторієм, який можна пілотувати й самостійно.

Архетипи репозиторіїв

Вони розв’язують суміжні проблеми. Spec-driven засоби чудово фіксують те, що має змінитися: специфікації, вимоги та пропозиції змін у повторюваній формі. Deep Work Plan — про те, як агент виконує роботу годинами без дрейфу: створений онбордингом harness, вибрані з торкнутої поверхні валідаційні gate для кожного завдання, відновлюваний стан на диску, обов’язковий Final Review із перевіркою безпеки та перевірник відповідності для самого репозиторію. Цих двох можна поєднати: специфікація або пропозиція змін живить план. Сторінка порівняння викладає можливості поруч — кожен засіб на його власних умовах.

Переглянути порівняння

Фреймворки для агентних робочих процесів, такі як BMAD, Superpowers і Get Shit Done, привносять сильні стилі роботи: ролі, принципи, кроки «спершу тести», звички перевірки. Gentle-AI перебуває в сусідній категорії як конфігуратор екосистеми агентів: він оснащує вже використовувані вами кодові агенти постійною пам'яттю між сесіями (Engram), відібраними skills, персонами, серверами MCP, опціональним Spec-Driven Development і опціональною перевіркою на основі доказів (Receipt-Driven Development), записуючи в конфігураційні каталоги кожного агента. Deep Work Plan відрізняється від обох: він фокусується на тому, що залишається в репозиторії і що можна перевірити — harness, який будь-який агент читає «з нуля», файли завдань із критеріями прийняття та gate, стан, що переживає сесію, перевірник відповідності з CI-дружнім кодом виходу та опублікований вимір того, скільки байтів інструкцій завантажує кожен flow. Він інструментально-незалежний за побудовою і не додає до основного циклу жодного сервісу, провайдера чи секрету. Шари можуть співіснувати: фреймворки та Gentle-AI формують те, як працює агент; Deep Work Plan робить довгу роботу тривкою і перевірюваною всередині репозиторію. Сторінка порівняння показує, де який підхід вбудований, опціональний чи поза межами.

Переглянути порівняння

Вбудовані режими планування корисні, і Deep Work Plan стоїть на тому самому фундаменті — конвенції `AGENTS.md` та відкритому стандарті Agent Skills. Різниця в тому, де живе план і що його забезпечує. Нативні плани зазвичай живуть поза репозиторієм і завершуються разом із сесією; Deep Work Plan записує план, його стан і його докази в репозиторій, тож продовжити його може інший агент або колега, а кожне завдання несе виконуваний gate і зафіксований журнал. Ви й далі користуєтеся режимом планування свого агента для роздумів; методологія додає довговічний, перевірюваний цикл виконання.

Переглянути порівняння

Онбординг неруйнівний: він виявляє наявні `AGENTS.md`, `docs/`, `.agents/` чи `CLAUDE.md`, узгоджує, а не перезаписує, і питає перед заміною будь-чого. Він записує індекс `AGENTS.md` із реальними командами, обґрунтоване дерево `docs/`, документацію кожного модуля, набір `.agents/` із тонкими командами `dwp-*`, вихідну область `.dwp/` у gitignore, перевірену карту тестування та необхідний локальний огляд коду (скіл AI Diff Reviewer плюс розширення огляду, пристосовані до репозиторію). Потім він запускає самоперевірку та перевірник відповідності, тож ви бачите, що було створено. Репозиторій, який пройшов онбординг за ранішого стандарту, отримує адресне оновлення harness, що узгоджує лише те, чого бракує або що застаріло.

Ендпоінт впровадження

Тут два різні оновлення, і потік тримає їх окремо. Harness репозиторію — `AGENTS.md`, `docs/`, набір `.agents/` — узгоджується повторним запуском онбордингу, який доповнює лише те, чого бракує або що застаріло. Сам скіл рухається через `/dwp-upgrade`: перевірка найновішого опублікованого релізу лише для читання, установка точного тегу, який ви прийняли, з верифікацією, а потім онбординг заново як свіжий запуск. Потік на кожному кроці потребує явної згоди, локальні адаптації порівнюються через diff і зберігаються, а не перезаписуються, а `.dwp/` ніколи не переноситься — наявні плани зберігають записану форму й продовжують працювати.

Ендпоінт впровадження

Так. Додатки — це опційні шари, і репозиторій без жодного з них повністю відповідає DWP. Devcontainers, звітування Dailybot, оновлення залежностей, підтримка дизайн-системи та опційний CI-огляд пропонуються, лише якщо вони пасують вашому репозиторію і ви явно їх приймаєте.

Переглянути додатки

DWP не сприймає відсутність інструментарію як привід її оминути. Під час онбордингу агент пропонує налаштування валідації, доречне для стеку, фіксує команди в документації репозиторію і використовує ці команди як ціль для майбутніх gate; пропозиція лишається видимою для вашого перегляду.

Читати агентський протокол

Методологія та скіл розповсюджуються за ліцензією MIT і безкоштовні; у базових потоках немає служби, API-ключа чи телеметрії. Ефективність звітується як кількість байтів інструкцій, які кожен потік завантажує **на вході** — його пакет на початку сесії — і публікується поряд із названими **наскрізними шляхами**, що додають те, що завантажують власні тригери потоку, коли реальна робота триває (наприклад, resume, що переходить до execute, зазвичай завантажує в кілька разів більше за свій вхідний пакет). Жодне з цих чисел не обмежує сесію: реальний прогін також читає власні файли репозиторію, вивід інструментів і робочі файли плану, які цей реєстр не рахує. Обидва числа вимірює сценарій, зафіксований разом зі скілом, перемірює на кожній базовій лінії релізів, а результати публікуються в реєстрі оцінювання, причому зростання звітується так само відкрито, як і зменшення. Це не звітується у відсотках токенів чи економії витрат, бо інвентаризація байтів цього не доводить. Публічне оцінювання зі свіжими агентами вже проведено за замороженим протоколом: ті самі дві функціональні задачі побудовані з чистих клонів без harness, з попередньою мажорною версією та з чинною. Воно показало, що агенти на дереві з harness читали менше байтів в обох задачах, а сесії задач чинної версії витрачали менше входу й виходу моделі, ніж у попередньої мажорної, в обох задачах — за даними harness, на одному робочому навантаженні. Воно ж чесно позначило межі: онбординг — разова вартість, що окупається лише за використання потоків; чистий напрям токенів на робоче навантаження був змішаним; переваг у часі виконання не заявляється; і свіжий агент не входить у потоки сам — потоки це команди, які викликуєте ви або агент, що знає, як їх викликати.

Довіра та розкриття