Skip to content
Deep Work Plan сьогодні на Product Hunt Підтримати

Відкрита методологія · MIT · Незалежно від агента

Моделі важливі. Контекст важливіший.

Deep Work Plan перетворює будь-який репозиторій на структуроване середовище — контекст, захисні бар’єри та довговічний план, — де будь-який агент розробки працює точно й ефективно та виконує тривалу роботу.

Скопіювати до агента https://deepworkplan.com/init.md

Скопіюйте промт init.md і вставте його у свій агент програмування — Claude Code, Cursor, Codex або будь-який інший — щоб зробити будь-який репозиторій AI-first.

Deep Work Plan — це spec-driven розробка, у якій сам репозиторій стає harness.

Маяк на скелястому березі кидає єдиний промінь, що скеровує невелике судно — гравюра, що уособлює репозиторій як надійний harness, що веде будь-якого агента.
Гравюрний диптих: ліворуч — корабель, що дрейфує в тумані біля скель, праворуч — той самий корабель, впевнено на прокладеному курсі до маяка гавані.

Проблема й відповідь

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

Deep Work Plan відповідає розробкою за специфікацією: міцний план, атомарні завдання та validation gates, які агент зобов’язаний пройти. «Готово» перестає бути відчуттям — стає перевіреним і оглянутим доказом.

І оскільки контекст — найдефіцитніший ресурс вашого агента, harness спроектований так, щоб його власне навантаження інструкціями залишалося малим і перевірюваним: інструкції завантажуються поступово, перевірка торкається лише зміненого, а навчання відбувається на місці завдання. Навантаження кожного потоку вимірюється в байтах і публікується з кожним релізом — останній реліз скоротив потік виконання на 45,7%, а потік відновлення на 67,5%. Сам план масштабується так само: Lite-план для точкового виправлення, Full-план для роботи, що триває годинами — формат завжди слідує за обсягом роботи, а не навпаки.

Метод · Акт I

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

Прочитати методологію →

Метод · Акт II

Довгі завдання заповнюють контекст будь-якої моделі. Деталі втрачаються, і агент дрейфує. Письмовий план — атомарні завдання, ворота валідації, відновлюваний стан — це те, до чого він повертається коло за колом.

Переглянути основний цикл →

Метод · Акт III

Кожне завдання називає свої критерії приймання та перевірки, які мають пройти. Агент не може «відчути себе завершеним» — він має пройти перевірку, інакше завдання залишається відкритим.

Прочитати специфікацію →

Метод · Акт IV

Контекст, інструменти, захисні бар’єри та стан живуть у вашому репозиторії простими файлами, які може прочитати будь-який агент. Без прив’язки, без зовнішнього мозку — усе переживає скидання контексту.

Подивитися, що створює онбордінг →

Метод · Акт V

Контекст — найдефіцитніший ресурс вашого агента. Harness завантажується поступово, перевіряє лише змінене та вчиться завдання за завданням — навантаження інструкціями кожного потоку виміряне й опубліковане, реліз за релізом.

Прочитати методологію →

Онбординг на основі міркувань

Спрямуйте його на будь-який репозиторій. Він міркує — а не копіює та вставляє.

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

  1. 01

    Міркує про ваш стек та архетип

    Читає маніфести, структуру каталогів та CI, щоб вивести реальні команди тестування, лінтингу та збірки, після чого класифікує репозиторій як окремий репозиторій або як хаб-оркестратор.

  2. 02

    Генерує AGENTS.md, docs/ та документацію кожного модуля

    Обґрунтований AGENTS.md, упорядкована за категоріями ієрархія docs/, а також README та docs/ усередині кожного великого модуля — заповнені реальними командами вашого репозиторію, а не заготовками.

  3. 03

    Створює .agents/ із символьними посиланнями .claude та .cursor на .agents

    Міжагентний каталог .agents/ (скіли, агенти, команди) та символьні посилання .claude та .cursor на .agents, що віддзеркалює CLAUDE.md у AGENTS.md, аби кожен інструмент читав одне джерело істини.

  4. 04

    Встановлює скіл DWP і створює .dwp/

    Підключає скіл Deep Work Plan і створює каталог .dwp/ у gitignore для планів, встановлює необхідний локальний огляд AI Diff Reviewer, а потім за бажанням додає опціональні addon, як-от підтримку devcontainer.

Що відбувається, коли ви це запускаєте

Одна інструкція. Решту робить репозиторій.

Ви не обираєте спосіб встановлення й не копіюєте шаблон. Ви передаєте агенту один рядок; він встановлює скіл — багаторазовий рушій — і пристосовує до нього ваш репозиторій.

  1. 01

    Ваш агент відкриває /init.md

    Він читає промт онбордингу за адресою deepworkplan.com/init.md, а також методологію, специфікацію та набір, на які той посилається — стандарт, який він збирається прийняти.

  2. 02

    Він встановлює скіл Deep Work Plan

    Скіл — це рушій, однаковий у кожному репозиторії. Одна команда підтягує маршрутизатор та його суб-скіли (create, execute, refine, resume, status, verify, onboard, author, upgrade) для Claude Code, Cursor, Codex, Gemini та Copilot.

  3. 03

    Він пристосовує ваш репозиторій

    Міркуючи про ваш реальний стек — ніколи не копіюючи та не вставляючи — він пише AGENTS.md, упорядковане дерево docs/, README кожного модуля, обґрунтований набір .agents/ та .dwp/ у gitignore. Ваш репозиторій стає harness.

  4. 04

    Ви плануєте та виконуєте

    Генеруйте тривалі Deep Work Plan для будь-якого завдання та виконуйте їх крок за кроком — із чіткими критеріями приймання, валідаційними gate та відновлюваним станом — автономно, годинами.

Скіл встановлюється всюди однаково; пристосовується саме ваш репозиторій — AGENTS.md, документація та обґрунтований набір .agents/, згенеровані під ваш стек. Саме цей поділ робить методологію багаторазовим стандартом, а не разовою заготовкою.

Що ви отримуєте

Усе, що потрібно вашому агенту для автономної роботи.

Один запуск, зафіксований атомарно. Кожен результат — це Markdown, а кожна зміна піддається аудиту.

  • AGENTS.md у корені репозиторію

    Обґрунтований на основі реального стеку, команд і структури вашого репозиторію — а не шаблон із заготовками. CLAUDE.md символьно посилається на AGENTS.md.

  • Упорядкований docs/ та документація кожного модуля

    Архітектура, налаштування, стандарти та усунення несправностей — плюс README і docs/ усередині кожного великого модуля, згенеровані з вашої кодової бази.

  • .agents/ із символьними посиланнями .claude та .cursor на .agents

    Міжагентний каталог .agents/ (скіли, агенти, команди) із символьними посиланнями .claude та .cursor на .agents, аби кожен інструмент читав одне джерело істини.

  • Встановлений скіл Deep Work Plan

    create, execute, refine, resume, status, verify, onboard, author та upgrade — доступні вашому агенту як єдиний пакет скілів, без копії для кожного репозиторію.

  • Відповідність, яку можна перевірити

    /dwp-verify формує обʼєктивний звіт «пройдено/не пройдено» за специфікацією, тож «AI-first» є перевіреним, а не просто заявленим — і його можна перевірити заново після кожного плану.

  • Два архетипи, опрацьовані

    Онбординг класифікує ваш репозиторій як окремий репозиторій (типовий випадок) або як хаб-оркестратор, що координує дочірні плани в межах багатьох репозиторіїв.

  • Живий набір, що зростає разом із репозиторієм

    Суб-скіл author (skill-create, agent-create) дає змогу репозиторію розвивати власні скіли, агенти та команди; опціональні addon обслуговування, як-от dependency-upgrade, допомагають йому підтримувати себе в актуальному стані.

  • Git-нативний, відновлюваний, .dwp/

    Без демона та без зовнішнього стану. Плани потрапляють у каталог .dwp/ у gitignore, і будь-яке завдання відновлюється виключно з git — навіть після переповнення контексту.

Агенти

Працює з агентом, яким ви вже користуєтеся.

Одна методологія, багато адаптерів. Markdown не привʼязує фреймворк ні до чого — будь-який агент, що читає Markdown, може запустити Deep Work Plan.

Claude Code

Повна

Еталонна реалізація, з нативними WebFetch та slash-командами.

Cursor

Повна

Повний адаптер. Скористайтеся офлайн-набором, якщо WebFetch обмежено.

OpenAI Codex

Повна

Рекомендовано офлайн-набір; правила встановлюються в .codex/.

GitHub Copilot

Повна

Повний адаптер — команди dwp-* виконуються через AGENTS.md та процедури #.

Gemini

Повна

Потрібен Gemini 2.5 Pro або новіший, із нативним WebFetch.

OpenCode

Повна

Відкритий код. Нативно читає AGENTS.md і запускає dwp-* через команди #.

Windsurf

Повна

Правила та процедури команд # керують повним циклом Deep Work Plan.

Cline

Повна

Відкритий код. Правила Markdown та команди # виконують кожен крок dwp-*.

Antigravity

Повна

Повний адаптер із нативним набором команд.

Стеки

Пресети-міркування для стеків, що мають значення.

Це допоміжні засоби для міркування, а не шаблони. Онбординг читає реальні маніфести вашого репозиторію та пристосовується до кожного стеку — він ніколи не копіює пресет наосліп. Монорепозиторії отримують документацію кожного модуля.

  • Django DRF · Poetry
  • FastAPI Pydantic · Poetry
  • Vue Vite · TypeScript
  • React Next · Vite · TS
  • Astro Svelte/React · MDX
  • TypeScript · Node Express · Fastify
  • TypeScript · Lambda Serverless · SAM
  • Go Modules · stdlib
  • Rust Cargo · 2021+
  • Generic Будь-який стек

Два архетипи

Окремий репозиторій або хаб-оркестратор.

Онбординг розгалужується за архетипом. Більшість репозиторіїв — це окремі репозиторії. Хаб координує дочірні 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.

— Інженерна команда Dailybot
Дізнатися про Dailybot

Зробіть свій репозиторій AI-first

Дайте своїм агентам глибоку роботу.

Передайте агенту один рядок — спрямуйте його на /init.md — і він зробить ваш репозиторій AI-first: встановить скіл, поміркує про ваш стек і зафіксує повну ієрархію AGENTS.md. Далі ви створюєте й виконуєте Deep Work Plan, що працюють автономно годинами.

Для агентів і розробників

Під ліцензією MIT · нуль телеметрії · виводить у каталог .dwp/ у gitignore.