Write Plan

概要

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

このスキルは計画作成のみです：

• コードを実装しない
• 本番ファイルを変更しない（計画アーティファクトを除く）

ワークフロー

ステップ 1：文脈化

共有の Context Loading Protocol に従ってプロジェクト文脈を読み込みます。次に、リクエストされた変更に関連するコード領域のみを検査します。

以下を記録します：

• ユーザー向けの目的と予期される結果
• 従うべき既存パターン
• 制約と依存関係
• 実行者を導くファイル、モジュール、コマンド、ドキュメント
• リスク、前提、不明な点

ステップ 2：計画アーティファクトの初期化

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

ルール：

• 共有の General Principles からタイムスタンプコマンドを使用してフォルダとドキュメントのタイムスタンプを設定します。

ステップ 3：要件の明確化

リクエストの曖昧性を解決するために、澄ましい質問をします。以下に焦点を当てます：

• スコープと境界
• 成功基準
• 制約と対象外
• 優先度とトレードオフ

ルール：

• 要件がすでに明確な場合、またはブレインストーム文脈からの場合、確認ステップは不要です。
• 回答と文脈の収集に Question Tool を使用します。
• SUMMARY.md で前提を明示的に述べます。リクエストの複数の解釈が存在する場合は、それをリストアップして質問してください。黙って選択しないでください。

ステップ 4：戦略とフェーズの定義

安全で検証可能なフェーズ戦略を設計します。

各フェーズは以下を含む必要があります：

• 明確な目的
• フェーズに適切な複雑さとリスクレベル（値：S、M、L、XL）
• 順序付けられたタスク
• 検証コマンド
• 観測可能な受け入れ基準と終了基準

粒度ルール：

• タスクは小さく、具体的で、通常 2～10 分程度である必要があります。
• 安全に再開できるフェーズを優先します。リスクのある作業については、冪等性、復旧ノート、またはロールバック制約をドキュメント化します。

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

調査はオプションで、不確実性に比例している必要があります。

推奨される順序：

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

外部調査機能が利用できない場合は、ローカル証拠で進め、前提と未解決の質問を明示的にリストアップします。

調査結果をドキュメント化します：

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

ステップ 6：計画コンテンツの作成

SUMMARY.md の形式

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

要約は静的な提案ではなく、生きた計画である必要があります。実行時の更新のための空のセクションを含めます：進捗、発見/驚き、決定ログ、結果/振り返り。これらのセクションにより、execute-plan が何が変わり、なぜ変わったかを記録する安定した場所が得られます。

phase-XX-<name>.md の形式

references/phase-template.md 内のテンプレートに従います。

ステップ 7：レビューと改善

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

• パスは正確で一貫性がある
• フェーズの順序は論理的である
• タスクは実行可能である（曖昧なステップがない）
• 各フェーズで検証が定義されている
• 受け入れ基準は観測可能である
• リスク/前提は明示的である
• 計画は現在のチャットの隠れた文脈なしで実行可能である

その後、ユーザーレビュー用に提示します。

複数の実行可能なアプローチが存在する場合は、オプションを提示し、以下のいずれかを求めます（Question Tool を選択に使用）：

• Confirm：現在の計画を実行承認
• Confirm and Visualize：現在の計画を承認し、同じセッション内でソース隣接の可視化を作成
• Validate：追加の明確化質問を通じて改善

ユーザーが Confirm and Visualize を選択した場合：

1. 現在の write-plan セッション文脈と作成したばかりの計画アーティファクトを使用します。
2. プロジェクト文脈読み込みを再開したり、セッションで既に利用可能な背景を再発見したりしないでください。
3. 計画フォルダの visualize スキル出力規約に従います：
   • docs/plans/YYMMDD-HHmm-<plan-slug>/visualize.html
   • docs/plans/YYMMDD-HHmm-<plan-slug>/visualize-assets/
4. 固定された可視化テーマを隣接アセットフォルダにコピーします。
5. HTML、ローカル CSS リンク、Mermaid インポート、ソースメタデータ、主要コンテンツブロックが存在することを確認するのに十分な可視化を確認します。
6. その後、通常のハンドオフに進みます。

ステップ 8：ハンドオフ

以下で終了します：

計画 <relative_path_to_plan>/SUMMARY.md の準備ができました。
/clear を実行し、次に /execute-plan <relative_path_to_plan>/SUMMARY.md を実行して実行してください。

可視化が作成された場合は、以下も含めます：

可視化 <relative_path_to_plan>/visualize.html の準備ができました。

ルール

• 同じセッション内で自動的にコード変更を実装または実行しないでください。オプションの計画可視化は、ユーザー選択後で、計画アーティファクトのみに対してのみ許可されます。
• 明示的なファイルパスと具体的なコマンドを優先します
• プロジェクト標準と既存アーキテクチャに合わせます
• 計画を自己完結型、決定的、再開可能に保ちます。新しいエージェントが計画フォルダだけから続行できる必要があります。
• **最小限の実行可能な変更を計画します：**投機的なフェーズなし、「念のため」の抽象化なし、リクエストされていない柔軟性なし。計画が 6 フェーズではなく 3 フェーズで済む場合は、3 にします。すべてのタスクは、述べられた要件に直接追跡可能である必要があります。
• write-plan リクエストがブレインストームセッションから来た場合、ドキュメント収集、要件の明確化、調査などの多くのステップをスキップできます。これらはブレインストームセッションでカバーされるべきだからです。その場合、ステップ 4：戦略とフェーズの定義から直接開始し、ブレインストームセッションからの情報を文脈として使用できます。