FAQ
Часто задаваемые вопросы
Короткие ответы на самые частые вопросы о Deep Work Plan, каждый со ссылкой на страницу, где тема раскрыта глубже.
01
Что такое Deep Work Plan
Что именно делает Deep Work Plan?
Deep Work Plan превращает репозиторий в структурированную среду, где агент разработки надёжно выполняет долгую работу. Он устанавливается как навык агента и один раз проводит онбординг репозитория (индекс `AGENTS.md`, дерево `docs/`, набор навыков и команд `.agents/`, игнорируемая git-ом область вывода `.dwp/`), а после этого любая цель становится планом: атомарные задачи, каждая со своими критериями приёмки и validation gate, выполняются по одной, фиксируются коммитами по мере прохождения и возобновляются с диска любым агентом. План завершается Final Review, которая проверяет безопасность и валидирует финальное состояние. Методология распространяется по лицензии MIT и работает с любым агентом разработки, который читает репозиторий.
Для кого он предназначен?
Разработчикам и командам, которые передают агентам разработки настоящую многошаговую работу и хотят, чтобы она была доведена до конца. Методология уместна, когда задача выходит за рамки одной сессии, одного семейства файлов или одного агента; когда коллега должен суметь продолжить с того места, где агент остановился; или когда «готово» должно означать «провалидировано», а не «агент так сказал». Однострочной правке план не нужен, и методология прямо это признаёт: её правило соразмерной строгости рекомендует вместо этого ограничиться целью, критериями и gate, записанными по месту.
В чём разница между планом Lite и планом Full?
Это выбор формы представления, а не компромисс со строгостью. По умолчанию план — это Lite: компактный README с привязанными записями задач, уже готовый к исполнению, а не частичный черновик. Если вы сразу просите план Full, `create` напрямую пишет файлы задач Full; а когда детализация инструкций, зависимости или контракты задачи перестают помещаться в компактную, удобную для ревью запись, план разворачивается в Full. Повышение позже сохраняет каждую завершённую задачу. Оба формата несут одни и те же критерии приёмки, validation gates, свидетельства и обязательный 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` (или клонируйте репозиторий 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`). Точка adoption и быстрый старт проходят тот же путь подробнее.
Что именно устанавливается и куда?
Навык агента устанавливается туда, куда ваш агент загружает навыки проекта или пользователя. Затем онбординг адаптирует сам репозиторий: он создаёт или согласовывает `AGENTS.md`, `docs/`, `.agents/` и игнорируемую git-ом рабочую область `.dwp/`. Навык учит агента методу; репозиторий хранит контекст, набор инструментов и свидетельства плана, которые нужны другим агентам, чтобы продолжить.
Требует ли Deep Work Plan использования Git?
Для репозиториев Git рекомендуется, потому что его история — часть поверхности восстановления и ревью, но методология может выполняться и в рабочей области агента без git-репозитория. В этом случае обязателен машиночитаемый слой состояния, включая контрольные точки `state.json` и записи gates, чтобы восстановление не зависело от расшифровки чата.
В чём разница между навыком, планом и продуктовой спецификацией?
Навык описывает, как агент выполняет повторяемую процедуру. План DWP описывает конкретное изменение через область охвата, критерии приёмки, validation gates и свидетельства. Продуктовая спецификация описывает текущее поведение продукта и развивается через дельты после внедрения; навыки и планы тоже являются спецификациями, но они описывают процедуры и изменения, а не поддерживают этот канонический продуктовый контракт.
02
Как выполняется план
Как реализованы validation gates? Требуют ли они согласования человеком?
Это исполняемые утверждения, которые агент запускает сам. Участие человека обрамляет запуск: человек утверждает план перед выполнением и просматривает финальный дифф на этапе pull request; выполнение между ними автономно. Каждая задача называет конкретные команды — как правило, собственную проверку качества репозитория, — выбранные по затронутой поверхности задачи: тесты изменённого поведения и его потребителей, с расширением до полного набора, когда изменение разделяемое или его нельзя ограничить. Задача отмечается готовой, только если эти команды завершаются успешно, а задачи, меняющие поведение, обязаны расширять тесты. При провале агент сначала чинит то, что попадает в собственные рамки задачи, и повторяет gate; провал, который нельзя устранить в этих рамках, оставляет задачу помеченной заблокированной и останавливает выполнение.
Как план не устаревает, когда код меняют между запусками?
По трём направлениям. Задачи записываются как поведение, а не как правки: критерий приёмки говорит, что система должна делать, поэтому переименованный файл или заменённая реализация не обесценивают его. Каждый gate перезапускается на репозитории в его текущем виде, поэтому сломанное предположение громко проваливается при следующем запуске, а не дрейфует молча, — и этот провал служит сигналом к уточнению. И поддерживать документацию в актуальном виде — часть работы: задача, меняющая поведение, обновляет и описывающие её документацию, и набор для агентов, внутри собственного gate. Каждый запуск должен оставлять репозиторий более готовым к агентам, чем он его застал.
Можно ли менять план посреди выполнения, не теряя завершённой работы?
Да: уточнение частично выполненного плана — полноценный приём. Определения задач и состояние выполнения хранятся раздельно: план — это чек-лист на диске плюс небольшой файл состояния, поэтому сделанное остаётся записанным независимо от текста задач. Если задача оказывается ошибочной, агент помечает её заблокированной и останавливается, а не продавливает её силой. Затем вы редактируете, переупорядочиваете, разбиваете или отбрасываете ещё не выполненные задачи, а завершённые остаются завершёнными. Возобновление восстанавливает состояние с диска и из фактического репозитория и перезапускает значимые gates, поэтому ничто изменившееся под руками не ускользнёт.
Он постоянно сверяет работу с планом или план существует только в начале?
План — это непрерывная проверка. Агент работает маленькими задачами по одной и обязан валидироваться, прежде чем идти дальше, поэтому он может сойти на шаг, а не на три. Каждая задача несёт критерии приёмки и точные команды, которые их доказывают, а прогресс по ходу работы записывается в репозиторий со статусом по каждой задаче, поэтому дрейф становится виден вам, следующей сессии и следующему агенту. План не закончен, пока не провалидируется всё, включая Final Review. Честная оговорка: методология не может помешать агенту изначально записать слабый критерий приёмки; она делает дрейф громким, а не молчаливым.
План генерируется один раз и поддерживается вручную или развивается вместе с кодом?
Ни то, ни другое. План генерируется один раз из цели, а затем поддерживается как часть работы. Он намеренно не переписывается из диффов кода: спецификация, гонящаяся за кодом, становится запаздывающим зеркалом, а это тот самый дрейф, ради устранения которого методология существует. План развивается осознанно: gates перезапускаются на текущем репозитории, провалившийся gate запускает уточнение, и агент выполняет это уточнение во время прогона, пока вы утверждаете план в начале и делаете ревью в конце. Документация и тесты развиваются вместе с кодом по построению, потому что их обновление находится внутри gate каждой задачи.
Что будет, если сессия оборвётся на полпути?
Прогресс живёт на диске, а не в чате. Чекбоксы README, журнал каждой задачи, ограниченный рабочий индекс и машиночитаемый файл состояния обновляются на каждой границе задач, а файл состояния записывает контрольную точку перед любой запланированной паузой. Свежая сессия или другой агент читает этот компактный индекс, сверяет его с репозиторием и историей git и продолжает с первой незавершённой задачи, не переделывая законченную работу. Восстановимо даже прерванное создание плана: то, что это за план, и его задуманный список задач записываются раньше любых файлов задач, поэтому недосозданный план можно завершить или отбросить, а не угадывать.
Что такое Final Review?
Единственная обязательная закрывающая задача каждого плана. По порядку: проверка безопасности всего накопленного набора изменений плана, включая обязательное локальное ревью диффа навыком AI Diff Reviewer, где критические находки блокируют завершение, пока они не исправлены или явно приняты; валидация финального состояния — то есть все подходящие наборы тестов, линтинга, проверки типов и форматирования репозитория на финальном коде; и сверка записанных каждой задачей решений по skills. Затем агент отчитывается о результатах, свидетельствах и ограничениях и один раз предлагает Executive Report, создавая его, только если вы попросите.
Что происходит, если validation gate не проходит?
Провал gate — это сначала сигнал к починке: агент исправляет то, что попадает в собственные рамки задачи, и запускает gate повторно. Провал, выходящий за эти рамки, фиксирует задачу как заблокированную, и агент останавливается, не заявляя о завершении. Вы можете изучить свидетельства, исправить код или уточнить задачу, а затем возобновить работу; провалившаяся команда — сигнал устранить несоответствие, а не разрешение ослабить gate.
Что происходит, когда инструмент проверки соответствия не может выполнить свои проверки?
Он прямо об этом говорит. Проверка завершается с кодом выхода 2 и явным вердиктом `UNVERIFIED` — она никогда не печатает «пройдено», которого фактически не проверяла. Если в окружении нет способного интерпретатора или проверка не может выполниться, честный результат — «не проверено», а не «соответствует»; зелёный результат всегда означает, что каждая проверка выполнилась и прошла. Та же дисциплина пронизывает всю методологию: ни один поток не ослабляет и не подделывает gate, чтобы заявить о завершении.
Может ли план выполняться без присмотра ночью или в CI?
Да, если план был заранее утверждён, несёт требуемый слой состояния и наделяет агента ограниченными полномочиями. Запуск без присмотра обязан остановиться и зафиксировать блокер, когда реальность расходится с планом, gate проваливается за пределами запланированной области исправления или требуется новое согласование либо учётные данные.
03
Сравнение с другими
Может ли один план охватывать несколько репозиториев?
Да — архетип хаба-оркестратора существует именно для этого. Хаб-репозиторий хранит координирующий план, а каждый дочерний репозиторий выполняет собственный план в собственном изолированном рабочем пространстве `.dwp/`, поэтому дочерний репозиторий никогда не пишет в состояние планов хаба. Завершённость дочернего плана читается из собственного состояния верхнего уровня каждого плана, а не поиском строк внутри него, и хаб записывает, где он находится, прежде чем куда-либо переходить. Каждый дочерний репозиторий остаётся обычным DWP-репозиторием, который можно пилотировать и самостоятельно.
Чем он отличается от spec-driven-инструментов вроде Spec Kit, OpenSpec или Kiro?
Они решают смежные задачи. Spec-driven-инструменты отлично фиксируют, что должно измениться: спецификации, требования и предложения изменений в повторяемой форме. Deep Work Plan — о том, как агент выполняет работу часами без дрейфа: созданный онбордингом harness, пер-задачные validation gates, выбранные по затронутой поверхности, возобновляемое состояние на диске, обязательный Final Review с проверкой безопасности и инструмент проверки соответствия для самого репозитория. То и другое можно сочетать: спецификация или предложение изменений может питать план. Страница сравнения выкладывает возможности рядом, на условиях каждого инструмента.
Чем он отличается от инструментов агентных workflows, таких как BMAD, Superpowers, Get Shit Done или Gentle-AI?
Фреймворки для агентных рабочих процессов, такие как BMAD, Superpowers и Get Shit Done, привносят сильные стили работы: роли, принципы, шаги «сначала тесты», привычки проверки. Gentle-AI находится в соседней категории как конфигуратор экосистемы агентов: он оснащает уже используемых вами кодовых агентов постоянной памятью между сессиями (Engram), отобранными skills, персонами, серверами MCP, опциональным Spec-Driven Development и опциональной проверкой на основе доказательств (Receipt-Driven Development), записывая в конфигурационные директории каждого агента. Deep Work Plan отличается от обоих: он фокусируется на том, что остаётся в репозитории и что можно проверить — harness, который любой агент читает «с нуля», файлы задач с критериями приёмки и gates, состояние, переживающее сессию, проверщик соответствия с CI-дружелюбным кодом выхода и публикуемое измерение того, сколько байт инструкций загружает каждый flow. Он инструментально-независим по построению и не добавляет в основной цикл ни сервиса, ни провайдера, ни секрета. Слои могут сосуществовать: фреймворки и Gentle-AI формируют то, как работает агент; Deep Work Plan делает долгую работу устойчивой и проверяемой внутри репозитория. Страница сравнения показывает, где какой подход встроен, опционален или вне рамок.
Почему бы просто не использовать встроенный режим планирования моего агента?
Встроенные режимы планирования полезны, и Deep Work Plan строится на том же основании — соглашении `AGENTS.md` и открытом стандарте Agent Skills. Разница в том, где живёт план и что его обеспечивает. Нативные планы обычно живут вне репозитория и истекают вместе с сессией; Deep Work Plan записывает план, его состояние и его свидетельства в репозиторий, поэтому другой агент или коллега может продолжить его, а каждая задача несёт исполняемый gate и записанный журнал. Режим планирования агента вы продолжаете использовать для обдумывания; методология добавляет долговечный, проверяемый цикл выполнения.
04
Внедрение
Что онбординг записывает в мой репозиторий и затрагивает ли он существующие файлы?
Онбординг неразрушителен: он обнаруживает существующие `AGENTS.md`, `docs/`, `.agents/` или `CLAUDE.md`, согласовывает, а не перезаписывает, и спрашивает перед заменой чего-либо. Он записывает индекс `AGENTS.md` с реальными командами, осмысленное дерево `docs/`, документацию по модулям, набор `.agents/` с тонкими командами `dwp-*`, игнорируемую git-ом область вывода `.dwp/`, проверенную карту тестирования и обязательную локальную проверку кода (навык AI Diff Reviewer плюс адаптированное под репозиторий расширение ревью). Затем он запускает самопроверку и инструмент проверки соответствия, чтобы вы увидели, что получилось. Репозиторий, для которого онбординг был выполнен под более ранним стандартом, получает адресное обновление harness, согласовывающее только то, чего не хватает или что устарело.
Как обновить навык в репозитории, который уже прошёл онбординг?
Здесь два разных обновления, и поток держит их раздельно. Harness репозитория — `AGENTS.md`, `docs/`, набор `.agents/` — согласуется повторным запуском онбординга, который дополняет только недостающее или устаревшее. Сам навык движется через `/dwp-upgrade`: проверка последнего опубликованного релиза только для чтения, установка точного тега, который вы приняли, с верификацией, и затем онбординг заново как свежий запуск. Поток на каждом шаге требует явного согласия, локальные адаптации сравниваются через diff и сохраняются, а не перезаписываются, а `.dwp/` никогда не переносится — существующие планы сохраняют записанную форму и продолжают работать.
Можно ли использовать основную методологию без установки надстроек?
Да. Надстройки — это опциональные слои, и репозиторий без них полностью соответствует DWP. Devcontainers, отчётность Dailybot, обновление зависимостей, поддержка дизайн-системы и опциональное ревью в CI предлагаются только тогда, когда подходят вашему репозиторию, и только если вы явно их принимаете.
Что, если в моём репозитории пока нет тестов или линтинга?
DWP не считает отсутствие набора инструментов поводом для послаблений. Во время онбординга агент предлагает подходящую для стека настройку валидации, фиксирует команды в документации репозитория и использует эти команды как цель для будущих gates; предложение остаётся видимым, чтобы вы могли его проверить.
Сколько это стоит и как измеряется эффективность?
Методология и навык распространяются под лицензией MIT и бесплатны; в основных потоках нет сервиса, API-ключа и телеметрии. Эффективность сообщается как число байтов инструкций, которые каждый поток загружает **на входе** — его пакет в начале сессии, — публикуемое вместе с именованными **сквозными маршрутами**, добавляющими то, что загружают собственные триггеры потока по мере продолжения реальной работы (например, возобновление, которое затем переходит к выполнению, обычно загружает в несколько раз больше своего входного пакета). Ни одна из этих величин не ограничивает сессию: реальный запуск также читает файлы самого репозитория, вывод инструментов и рабочие файлы плана, ничего из этого реестр не учитывает. Обе величины измеряет зафиксированный вместе с навыком скрипт, перемеряет на каждой базовой линии релизов и публикует в реестре оценки, причём рост сообщается так же прямо, как и снижение. Процентами токенов или экономией затрат она не сообщается, потому что инвентаризация байтов этого не устанавливает. Публичная оценка на свежих агентах уже проведена по замороженному протоколу: одни и те же две функциональные задачи построены с чистых клонов без harness, с предыдущей мажорной версией и с текущей. Она показала, что агенты на дереве с harness читали меньше байтов в обеих задачах, а сессии задач текущей версии расходовали меньше входа и выхода модели, чем у предыдущей мажорной, в обеих задачах — по данным harness, на одной рабочей нагрузке. Она же честно обозначила пределы: онбординг — разовая стоимость, которая окупается только при использовании потоков; чистое направление токенов на рабочую нагрузку было смешанным; преимуществ по времени выполнения не заявляется; и свежий агент не входит в потоки сам — потоки это команды, которые вызываете вы или агент, знающий, как их вызвать.
Остался вопрос?
Остался вопрос?
Откройте обсуждение или issue на GitHub. Вопросы, которые возникают повторно, добавляются на эту страницу.