Skip to content
← すべての仕様ドキュメント

適合性

バージョン 1.1。状態: 安定。 この文書は、リポジトリが 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）。
  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/ と drafts/ を備えた .dwp/ ディレクトリを含まなければならず（MUST）、.dwp/ は gitignore されていなければなりません（MUST）。tmp/ スクラッチ領域は存在すべきであり（SHOULD）、gitignore されているべきです（SHOULD）。
  6. 方法論スキルが解決可能。 Deep Work Plan スキルは、リポジトリ内のエージェントがそのサブスキルを呼び出せるよう、インストールまたは参照されていなければなりません（MUST）。

リポジトリはアドオンがゼロでも完全に適合します。アドオン（devcontainer、Dailybot、dependency-upgrade、design-system）はオプトインであり、適合性のために必須であってはなりません（MUST NOT）。

よく形成された計画

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

  1. すべてのタスクは、明示的なスコープ、受け入れ基準、そして少なくとも一つの検証ゲート（客観的に合格または不合格になるコマンドやチェック）を宣言しなければなりません（MUST）。
  2. 新しい中核機能を追加したり、プロダクトの挙動を変更したりするすべてのタスクは、その受け入れ基準にその挙動に対する自動テストの網羅を含めなければならず（MUST）、その検証ゲートで、ビルドだけでなく、リポジトリのテストをそのリントと型チェックのチェックとともに実行しなければなりません（MUST）。既存のテストはグリーンを保たなければなりません（MUST）。挙動変更は、壊したテストを削除したりスキップしたりするのではなく、更新しなければなりません（MUST）。純粋なドキュメント、設定、または調査のタスクは、テストの作成を免除されますが、それでもリポジトリのゲートを実行します。
  3. 認証、入力処理、シークレットや設定、ネットワーク面、または依存関係に触れるすべてのタスクは、その変更のセキュリティ上の期待を受け入れ基準に含めなければならず（MUST）、すべてのコミットはシークレット素材を含まないものでなければなりません（MUST）。
  4. 計画は、作業が中断を生き延び、別のエージェントによって再開できるよう、進捗を永続化しなければなりません（MUST）。
  5. 計画は、三つの必須最終タスク、すなわち Security Review、Skills & Agents Discovery、Executive Report を含まなければなりません（MUST）。重大なセキュリティ上の発見は、修正されるか明示的に受け入れられるまで完了を阻止します。
  6. タスクは、長期にわたる逸脱を防ぐため、実行の前に計画の目標へと改めて立ち返るべきです（SHOULD）。

適合性の検証

適合性は、目視ではなく機械的に検証されるべきです（SHOULD）。/dwp-verify を実行すると、上記の基準に照らした合否レポートが生成されます。すなわち、AGENTS.md の存在と実内容、CLAUDE.md の解決、docs/ のカテゴリ、.agents/ のカタログとディスクの一致、.dwp/ と tmp/ の gitignore 状態、そして計画については、すべてのタスクが受け入れ基準と検証ゲートを備えていること、挙動を変更するタスクについてはテストの網羅を伴い、三つの必須最終タスクが Security Review を含めて存在していることです。

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