write-plan

計画の作成

概要

execute-planで実行できる、完全で自己完結した実装計画を作成します。/clearの後や別のエージェントが実行する場合でも、曖昧さを最小限に抑えます。

このスキルは計画専用です。

• コードを実装しないでください
• 計画の成果物を除き、本番ファイルを変更しないでください

ワークフロー

ステップ 1：背景を把握する

依頼された変更に関連するプロジェクトの情報だけを読み込みます。

• docs/SUMMARY.mdが存在する場合は、最初に読みます。
• タスクに関連する詳細ドキュメントだけを読み込みます。
• 実装規約については、Code Standardドキュメントを優先します。
• ドキュメントの内容がコードやユーザーの意図と矛盾する場合は、広範な変更を行う前に、利用可能な入力／質問ツールを使用します。

次に、依頼された変更に関連するコード領域だけを確認します。

以下を記録します。

• ユーザーに見える目的と期待される結果
• 従うべき既存のパターン
• 制約と依存関係
• 実行担当者の理解に役立つファイル、モジュール、コマンド、ドキュメント
• リスク、前提条件、未解決の点

ステップ 2：計画の成果物を作成する

1. docs/.plans/YYMMDD-HHmm-<plan-slug>/を作成します。
2. 以下を作成します。
   • SUMMARY.md
   • 実装フェーズごとに1つのフェーズファイル。命名規則はphase-XX-<name>.mdです。
3. 必要な場合に限り、research/を追加します。

ルール：

• フォルダーとドキュメントのタイムスタンプには、共有の General Principles に記載されたタイムスタンプコマンドを使用します。

ステップ 3：要件を明確にする

依頼に曖昧さがあれば、それを解消するために確認の質問をします。以下に焦点を当てます。

• 範囲と境界
• 成功基準
• 制約と対象外事項
• 優先順位とトレードオフ

ルール：

• 要件がすでに明確な場合、またはブレインストーミングの文脈から得られる場合は、確認のステップは不要です。
• 回答や背景情報を得るには、入力／質問ツールを使用します。
• 前提条件はSUMMARY.mdに明記します。依頼に複数の解釈がある場合は、それらを列挙して質問してください。黙って解釈を選ばないでください。

ステップ 4：方針とフェーズを定義する

安全に実行でき、検証可能な段階的方針を設計します。

各フェーズには、以下を含めます。

• 明確な目的
• フェーズに適した複雑さとリスクレベル。値はS、M、L、XLのいずれかです。
• 順序付けされたタスク
• 検証コマンド
• 観察可能な受け入れ基準と終了基準

粒度に関するルール：

• 各タスクは小さく、具体的にします。
• 安全に再開できるフェーズを優先します。リスクの高い作業については、冪等性、復旧に関する注意事項、またはロールバックの制約を記載します。

ステップ 5：調査する（必要な場合のみ）

調査は任意です。不確実性に応じた範囲にとどめてください。

推奨する優先順位：

1. 既存のプロジェクトドキュメントとコード
2. 既存のスキルとローカルの参照資料
3. 外部資料（現在の環境で利用可能な場合のみ）

外部調査機能が利用できない場合は、ローカルで得られる情報に基づいて進め、前提条件と未解決の質問を明記します。

調査結果は以下に記録します。

• docs/.plans/YYMMDD-HHmm-<plan-slug>/research/<topic>.md

ステップ 6：計画の成果物を作成する

• SUMMARY.mdの形式 references/summary-template.md内のテンプレートに従います。

• phase-XX-<name>.mdの形式 references/phase-template.md内のテンプレートに従います。

• スキルvisualizeを使って計画を図示します。ただし、--non-visualizeが指定されている場合は、図示を省略します。

ステップ 7：レビューして改善する

計画を提示する前に、以下を確認します。

• パスが正確で、一貫している
• フェーズの順序が論理的である
• タスクが実行可能である（曖昧な手順がない）
• 各フェーズの検証方法が定義されている
• 受け入れ基準が観察可能である
• リスクと前提条件が明記されている
• 現在のチャットに隠れた情報がなくても計画を実行できる

その後、ユーザーにレビューを依頼します。

実行可能なアプローチが複数ある場合は、選択肢を提示して、次のいずれかを選ぶよう依頼します（選択には入力／質問ツールを使用します）。

• 承認：現在の計画を承認して実行に進みます
• 検証：追加の確認質問を通じて計画を改善します

ステップ 8：引き継ぎ

最後に、次を記載します。

Plan `<relative_path_to_plan>/SUMMARY.md` is ready.

図示を作成した場合は、以下も記載します。

Visualization `<relative_path_to_plan>/visualize.html` is ready.

ルール

• 同じセッション内でコード変更を自動的に実装または実行しないでください。ユーザーが選択した後に限り、計画の成果物のみを対象とした計画の可視化は任意で許可されます。
• 明示的なファイルパスと具体的なコマンドを優先してください。
• プロジェクトの規約と既存のアーキテクチャに合わせてください。
• 計画は自己完結型で、決定論的で、再開可能なものにしてください。新しいエージェントが計画フォルダーだけを使って続行できる必要があります。
• 実行可能な最小限の変更を計画してください： 推測に基づくフェーズ、「念のため」の抽象化、要求されていない柔軟性は含めないでください。計画を6フェーズではなく3フェーズで実行できるなら、3フェーズにしてください。すべてのタスクは明示された要件に直接結び付いている必要があります。
• 成果物は現在のセッションと同じ言語で作成してください。