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

ドキュメント標準

バージョン 5.0.0。 この標準は、Deep Work Plan がその構造、タスク、進捗をどう文書化するか、そしてエージェントが安全に行動できるようリポジトリ自身がどう自己文書化するかを定義します。DWP 方法論のもとで作成されるすべての計画に適用されます。このバージョンは、この文書自身のバージョンを、それが付随する DWP 標準と揃えるものです——既存の要件はいずれも変更されません——また、以下に述べる lean-index 予算の強制と feature 層を追加します。キーワード MUST、SHOULD、MAY は RFC 2119 に定義されたとおりに用いられます。

コンパクトなエントリーポイントとしての AGENTS.md

ルートの AGENTS.md ファイルは、150〜500 行の予算内に収まるべきです(SHOULD)。生成された、またはハーネスが維持するコンテンツがこれを超える場合、エージェントはその詳細を、それを所管する docs/ ガイド(またはモジュール/フィーチャーのドキュメント)へ移し、索引からリンクしなければなりません(MUST)——何も失われず、移動するだけであり、索引は移された内容を受け取ったすべてのドキュメントにリンクしなければなりません(MUST)。予算を超えた既存の手書き AGENTS.md が黙って書き換えられることは決してありません。エージェントは具体的な移行案(何をどこへ移すか、どのリンクを追加するか)を提案し、開発者の同意があって初めてそれを適用します。行数は客観的ですが著者性はそうではないため、適合性チェッカーはこの予算を助言的なものとして扱います——この MUST は、ファイルを生成または更新するハーネスを拘束するのであって、誰が書いたかについてのチェッカーの推測を拘束するものではありません。AGENTS.md は、存在しない docs/ ファイルにリンクしてはなりません(MUST NOT)。

モジュールごとのドキュメント層(下記)の上には、feature 層があります。一つのモジュールより大きい主要な機能領域は、そのコードの隣に専用の docs/ フォルダーを持ち、専用の README.md から入ります。ある領域は、二つ以上の主要モジュールにまたがる場合、自己完結したサブアプリやサブシステムのディレクトリを持つ場合、または複数のコンシューマーが依存する独自の契約(API サーフェス、イベントやスキーマの契約)を担う場合に該当します。ある領域が主要なものとして記録されたら、その feature 用 docs/ は存在すべきであり(SHOULD)、その中でも特に重要な項目は、それがまたがるモジュールとルートの AGENTS.md 索引の両方から、モジュールごとのドキュメントとまったく同じようにリンクされるべきです(SHOULD)。意図的に文書化されないままにされた領域には、記録された理由があります——見落としではなく、決定です。

計画の README

すべての計画は、次を含む README.md を備えなければなりません(MUST)。

  • タイトル# Deep Work Plan: <name>
  • 目標 — 計画の目的を散文で述べたもの。
  • 出典資料 — 正規の入力へのリンクやパス(任意)。
  • タスク — タスクの番号、名前、状態のチェックボックスを備えた Markdown の表。
  • 状態<n>/<total> tasks complete という形式の行。

タスクファイル

各タスクファイルは <n>.task_<slug>.md という名前で、十の節からなる構造を含まなければなりません(MUST)——従来の九つの節に 変更対象面(Touched Surface) を加えたもの:タスクが変更するものと検証されなければならないものとの契約(計画面と実際の面、影響を受けるコンシューマー、isolated(隔離)・seam(継ぎ目)・shared/core(共有/コア)・unknown(不明)のいずれかのリスククラス、使用したテストマッピング、そして選択されたゲートとその理由)。

PROGRESS.md

PROGRESS.md は追記専用の実行ログです。各エントリは次を記録しなければなりません(MUST)。

  • ISO 8601 のタイムスタンプ。
  • タスクの番号と名前。
  • 行ったこと。
  • あらゆる逸脱やスキップの理由。

状態マーカー

  • [ ] — 未着手。
  • [~] — 進行中。
  • [x] — 完了。
  • [!] — 阻害。

見出し

すべての見出しはセンテンスケースを用いなければなりません(MUST)。ドキュメントはマーケティング的な言い回しや感嘆符を避けるべきです(SHOULD)。

Final Review、タスク内スキル決定、そしてオプションのレポート

このバージョンのもとで書かれたすべての計画は、ちょうど一つの必須タスクで終わらなければなりません(MUST)。すなわち Final Review です — 計画の変更一式に対するセキュリティパス、最後の関連する状態に対する最終状態検証、そしてスキルの決定の突き合わせ。重大なセキュリティ上の発見は完了を阻止します。

  • タスク内スキル決定。 すべてのタスクの Completion & Log は**スキル処分(skills disposition)**を運びます — none(なし)、既存スキルまたはエージェントへの更新、名前付きの新規作成、あるいは理由と所有者を伴う見送りのいずれか。正当な作成は、その所有タスクの内部で、検証ゲートの前に、.agents/ カタログとの重複チェックの後に行われます。正当なエントリは、計画のスキル候補台帳に安定した候補(T{task}-{seq})として記録されます。
  • Executive Report はオプションで、要求に応じて。 完了時に一度だけ提案され、明示的な要求があった場合にのみ、永続的な証拠から生成されます。回答がない場合や無人実行の場合でも、計画はそれなしで完了します。
  • レガシーの計画。 より前のバージョンのもとで書かれた計画は三つの必須最終タスクで終わり、引き続き適合です — 適合チェッカーはそのかたちを受け入れなければなりません(MUST)。