Skip to content
Deep Work Plan が本日 Product Hunt に登場 応援する
← すべての仕様ドキュメント

適合性

バージョン 1.3。状態: 安定。 この文書は、リポジトリが Deep Work Plan に適合している とはどういうことか、すなわち AI-first でエージェントが操縦できるとはどういうことかを定義します。キーワード MUST、MUST NOT、SHOULD、SHOULD NOT、MAY は、RFC 2119 に記述されたとおりに解釈されます。

適合性が存在するのは、「AI-first」が印象ではなく、客観的で確認可能な性質であるためです。リポジトリは以下の基準を満たすか、満たさないかのいずれかです。verify サブスキル（/dwp-verify）がそれらを機械的に確認します。

適合したリポジトリ

DWP に適合したリポジトリは、以下のすべてを満たさなければなりません（MUST）。すべての成果物は、その実際の言語、フレームワーク、コマンドに適応された、リポジトリのために推論されたものでなければなりません（MUST）。汎用のひな形、プレースホルダー、あるいは別のリポジトリからコピーされた内容は、基準を満たしません。

  1. ルートの AGENTS.md。 リポジトリは、(a) ドキュメントの索引、(b) リポジトリの必須ルール、(c) コマンドがこのリポジトリで実際に存在し実行可能な Quick Commands ブロックを含むルートの AGENTS.md を含まなければなりません（MUST）。プレースホルダーのコマンド（たとえば npm を使わないリポジトリでの npm test）は現れてはなりません（MUST NOT）。索引は存在しない docs/ ファイルにリンクしてはならず（MUST NOT）、このファイルは 150〜500 行の予算内に収まり（SHOULD）、無制限に増大するのではなく詳細を docs/ に移してリンクすべきです。
  2. CLAUDE.md は AGENTS.md に解決される。 CLAUDE.md は存在し、AGENTS.md に解決されなければなりません（MUST）（シンボリックリンク、または単一の信頼できる情報源を保証する同等のもの）。両者は食い違ってはなりません（MUST NOT）。
  3. docs/ 階層。 リポジトリは、標準的なカテゴリ（アーキテクチャ、規約、テスト、開発コマンド、セキュリティ、エージェントのオンボーディング）を、実際のリポジトリ固有の内容でカバーする docs/ ディレクトリを含まなければなりません（MUST）。複雑なモジュールは独自の README.md を備えるべきです（SHOULD）。テストガイドは、実際のテスト、リント、型チェックのツールチェーンを——あるいは、それを持たないリポジトリについては、オンボーディング中にスタックから提案された具体的なセットアップを——定義しなければなりません（MUST）。空のテストガイドや「テストなし」はこの基準を満たしません。挙動を検証する定義された方法がなければ、計画は客観的な検証ゲートを持ちません。
  4. .agents/ 拠点。 リポジトリは、agents/、commands/、skills/ を備えた .agents/ ディレクトリと、ディスク上にあるものと一致する .agents/docs/ 配下のカタログを含まなければなりません（MUST）。dwp-* コマンドは、インストールされたスキルへの薄い委譲でなければなりません（MUST）。.claude パスは .agents に解決されなければなりません（MUST）。
  5. gitignore された .dwp/ 作業領域。 リポジトリは、plans/ を備えた .dwp/ ディレクトリを含まなければならず（MUST）、.dwp/ は gitignore されていなければなりません（MUST）。tmp/ スクラッチ領域は存在すべきであり（SHOULD）、gitignore されているべきです（SHOULD）。
  6. 方法論スキルが解決可能。 Deep Work Plan スキルは、リポジトリ内のエージェントがそのサブスキルを呼び出せるよう、インストールまたは参照されていなければなりません（MUST）。

リポジトリはオプションアドオンがゼロでも完全に適合します。オプションアドオン（devcontainer、Dailybot、dependency-upgrade、design-system）は、適合性のために必須であってはなりません（MUST NOT）。標準 2.3.0 以降、AI Diff Reviewer ローカルレビュー（vendored スキル + 拡張ファイル）はベースラインの一部です。2.3.0 以降を宣言するリポジトリではその不在が失敗であり、レガシーリポジトリではハーネスバージョンの発見となります。CI サーフェスはオプションのままです。

よく形成された計画

.dwp/plans/ にある Deep Work Plan は、次のときによく形成されています。

  1. すべてのタスクは、明示的なスコープ、受け入れ基準、そして少なくとも一つの検証ゲート（客観的に合格または不合格になるコマンドやチェック）を宣言しなければなりません（MUST）。
  2. 新しい中核機能を追加したり、プロダクトの挙動を変更したりするすべてのタスクは、その受け入れ基準にその挙動に対する自動テストの網羅を含めなければならず（MUST）、その検証ゲートで、ビルドだけでなく、リポジトリのテストをそのリントと型チェックのチェックとともに実行しなければなりません（MUST）。既存のテストはグリーンを保たなければなりません（MUST）。挙動変更は、壊したテストを削除したりスキップしたりするのではなく、更新しなければなりません（MUST）。純粋なドキュメント、設定、または調査のタスクは、テストの作成を免除されますが、それでもリポジトリのゲートを実行します。
  3. 認証、入力処理、シークレットや設定、ネットワーク面、または依存関係に触れるすべてのタスクは、その変更のセキュリティ上の期待を受け入れ基準に含めなければならず（MUST）、すべてのコミットはシークレット素材を含まないものでなければなりません（MUST）。
  4. 計画は、作業が中断を生き延び、別のエージェントによって再開できるよう、進捗を永続化しなければなりません（MUST）。タスクは、その検証ゲートのレコードのいずれかがなお失敗した未解決の実行を示している間は completed として記録されてはならず（MUST NOT）、タスク自身の完了ログは、その記録された状態と矛盾してはなりません（MUST NOT）(たとえば completed のタスクのログがなお「Status: pending」と読める場合、それは合格ではなく欠陥です)。
  5. 計画は記録された最終レビューで締めくくらなければなりません（MUST）。このバージョンのもとで書かれた計画は、ちょうど一つの必須 Final Review — セキュリティパス、最終状態の検証、そしてスキルの決定の突き合わせ — で終わらなければなりません（MUST）。より前のバージョンのもとで書かれた計画は三つの必須最終タスク（Security Review、Skills & Agents Discovery、Executive Report）で終わり、引き続き適合です。重大なセキュリティ上の発見は、修正されるか明示的に受け入れられるまで完了を阻止します。完了そのものは、単なる状態の切り替えではなく、検証され復旧可能なトランザクションです。終端タスクは、状態を書き込む前に完了した計画のすべての成果物に照らして検証するガードされた公開ステップを通じて締めくくられ、機械でチェック可能な FINALIZATION.json の受領票を残します。中断された公開は証拠から復旧されるのであって、黙って完了済みと再宣言されることは決してありません。ゲートレコードが指し示す証拠へのポインターはいずれも、計画自身のフォルダー内で解決しなければならず(MUST)、宙に浮いた、あるいは範囲外へ逃げるポインターは、合格の証拠ではなく発見です。
  6. タスクは、長期にわたる逸脱を防ぐため、実行の前に計画の目標へと改めて立ち返るべきです（SHOULD）。

適合性の検証

適合性は、目視ではなく機械的に検証されるべきです（SHOULD）。/dwp-verify を実行すると、上記の基準に照らした合否レポートが生成されます。すなわち、AGENTS.md の存在と実内容、CLAUDE.md の解決、docs/ のカテゴリ、.agents/ のカタログとディスクの一致、.dwp/ と tmp/ の gitignore 状態、そして計画については、すべてのタスクが受け入れ基準と検証ゲートを備えていること、挙動を変更するタスクについてはテストの網羅を伴い、記録された最終レビューが存在していることです。計画については、計画の Markdown とその機械可読な状態が一致していること(README と state.json のデシンクは、決して黙って見逃されるのではなく、発見として扱われます)、完了したタスクが矛盾のないゲートとログの証拠を備えていること、そして——完了した計画がそこに到達している場合——公開の受領票がその主張する完了を裏づけていることも確認します。チェッカーはバージョンを認識します：レガシーの計画（三つの必須最終タスク、変更対象面なし）を適合として受け入れなければならず（MUST）、このバージョンを宣言しながらその下で客観的に無効な計画を拒否しなければなりません（MUST）。また、欠落または古い DWP standard: の由来行を、対象のハーネスアップグレードを名指する発見として報告します。 機械的レイヤーは自らの限界に誠実です：有能なインタープリター（Python 3.9+）がない場合、チェックを飛ばすのではなく、ゼロ以外の終了コードと明示的な UNVERIFIED 判定とともに終了します — 検証器は検証していない結果を決して報告しません。

リポジトリは、適合性が一度きり主張されるのではなく維持されるよう、オンボーディングのあと、そして各計画の完了のあとに再検証されるべきです（SHOULD）。