Claude Code
ПовнаЕталонна реалізація, з нативними WebFetch та slash-командами.
Відкрита методологія · MIT · Незалежно від агента
Deep Work Plan перетворює будь-який репозиторій на структуроване середовище — контекст, захисні бар’єри та довговічний план, — де будь-який агент розробки працює точно й ефективно та виконує тривалу роботу.
Скопіюйте промт init.md і вставте його у свій агент програмування — Claude Code, Cursor, Codex або будь-який інший — щоб зробити будь-який репозиторій AI-first.
Deep Work Plan — це spec-driven розробка, у якій сам репозиторій стає harness.
Проблема й відповідь
У коротких ривках агенти розробки вражають. Доручіть їм тривалу місію — міграцію, новий підсистемний рефакторинг десятків файлів — і вони дрейфують: контекст переповнюється, попередні рішення бліднуть, а багатогодинна робота зупиняється на півдорозі.
Deep Work Plan відповідає розробкою за специфікацією: міцний план, атомарні завдання та validation gates, які агент зобов’язаний пройти. «Готово» перестає бути відчуттям — стає перевіреним і оглянутим доказом.
І оскільки контекст — найдефіцитніший ресурс вашого агента, harness спроектований так, щоб його власне навантаження інструкціями залишалося малим і перевірюваним: інструкції завантажуються поступово, перевірка торкається лише зміненого, а навчання відбувається на місці завдання. Навантаження кожного потоку вимірюється в байтах і публікується з кожним релізом — останній реліз скоротив потік виконання на 45,7%, а потік відновлення на 67,5%. Сам план масштабується так само: Lite-план для точкового виправлення, Full-план для роботи, що триває годинами — формат завжди слідує за обсягом роботи, а не навпаки.
Ви вирішуєте, що означає «готово» і де проходять межі. План несе ваш задум; агенти відпрацьовують години — без постійного нагляду та правок кожні двадцять хвилин.
Прочитати методологію →
Люди керують. Агенти виконують.
Довгі завдання заповнюють контекст будь-якої моделі. Деталі втрачаються, і агент дрейфує. Письмовий план — атомарні завдання, ворота валідації, відновлюваний стан — це те, до чого він повертається коло за колом.
Переглянути основний цикл →
План, від якого агенти не можуть відхилятися.
Кожне завдання називає свої критерії приймання та перевірки, які мають пройти. Агент не може «відчути себе завершеним» — він має пройти перевірку, інакше завдання залишається відкритим.
Прочитати специфікацію →
Готово — це контракт, а не відчуття.
Контекст, інструменти, захисні бар’єри та стан живуть у вашому репозиторії простими файлами, які може прочитати будь-який агент. Без прив’язки, без зовнішнього мозку — усе переживає скидання контексту.
Подивитися, що створює онбордінг →
Репозиторій — це harness.
Контекст — найдефіцитніший ресурс вашого агента. Harness завантажується поступово, перевіряє лише змінене та вчиться завдання за завданням — навантаження інструкціями кожного потоку виміряне й опубліковане, реліз за релізом.
Прочитати методологію →
Кожен токен на рахунку.
Онбординг на основі міркувань
Процес онбордингу перевіряє реальні мови, фреймворки, менеджер пакетів і команди валідації вашого репозиторію, а потім генерує артефакти, пристосовані до цього репозиторію. Загальна заготовка вважається невдачею.
Читає маніфести, структуру каталогів та CI, щоб вивести реальні команди тестування, лінтингу та збірки, після чого класифікує репозиторій як окремий репозиторій або як хаб-оркестратор.
Обґрунтований AGENTS.md, упорядкована за категоріями ієрархія docs/, а також README та docs/ усередині кожного великого модуля — заповнені реальними командами вашого репозиторію, а не заготовками.
Міжагентний каталог .agents/ (скіли, агенти, команди) та символьні посилання .claude та .cursor на .agents, що віддзеркалює CLAUDE.md у AGENTS.md, аби кожен інструмент читав одне джерело істини.
Підключає скіл Deep Work Plan і створює каталог .dwp/ у gitignore для планів, встановлює необхідний локальний огляд AI Diff Reviewer, а потім за бажанням додає опціональні addon, як-от підтримку devcontainer.
Що відбувається, коли ви це запускаєте
Ви не обираєте спосіб встановлення й не копіюєте шаблон. Ви передаєте агенту один рядок; він встановлює скіл — багаторазовий рушій — і пристосовує до нього ваш репозиторій.
Він читає промт онбордингу за адресою deepworkplan.com/init.md, а також методологію, специфікацію та набір, на які той посилається — стандарт, який він збирається прийняти.
Скіл — це рушій, однаковий у кожному репозиторії. Одна команда підтягує маршрутизатор та його суб-скіли (create, execute, refine, resume, status, verify, onboard, author, upgrade) для Claude Code, Cursor, Codex, Gemini та Copilot.
Міркуючи про ваш реальний стек — ніколи не копіюючи та не вставляючи — він пише AGENTS.md, упорядковане дерево docs/, README кожного модуля, обґрунтований набір .agents/ та .dwp/ у gitignore. Ваш репозиторій стає harness.
Генеруйте тривалі Deep Work Plan для будь-якого завдання та виконуйте їх крок за кроком — із чіткими критеріями приймання, валідаційними gate та відновлюваним станом — автономно, годинами.
Скіл встановлюється всюди однаково; пристосовується саме ваш репозиторій — AGENTS.md, документація та обґрунтований набір .agents/, згенеровані під ваш стек. Саме цей поділ робить методологію багаторазовим стандартом, а не разовою заготовкою.
Що ви отримуєте
Один запуск, зафіксований атомарно. Кожен результат — це Markdown, а кожна зміна піддається аудиту.
Обґрунтований на основі реального стеку, команд і структури вашого репозиторію — а не шаблон із заготовками. CLAUDE.md символьно посилається на AGENTS.md.
Архітектура, налаштування, стандарти та усунення несправностей — плюс README і docs/ усередині кожного великого модуля, згенеровані з вашої кодової бази.
Міжагентний каталог .agents/ (скіли, агенти, команди) із символьними посиланнями .claude та .cursor на .agents, аби кожен інструмент читав одне джерело істини.
create, execute, refine, resume, status, verify, onboard, author та upgrade — доступні вашому агенту як єдиний пакет скілів, без копії для кожного репозиторію.
/dwp-verify формує обʼєктивний звіт «пройдено/не пройдено» за специфікацією, тож «AI-first» є перевіреним, а не просто заявленим — і його можна перевірити заново після кожного плану.
Онбординг класифікує ваш репозиторій як окремий репозиторій (типовий випадок) або як хаб-оркестратор, що координує дочірні плани в межах багатьох репозиторіїв.
Суб-скіл author (skill-create, agent-create) дає змогу репозиторію розвивати власні скіли, агенти та команди; опціональні addon обслуговування, як-от dependency-upgrade, допомагають йому підтримувати себе в актуальному стані.
Без демона та без зовнішнього стану. Плани потрапляють у каталог .dwp/ у gitignore, і будь-яке завдання відновлюється виключно з git — навіть після переповнення контексту.
Агенти
Одна методологія, багато адаптерів. Markdown не привʼязує фреймворк ні до чого — будь-який агент, що читає Markdown, може запустити Deep Work Plan.
Еталонна реалізація, з нативними WebFetch та slash-командами.
Повний адаптер. Скористайтеся офлайн-набором, якщо WebFetch обмежено.
Рекомендовано офлайн-набір; правила встановлюються в .codex/.
Повний адаптер — команди dwp-* виконуються через AGENTS.md та процедури #.
Потрібен Gemini 2.5 Pro або новіший, із нативним WebFetch.
Відкритий код. Нативно читає AGENTS.md і запускає dwp-* через команди #.
Правила та процедури команд # керують повним циклом Deep Work Plan.
Відкритий код. Правила Markdown та команди # виконують кожен крок dwp-*.
Повний адаптер із нативним набором команд.
Стеки
Це допоміжні засоби для міркування, а не шаблони. Онбординг читає реальні маніфести вашого репозиторію та пристосовується до кожного стеку — він ніколи не копіює пресет наосліп. Монорепозиторії отримують документацію кожного модуля.
Два архетипи
Онбординг розгалужується за архетипом. Більшість репозиторіїв — це окремі репозиторії. Хаб координує дочірні Deep Work Plan у межах багатьох репозиторіїв. Методологія опрацьовує обидва як повноцінні.
Окремий репозиторій
самодостатня кодова база
Хаб-оркестратор
координує підрепозиторії
Єдина кодова база з одним основним стеком, власними командами валідації та документацією кожного модуля. Варіант за замовчуванням — онбординг припускає його, доки репозиторій не виявиться явно хабом.
Наприклад, Django API, застосунок на Vue або сервіс TypeScript Lambda.
Координаційний репозиторій, що оркеструє роботу між суб-репозиторіями через маніфест оркестратора, породжуючи дочірні плани, кожен з яких фіксується у власному репозиторії, плюс правила меж та навігаційний індекс.
Наприклад, хаб, що координує пʼять продуктових репозиторіїв.
Методологія проти інструмента
Deep Work Plan — не черговий генератор заготовок. Це рівень методології під будь-яким spec-driven або генерувальним інструментом, зосереджений на багатогодинних автономних запусках.
| Методологія проти інструмента | Deep Work Plan | Інструменти заготовок / специфікацій |
|---|---|---|
| Основний фокус | Багатогодинне автономне виконання | Генерація специфікації чи заготовки |
| Одиниця роботи | Deep Work Plan (відновлювана сесія) | Документ специфікації або заготовка |
| Модель стану | Git-нативний каталог .dwp/, відновлюваний | Часто зовнішня або в межах IDE |
| Привʼязка до агента | Незалежно від агента (Markdown та Bash) | Часто привʼязано до інструмента чи IDE |
| Відновлення контексту | Відновлюється після переповнення контексту | Зазвичай перезапускає завдання |
| Ліцензія | MIT, відкрита методологія та набір | Залежить |
Походження
Створено в Dailybot — компанії, що стоїть за асинхронними стендапами для розподілених команд. Усередині ми використовували Deep Work Plan, щоб зробити продакшн-репозиторії, які охоплюють Django, Vue, TypeScript Lambda та Astro, пілотовними агентами. Після місяців використання в продакшні ми відкрили методологію під ліцензією MIT.
Зробіть свій репозиторій AI-first
Передайте агенту один рядок — спрямуйте його на /init.md — і він зробить ваш репозиторій AI-first: встановить скіл, поміркує про ваш стек і зафіксує повну ієрархію AGENTS.md. Далі ви створюєте й виконуєте Deep Work Plan, що працюють автономно годинами.
Для агентів і розробниківПід ліцензією MIT · нуль телеметрії · виводить у каталог .dwp/ у gitignore.