よくある質問

Deep Work Plan はリポジトリを、コーディングエージェントが長い作業を確実に実行できる構造化された環境に変えます。エージェントスキルとしてインストールされ、リポジトリのオンボーディングを一度だけ実行します（`AGENTS.md` のインデックス、`docs/` ツリー、スキルとコマンドの `.agents/` キット、gitignore された `.dwp/` 出力領域）。以後、あらゆる目標が計画になります。原子タスクの一つひとつに受け入れ基準と検証ゲートが伴い、一つずつ実行され、通過するたびにコミットされ、どのエージェントでもディスクから再開できます。計画は、セキュリティを監査し最終状態を検証する Final Review で締めくくられます。方法論は MIT ライセンスで、リポジトリを読めるどのコーディングエージェントとも動作します。

方法論を読む

本物の複数ステップの作業をコーディングエージェントに任せ、それをやり遂げてほしい開発者とチームのためのものです。タスクが複数のセッション、複数のファイル群、複数のエージェントにまたがるとき。チームメイトがエージェントの停止地点から引き継げる必要があるとき。あるいは「完了」が「エージェントがそう言った」ではなく「検証済み」を意味しなければならないときに適合します。一行修正に計画は不要であり、方法論も自らそう述べています。比例リゴーの規則は、代わりにインラインの目標・基準・ゲートを推奨します。

クイックスタート

厳密さのトレードオフではなく、表現形式の選択です。計画はデフォルトで Lite です。アンカー付きのタスク記録を備えたコンパクトな README であり、部分的なドラフトではなく、すでに実行可能です。最初から Full プランを指定すれば、`create` は Full のタスクファイルを直接書き込みます。また、タスクの指示の詳細・依存関係・契約がレビュー可能なコンパクト記録に収まらなくなると、計画を Full へ展開します。後からの昇格でも完了済みタスクはすべて保持されます。両方の形式とも、同じ受け入れ基準・検証ゲート・証拠・必須の Final Review を備えています。

方法論を読む

インストール可能なスキルとしてパッケージされた方法論です。サーバーも、アカウントも、独自のフォーマットも、すでに使っているコーディングエージェント以外のランタイムもありません。インストールされるのは、エージェントが読む指示、コンテキスト検出と適合性チェックのための小さなシェルスクリプト群、そしてリポジトリが採用する規約です。計画が生成するすべてはリポジトリ内の Markdown と JSON であり、ツールなしで読めます。

仕様を読む

リポジトリのファイルを読めるエージェントすべてです。スキルはオープンな Agent Skills 標準と `AGENTS.md` 規約に従うため、Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot などが、通常のスキルと指示の読み込みを通じて取り込みます。方法論自身の評価では、あるベンダーのエージェントが開始した計画を別ベンダーのエージェントが再開する様子が双方向で示されています。インストール対応状況と挙動の証拠はエージェントごとに互換性マトリクスへ列挙され、両者が混同されることはありません。

キットを見る

三つのステップです。まず、コーディングエージェントに Deep Work Plan スキルをインストールします——最も速い方法は `npx skills add DailybotHQ/deepworkplan-skill`（またはスキルリポジトリをクローンして `./setup.sh` を実行）です。次に、リポジトリに一度オンボーディングし、エージェントに `AGENTS.md`、`docs/`、`.agents/` キット、gitignore された `.dwp/` 領域をあなたのスタックに適応させます：https://deepworkplan.com/init.md を指すか、`/deepworkplan-onboard` を実行します。第三に、薄いコマンドで計画と実行を行います：`/dwp-create <goal>` が計画を構築し、`/dwp-execute` が各ゲートに対してタスク単位で実行し、`/dwp-refine` が進行中の計画（スコープ、タスク、または Lite プランから Full への昇格）を編集し、`/dwp-resume` が中断後に続行し、`/dwp-status` が実行せずに進捗を報告し、`/dwp-verify` が客観的な適合性レポートを生成し、`/dwp-upgrade` がインストール済みのスキルを、既存のプランに触れることなく新しいリリースへ移動します。`/` をインターセプトするエージェントは `#` を使うことが多いです（例：`#dwp-execute`）。アダプションエンドポイントとクイックスタートが、同じ経路をより詳しく説明します。

クイックスタート

エージェントスキルは、あなたのエージェントがプロジェクトまたはユーザーのスキルを読み込む場所にインストールされます。続いてオンボーディングがリポジトリ自体を適応させます。`AGENTS.md`、`docs/`、`.agents/`、そして gitignore された `.dwp/` ワークスペースを作成または調整します。スキルはエージェントにこの方法を教え、リポジトリは他のエージェントが作業を続けるために必要なコンテキスト・キット・計画の証拠を保持します。

採用フローを見る

リポジトリには Git を推奨します。その履歴が復旧とレビューの対象面の一部を成すためです。ただし方法論は、Git リポジトリを持たないエージェントのワークスペースでも動作します。その場合、`state.json` のチェックポイントとゲートの記録を含む機械可読の状態レイヤーが必須となり、復旧がチャットの記録に依存しないようにします。

リポジトリのアーキタイプを読む

スキルは、エージェントが繰り返し可能な手順をどう実行するかを記述します。DWP の計画は、スコープ・受け入れ基準・検証ゲート・証拠を通じて具体的な変更を記述します。プロダクト仕様はプロダクトの現在の挙動を記述し、実装後は差分を通じて進化します。スキルと計画も広い意味では仕様ですが、それらは手順と変更を記述するものであり、その正典的なプロダクト契約を維持するものではありません。

仕様を読む

ゲートは、エージェント自身が実行する実行可能なアサーションです。人の承認は実行の両端にあります。実行の前に人が計画を承認し、プルリクエストの時点で最終 diff をレビューし、その間の実行は自律的に行われます。すべてのタスクは具体的なコマンドを明記します。通常はリポジトリ自身の品質ゲートであり、タスクの変更対象面から選ばれます。変更された挙動とそのコンシューマーのテストから始まり、変更が共有されているか境界づけられない場合はスイート全体に広がります。タスクはそれらのコマンドが正常終了したときだけ完了とマークされ、挙動を変更するタスクはテストを拡張しなければなりません。失敗した場合、エージェントはまずタスク自身のスコープ内に収まるものを修復してゲートを再実行します。そのスコープで修復できない失敗だけが、タスクをブロックとマークし、実行を停止させます。

コアループ

三つの面で防ぎます。第一に、タスクは編集ではなく挙動として書かれます。受け入れ基準はシステムが何をすべきかを述べるため、ファイルの改名や実装の差し替えで無効になりません。第二に、すべてのゲートは今のリポジトリに対して再実行されるため、壊れた前提は静かにドリフトするのではなく次の実行で明確に失敗し、その失敗こそがリファインの合図になります。第三に、ドキュメントの同期を保つことも作業の一部です。挙動を変更するタスクは、自分のゲートの内側で、それを記述するドキュメントとエージェント向けキットも更新します。すべての実行は、着手したときよりもエージェントにとって準備の整ったリポジトリを残すべきです。

方法論を読む

はい。部分的に実行された計画をリファインすることは、第一級の操作です。タスク定義と実行状態は分けて保持されます。計画はディスク上のチェックリストと小さな状態ファイルであり、完了したことはタスク本文とは独立に記録され続けます。タスクが誤りだと判明した場合、エージェントは強行するのではなく、ブロックとマークして停止します。そのあとあなたが、まだ実行していないタスクを編集・並べ替え・分割・削除し、完了したタスクは完了のまま残ります。再開時にはディスクと実際のリポジトリから状態が再構築され、重要なゲートが再実行されるため、水面下で変わったものが見逃されることはありません。

コアループ

計画は継続的なチェックです。エージェントは一度に一つの小さなタスクだけを扱い、次に進む前に検証しなければならないため、迷えるのは三歩ではなく一歩です。すべてのタスクは受け入れ基準に加えて、それを証明する正確なコマンドを持ちます。進捗はタスクごとのステータスとともにリポジトリに書き込まれていくため、ドリフトはあなたにも、次のセッションにも、次のエージェントにも見えるようになります。Final Review を含め、すべてが検証されるまで計画は完了しません。正直な注意点として、方法論はエージェントが最初に弱い受け入れ基準を書くことまでは止められません。ただ、ドリフトを静かではなく見える形に変えます。

コアループ

どちらでもありません。計画は目標から一度生成され、その後は作業の一部として保守されます。コード diff から書き直されないのは意図的です。コードを追いかけ続ける仕様は後追いの鏡になり、それはこの方法論が撲滅のために存在するドリフトそのものだからです。進化は意図的に行われます。ゲートは現在のリポジトリに対して再実行され、失敗するゲートはリファインを引き起こし、エージェントは実行中にそのリファインを実行します。あなたは事前に承認し、最後にレビューします。ドキュメントとテストは、その更新が各タスクのゲートの内側にあるため、構成上コードとともに進化します。

方法論を読む

進捗はチャットではなくディスクにあります。README のチェックボックス、各タスクのログ、範囲が限られた作業インデックス、機械可読の状態ファイルがすべてのタスク境界で更新され、状態ファイルは計画された休止の前にチェックポイントを記録します。新しいセッション、あるいは別のエージェントが、そのコンパクトなインデックスを読み、リポジトリと git 履歴と突き合わせ、完了済みの作業をやり直すことなく最初の未完了タスクから続行します。中断された計画の作成すら復元できます。計画の識別情報と意図されたタスク一覧はどのタスクファイルより先に書き込まれるため、作成途中の計画は、推測に委ねられるのではなく、完了させるか破棄できるのです。

コアループ

すべての計画に課される、ただ一つの必須の締めタスクです。順に、計画の累積変更セット全体に対するセキュリティパス（AI Diff Reviewer スキルによる必須のローカル diff レビューを含み、重大な発見は修正されるか明示的に受け入れられるまで完了を阻止します）、最終状態の検証（最終コードに対するリポジトリの適用可能なテスト・リント・型チェック・フォーマットのスイート全体）、そして各タスクが記録したスキル決定の突き合わせです。その後エージェントは成果物・証拠・制限を報告し、Executive Report を一度だけ提案し、あなたが求めた場合にのみ生成します。

仕様を読む

ゲートの失敗はまず修復の合図です。エージェントはタスク自身のスコープ内に収まるものを修正し、ゲートを再実行します。そのスコープを超える失敗はタスクをブロックとして記録し、エージェントは完了を主張する前に停止します。証拠を確認し、コードを修正するかタスクをリファインしたうえで再開できます。失敗したコマンドは不整合を解消せよという合図であり、ゲートを緩めてよいという許可ではありません。

エージェントプロトコルを読む

それを明確に示します。チェッカーは終了コード 2 と明示的な `UNVERIFIED` 判定で終わります——実際に検証していない合格を出力することは決してありません。環境に有能なインタープリターがなかったり、チェックを実行できない場合は、誠実な結果は「適合」ではなく「未検証」です。グリーンの結果は、常にすべてのチェックが実行されて通過したことを意味します。同じ規律は方法論全体を貫いており、完了を宣言するためにゲートを弱めたり偽装したりするフローは存在しません。

適合性の契約

できます。計画が事前に承認され、必須の状態レイヤーを備え、エージェントに範囲の定まった権限を与えている場合です。無人実行は、現実が計画から乖離したとき、ゲートが計画された修復範囲の外で失敗したとき、あるいは新たな承認や認証情報が必要になったときには、停止してブロッカーを記録しなければなりません。

無人実行プロトコルを読む

はい——オーケストレーターハブのアーキタイプはまさにそのために存在します。ハブリポジトリが調整する計画を保持し、各子リポジトリは自分の隔離された `.dwp/` ワークスペースの中で自分の計画を実行するため、子がハブの計画状態に書き込むことは決してありません。子の完了状態は内部の文字列照合ではなく、各計画自身の最上位状態から読み取られ、ハブはどこへ移動する前にも自分の位置を記録します。各子は通常の DWP リポジトリのままで、単体で操縦することもできます。

リポジトリのアーキタイプ

これらは隣接する問題を解きます。仕様駆動ツールは、何を変更すべきかを捉えるのが得意です。仕様、要件、変更提案を繰り返し可能なかたちでまとめます。Deep Work Plan が扱うのは、エージェントがドリフトせずに何時間も実行し続ける方法です。オンボーディングされたハーネス、変更対象面から選ばれるタスクごとの検証ゲート、ディスク上の再開可能な状態、セキュリティパスを伴う必須の Final Review、そしてリポジトリ自身のための適合性チェッカーです。両者は組み合わせられます。仕様や変更提案が計画に流れ込む構成です。比較ページは、各ツール自身の言葉でケイパビリティを並べて示します。

比較を見る

BMAD、Superpowers、Get Shit Done のようなエージェント・ワークフローフレームワークは、役割・原則・テストファーストのステップ・検証の習慣といった強い作業スタイルをもたらします。Gentle-AI は隣接するカテゴリに位置し、エージェントエコシステムの構成ツールとして機能します。すでに使用しているコーディングエージェントに、セッションをまたぐ永続メモリ（Engram）、厳選されたスキル、ペルソナ、MCPサーバー、任意のSpec-Driven Development、任意の証拠に基づくレビュー(Receipt-Driven Development)を装備し、各エージェントの設定ディレクトリに書き込みます。Deep Work Plan はその両方と異なり、リポジトリに何が残り、何を検査できるかに焦点を当てます——どのエージェントも初見で読めるharness、受け入れ基準とgateを備えたタスクファイル、セッションを超えて存続する状態、CIフレンドリーな終了コードを持つ適合性チェッカー、そして各フローが読み込む命令バイト数の公開された測定です。構造上ツールに依存せず、コアループにサービス、プロバイダー、シークレットを一切追加しません。これらの層は共存できます：フレームワークとGentle-AIはエージェントの働き方を形づくり、Deep Work Planは長時間の作業をリポジトリ内で持続的かつ検証可能にします。比較ページは、各アプローチが組み込み済みか、任意か、対象外かを示します。

比較を見る

内蔵プランモードは有用であり、Deep Work Plan も同じ基盤——`AGENTS.md` 規約とオープンな Agent Skills 標準——の上に築かれています。違いは、計画がどこに存在し、何がそれを強制するかです。ネイティブの計画は通常リポジトリの外にあり、セッションとともに失効します。Deep Work Plan は計画もその状態も証拠もリポジトリに書き込むため、別のエージェントやチームメイトが続きを実行でき、すべてのタスクが実行可能なゲートと記録されたログを持ちます。考えるためのエージェントのプランモードはそのまま使い、方法論がその上に永続的で検証可能な実行ループを加えます。

比較を見る

オンボーディングは非破壊的です。既存の `AGENTS.md`、`docs/`、`.agents/`、`CLAUDE.md` を検出し、上書きではなく調整し、何かを置き換える前には確認を求めます。実際のコマンドを備えた `AGENTS.md` インデックス、推論にもとづく `docs/` ツリー、モジュールごとのドキュメント、薄い `dwp-*` コマンドを備えた `.agents/` キット、gitignore された `.dwp/` 出力領域、検証済みのテストマップ、そして必須のローカルコードレビュー（AI Diff Reviewer スキルとリポジトリ仕立てのレビュー拡張）を書き込みます。その後セルフチェックと適合性チェッカーを実行するため、何が生成されたかを確認できます。より前の標準でオンボーディングされたリポジトリには、欠けているか古くなっているものだけを調整する、対象を絞ったハーネスアップグレードが適用されます。

採用エンドポイント

2 種類のアップグレードがあり、フローはそれらを分けて扱います。リポジトリハーネス——`AGENTS.md`、`docs/`、`.agents/` キット——はオンボーディングの再実行によって調整され、欠けているか古くなったものだけを埋めます。スキル自体は `/dwp-upgrade` で移動します：最新の公開リリースを読み取り専用で確認し、あなたが受け入れた正確なタグを検証してインストールし、その後オンボーディングを最初からの実行としてやり直します。フロー全体を通じて明示的な同意が求められ、ローカルの適応は上書きではなく差分比較して保持され、`.dwp/` は決して移行されません——既存のプランは記録された形のまま動き続けます。

採用エンドポイント

できます。アドオンはオプトインのレイヤーであり、一つも導入していないリポジトリも完全に DWP 準拠です。Devcontainers、Dailybot レポーティング、依存関係のアップグレード、デザインシステム対応、そしてオプションの CI レビューは、あなたのリポジトリに適合し、あなたが明示的に受け入れた場合にのみ提供されます。

アドオンを見る

DWP は、ツールチェーンがないことを免罪符として扱いません。オンボーディング中にエージェントは、あなたのスタックに適した検証セットアップを提案し、そのコマンドをリポジトリのドキュメントに記録し、以後のゲートの目標としてそれらのコマンドを使用します。その提案はあなたがレビューできるよう、そのまま見える状態で残ります。

エージェントプロトコルを読む

方法論とスキルは MIT ライセンスで無料です。中核のフローにサービスも API キーもテレメトリーもありません。効率は、各フローが**入口**で読み込む指示バイト数——セッション開始時点のバンドル——として報告され、これと並んで、実際の作業が進んだ際にそのフロー自身のトリガーが読み込む分を加えた**エンドツーエンドのパス**が名前つきで公開されます(たとえば、実行まで進む resume は、通常その入口バンドルの数倍を読み込みます)。どちらの数値もセッションの上限ではありません。実際の実行では、リポジトリ自体のファイル、ツールの出力、計画の作業ファイルも読み込まれますが、この台帳はそれらを一切数えていません。両方の数値は、スキルとともにコミットされたスクリプトによって計測され、リリースのベースラインごとに再計測され、評価台帳として公開され、増加は減少と同じようにはっきり報告されます。バイトの目録はそれらを立証しないため、トークンのパーセンテージやコスト削減として報告されることはありません。凍結されたプロトコルの下、公開のフレッシュエージェント評価がすでに実行されました：同じ2つの機能を、ハーネスなし・前のメジャーバージョン・現行版のクリーンなクローンでそれぞれ構築したものです。その結果、ハーネスを持つツリー上のエージェントは両タスクでより少ないバイトを読み、現行版の機能セッションは両タスクで前のメジャーバージョンより少ないモデル入出力を消費しました——ハーネス報告による、単一ワークロードでの値です。同時に正直な限界も判明しました：オンボーディングは一回限りのコストであり、フローが使われて初めて回収されること、ワークロードごとのトークンの純方向は混在していたこと、ウォールクロックの優位は主張しないこと、そしてフレッシュなエージェントは自力ではフローに入らないこと——フローはあなたか、呼び出し方を知るエージェントが実行するコマンドです。

信頼と開示