writing-plans

計画の作成

引き継ぎ前に、実装に関するすべての判断を確定します。実行者はコードを作成し、 プランナーは、アプローチを選ぶ必要がなくなるよう、契約、手順、パターン、および 証明を明確にします。計画には、本番コードやテスト本体の全体を含めないでください。 曖昧さを解消するために必要な場合に限り、シグネチャ、データ例、または簡潔な アルゴリズムを記載します。

入力：要件、対象リポジトリ、現在の Issue またはドキュメント、およびスコープの制約。出力：要件と調査済みのリビジョンに紐づく最新の実装計画を1つ。判断事項を解決し、正確なパス／シンボル、順序付きの手順、検証との対応、および作業可否を示すブロッキングな準備状況の結果を含めます。

書き込み先：要件 Issue の ## Implementation Plan コメント、または単一の正本となるローカルドキュメントの計画セクション。ただし、許可された公開範囲内に限ります。実装ファイルへの書き込みや、自律的な実行者のディスパッチは行いません。リポジトリとトラッカーを読み取ります。不足している権限、または重要な意図の確認だけを求めてください。この Issue の計画作成に対する許可はすでにその範囲をカバーしているため、承認を繰り返し求める必要はありません。公開を調整プロセスが担う場合は、下書きをそのプロセスに返します。

任意の補助ツール：prd-quality-gate（正本となる計画テンプレートと実行準備状況の確認）および executing-plans（scripts/plan-header.mjs）。どちらもこのスキルには含まれていません。利用できない場合は、以下のチェックリストを準備状況の確認に使い、ベースコミットと要件テキストのハッシュを手動で記録してください。

契約

入力：

• 要件、対象リポジトリ、現在の Issue／ドキュメント、およびスコープの制約。
• ハーネスが選択したプランナーと、許可された公開範囲。

出力：

• 要件と調査済みのリビジョンに紐づく最新の実装計画を1つ。
• 解決済みの判断事項、正確なパス／シンボル、順序付きの手順、検証との対応、および 作業可否を示すブロッキングな準備状況の結果。

作成／変更：

• 許可された、要件 Issue の ## Implementation Plan コメント、または 単一の正本となるローカルドキュメントの計画セクション。
• 実装ファイルへの書き込みや、自律的な実行者のディスパッチは行いません。

外部への副作用：

• リポジトリ／トラッカーの読み取り、および許可された計画の公開。

確認が必要な場合：

• 不足している権限、または重要な意図の確認だけを求めます。この Issue の準備または 計画作成に対する許可はすでにその範囲をカバーしているため、承認を繰り返し求める必要は ありません。公開を調整エンジンが担う場合は、下書きを返します。

委任先：

• 委任先を実行するには、同階層にある ../<name>/SKILL.md を読み、その指示に従います。 ここにあるスキルはユーザーが呼び出すものに限られるため、Skill ツールでは読み込めません。
• 正本となる計画テンプレートと実行準備状況の確認には prd-quality-gate を使用します。

調査して決定する

1. 現在の要件と関連コメント、リポジトリの指示とアーキテクチャ、現在のリビジョン、既存の実装を確認します。利用可能な場合は、prd-quality-gate から標準の実行準備状況リファレンスを読み込みます。
2. 既存のパス／シンボルと、近接するパターンを少なくとも3つ特定します。見つからない場合は、調査した範囲と得られた証拠を記録します。提案するファイルとシンボルには明示的にラベルを付けます。推測に基づく再構成は行わず、リポジトリのアーキテクチャに従います。脆弱な行番号だけでなく、関連するソースの証拠を含めます。
3. 該当する場合は、アーキテクチャ、インターフェース、データ形式、検証、認可、並行処理、エラー、互換性、UI の状態、移行、ロールアウトの動作をすべて確定します。名前と具体的なルールを明記し、「適切に処理する」「ライブラリを選ぶ」「ベストプラクティスに従う」などの表現は避けます。
4. 機能全体を1つの計画とイシューにまとめます。技術レイヤーはステップとして扱い、完了チケットを分けません。分割が必要な場合に限り、共通の独立成果ルールを適用し、親の受け入れ条件と統合作業の義務を維持します。
5. 各ステップに、正確なファイル／シンボル、変更内容、選択したパターンと判断の参照先、前提条件、完了条件を記載します。固定の作業時間や小さな編集ごとのコミットではなく、論理的なステップの粒度を選びます。標準テンプレートを使って、すべてのステップに Touch（生成された出力を含む、許可されたすべてのパス）、Pattern（既存のパス／シンボル、判断 ID、または理由を添えた None）、Check（正確なコマンド、実行ディレクトリ、期待結果）、Stop if（プランナーへのエスカレーションが必要な条件）を必ず記載します。実行担当者が編集できるのは Touch のパスだけです。
6. 要件から想定されるものの、チェックではまだカバーされていない、最も重大な入力クラスまたは障害モードを特定します。それぞれを担当ステップと具体的なフィクスチャに紐付けます。該当するものがない場合は、確認済みで該当なしと記録します。すべての受け入れ ID を、判断、ステップ、具体的なチェックに対応付けます。コマンド定義と CI 設定を調査し、実行ディレクトリ、許可された実行環境、環境／フィクスチャ、期待結果を記録します。新しいテストを提案する場合は、正確なパス、動作／フィクスチャ、検証済みのテストランナーを使った実行方法を示します。テストコード全体は記載しません。
7. 再現可能なベースコミット、要件のフィンガープリント、計画のリビジョンを記録します。スクリプトが利用可能な場合は、保存したイシュー本文に対して executing-plans の scripts/plan-header.mjs digest コマンドを使ってフィンガープリントを計算します。すべての準備状況チェックに合格したら、ドラフトの Readiness: READY に設定し、公開前に現在のヘッドに対して plan-header.mjs check（利用可能な場合）が合格することを確認します。プランナーが解決すべき未知事項はすべて解決します。ユーザーが決定すべき意図や、利用できない前提条件は、下位の実行担当者に選択を委ねず、明示的なブロッカーとして残します。

レビュー、保存、引き継ぎ

ブロッキングの execution-readiness モードで prd-quality-gate を実行するか、上記のチェックを手動で適用します。網羅性の不足、名前や契約の不整合、曖昧な選択、未検証のコマンド前提を修正します。見出しだけの確認結果ではなく、証拠を添えて判定を返します。

既存の認可範囲内で公開するか、ドラフトをコーディネーターに戻します。要件はイシュー本文に記載し、現在の ## Implementation Plan コメントをそのイシューに1つだけ残します。共通のメタデータおよび鮮度プロトコルに従います。現在のコメントへのリンクを示し、古い計画は明示的に置き換えます。ラベルのないコメントに、曖昧な計画を分割して記載してはいけません。トラッカーの上限を超える場合は、判断を切り捨てるのではなく、重複を減らすか、真に独立した成果に分割します。

イシュー／計画のリンク、調査したリビジョン、準備状況の判定、ブロッカーを報告します。ディスパッチ用ラベルを捏造したり、実行方針をユーザーに選ばせたりしません。実行前に、最新の鮮度検証を必須とします。実装上の不足があればプランナーに戻し、実行担当者が判断や受け入れ条件を修正することはできません。