計画とタスクのテンプレート

Deep Work Plan は Markdown ファイルのディレクトリです。そのディレクトリの形、そしてその中の各ファイルの形こそが、計画を人とエージェントの双方にとってレビュー可能なものにします。

計画の構造

プランのディレクトリ

• .dwp/
• plans/
• PLAN_<slug>/
• README.md 目的 ・ タスク表 ・ ステータス
• PROGRESS.md 追記のみの実行ログ
• 1.task_<slug>.md タスクファイル（十のセクション）
• 2.task_<slug>.md

計画は .dwp/plans/ 配下の PLAN_<slug>/ という名前のディレクトリです。次のものを含みます。

• README.md — 計画の概観。目標、出典資料、タスク表、状態。
• タスクごとに一つのファイル。<n>.task_<slug>.md という名前。
• PROGRESS.md — 実行の進行ログ。

タスクファイルの構造

各タスクファイルは <n>.task_<slug>.md という名前で、十の節からなる構造に従います。すなわち Goal、Context、Touched Surface（変更対象面）、Steps、Acceptance criteria、Validation、Files、Dependencies、Risks、Completion & Log です。各節は常にこの順序で現れるため、どの読み手もどこを見ればよいかが分かります。各タスクは行動の前に計画の目標へと改めて立ち返り、これにより、長く何時間にも及ぶ作業を通じてエージェントが逸脱するのを防ぎます。

Final Review

すべての計画は、ちょうど一つの必須タスクで締めくくらなければなりません。すなわち Final Review です。三つの順序づけられたパスで計画を閉じます — セキュリティパスで緩められるものは何もありません。

1. セキュリティパス — 計画が変更したすべてを、シークレット、インジェクションのリスク、新たな攻撃面について監査し、docs/SECURITY.md を最新に保ちます。セキュリティは最後に取って付けられる別個の作業の流れではありません。すべての計画は自身の変更を監査済みの状態で残し、重大な発見は完了を阻止します。
2. 最終状態検証 — リポジトリの完全な検証が、最後の修正の後の最終的な関連状態において実行されて合格します。
3. スキルの突き合わせ — 各タスクは証拠が新しいうちに自身のスキル処分を記録済みです。Final Review がその台帳を照合します。Executive Report は要求に応じて引き続き利用できます。

README と PROGRESS の規約

計画の README.md は、タイトル（# Deep Work Plan: <name>）、散文での目標の記述、任意の出典資料の節、タスク表（番号、タスク名、状態のチェックボックス）、そして <n>/<total> tasks complete という形式の計画状態の行を含まなければなりません。

PROGRESS.md は追記専用の実行ログです。各エントリには、ISO 8601 のタイムスタンプ、タスクの番号と名前、行ったこと、そしてあらゆる逸脱やスキップの理由を記録します。常に増えるだけなので、計画が実際にどう展開したかの信頼できる履歴になります。

見出しと相互参照

すべての見出しはセンテンスケースを用い、ドキュメントはマーケティング的な言い回しや感嘆符を避けます。これらの規約は、エージェントをまたいでも時間が経っても、計画を一貫したものに保ちます。