spec-kit-plan

機能仕様から技術的な実装計画を作成します。

入力：変更名を指定できます。省略した場合は、文脈から推測するか、ユーザーに確認します。 ユーザーがほかに追加する内容（希望する技術スタックや制約など）も、計画への入力となります。

手順

1. 変更を選択して成果物を読み込む

   specs/changes/<name>/spec.md を読み込みます。存在しない場合は、まず spec-kit-specify スキルを使用するよう提案します。

   また、FRAMEWORK.md（存在する場合は FRAMEWORK.local.md も）、有効な標準についてリンクされている機能文書、変更対象領域に関連する specs/features/ の文書、および変更を規定する specs/decisions/ の決定記録も読み込みます。

2. 不明点を調査する

   仕様に未解決の [NEEDS CLARIFICATION] マーカーが含まれている場合は、ユーザーが明示的に続行を希望しない限り、いったん作業を止め、先に spec-kit-clarify スキルを使用するよう提案します。

   計画自体の不明点（選択が必要な依存関係、統合パターン、既存コードの挙動など）を列挙し、それぞれコードまたは依存関係のドキュメントを読んで解決します。 解決した不明点と検討した代替案を、それぞれ ## Decisions & Rationale に記録します。

3. specs/changes/<name>/plan.md を作成する

   構成：

   # Plan: <Feature Name>
   
   ## Technical Context
   <Language and versions, main dependencies, storage, testing tools, target platform, constraints. Only what the code or the user establishes.>
   
   ## Architecture
   <Bounded context, layers affected, dependency direction. Must comply with FRAMEWORK.md dependency rule.>
   
   ## Data Models
   <Entities, value objects, aggregates. Identity vs. structural equality. Invariants. Field constraints: required or optional, limits, allowed values, validation rules.>
   
   ## Interface Contracts
   <Ports, use case signatures, domain events, and what the project exposes to users or other systems (commands, endpoints, public APIs, messages). Technology-agnostic where the layer requires it.>
   
   ## Implementation Phases
   1. <Phase name> — <what it establishes>
   2. ...
   
   ## Decisions & Rationale
   | Decision | Rationale | Alternatives Considered |
   |----------|-----------|------------------------|
   
   ## Exceptions
   | Rule | Trade-off | Simpler alternative rejected | Verification |
   |------|-----------|------------------------------|--------------|
   
   ## Record Search
   | Record | Search | Disposition |
   |--------|--------|-------------|
   
   ## Validation Scenarios
   <Runnable scenarios that prove the feature works end to end: prerequisites, the commands to run, expected outcomes.>
   
   ## Constraints & Risks
   <Known constraints, open technical risks.>
   

   ルール：

   • 依存関係の方向は infrastructure -> application -> domain とします。逆方向にしてはいけません。
   • ビジネス上の挙動に影響する外部依存関係は、ポートの背後に配置します。
   • リポジトリはテーブルごとではなく、集約ルートごとに設けます。
   • ドメイン層またはアプリケーション層の設計に、フレームワーク名を含めてはいけません。
   • コンテキスト間の連携は、共有カーネルの契約またはドメインイベントを介して行います。互いをインポートしてはいけません（他のコンテキストのアプリケーションサービスも含みます）。
   • 規定ルールの例外は、4 列すべてを含む ## Exceptions に記録するか、まったく記録しないでください。例外がない場合は None. と記載します。 spec-kit-analyse は、トレードオフが妥当で検証方法がある記録済みの例外を認めます。列が 1 つでも欠けている場合は違反として扱います。
   • ## Record Search には、この変更によって事実と異なる状態になる、現行の仕様、決定記録、文書をすべて記載します。 specs/features/、specs/decisions/、およびプロジェクトのドキュメントを検索し、変更対象となる用語について、その概念を表す語と表記の両方を検索します。たとえば、「機能仕様の隣に」と記載されたページは、パスだけの検索では見落とされる配置を規定しています。 各行には、見つかった方法と対応内容を記載します。対応内容は、変更によって更新する場合（更新方法も記載）または影響を受けない場合（その理由も記載）のいずれかです。 決定記録を覆す変更では、その旨を記載し、ユーザーの決定を引用します。計画が独自の判断で記録済みの決定を覆してはいけません。 影響を受けるものがない場合は、実施した検索内容とともに None found. と記載します。
   • ## Validation Scenarios は実行時の指針であり、実装内容ではありません。契約やデータモデルへのリンクを記載し、契約やデータモデルを繰り返し記載しないでください。また、実装コード、マイグレーション、テストスイート全体を含めてはいけません。

4. 実際の内容と照らして計画を確認する

   変更対象がすでに存在する場合は、記述する前にその内容を読みます。 計画は正式な指針として扱われるため、ここで確認しなければ、次のような誤りはレビューをすり抜けます。

   • しきい値と比較。 演算子と定数は言い換えず、コードから引用します。 コードが > limit をテストしているのに、計画に「上限以上」と書くと、実装者が動作しているコードを変更したり、計画にあるルールを表すテストを書いたりすることになります。
   • 要件が暗黙に依存している設定。 スコープ外として記録する前に、要件に必要なものがないか確認します。権限、ビルドまたはデプロイの設定、キャッシュキー、チェックアウトの深さなどです。
   • コード内の件数、列挙、箇所。 「X を行うファイル」のような集合は、サンプルからではなく、検索でコードから導き出し、実装者が繰り返せるように検索方法を記録します。 コード内の箇所は、検索可能なもの、たとえば関数、型、特徴的な文字列で示します。別の場所を編集すると変わる行番号は使いません。
   • 変更を生成する箇所だけでなく、それを読む箇所。 変更する識別子、メッセージ、形式、フラグ、エンドポイントの形を決める前に、コードとテストを含むリポジトリ全体を検索し、コード上の表記どおりに、それを読む箇所をすべて確認して、検索方法を記録します。 コードの別の箇所がすでに解析しているテキストは形式です。その形式にフィールドやマーカーを追加しても安全なのは、パーサーを特定して確認した後だけです。通常、パーサーは編集対象のファイルにはありません。 変更の影響を受けるものを読む、変更対象外のテストはすべて名前を挙げます。そうすれば、spec-kit-tasks がそれらにタスクを割り当てられます。これらは、そうしなければ変更によって古い状態のまま残るテストです。
   • 特殊ケースでは、変更される事実を読み取るすべてのステップをたどり、導入するステップだけにとどめません。 計画には、各ステップが以後どのように動作するかを記載します。
   • 結果が共通しているからといって、すべての生成元が新しいケースに対応している証拠にはなりません。 1 つの結果（ステータス、エラー、中断）が複数のトリガーから発生する場合は、各生成元を名前で確認します。また、新しい値を汎用的に処理するコンシューマーでも、その隣にハードコードされた文言を表示していると、新しいケースでは事実に反することがあります。
   • ルールの例外では、そのルールを再掲する箇所をすべて挙げます。 ルールは標準、スキル、ドキュメントなど複数の場所に記載されていることが多く、その例外によって修正が必要な箇所は、それぞれが対象となります。ルールの文言を検索します。
   • 安全性チェックの免除は、安全であることを示す状態に基づいてキー付けします。 適用箇所でその状態を確認し、その状態を超えて存続する可能性のあるレコードに基づいてキー付けしてはいけません。
   • 約束するコミットは分離可能でなければなりません。 1 つのファイル内の 2 つの振る舞いを 2 つのコミットとして計画する前に、きれいに分割できるか確認します。1 つの関数内に織り込まれている場合は、両方を説明するメッセージを付けた 1 つのコミットを計画します。
   • 計画のセクションは、プロジェクト独自のテンプレートに従います。 FRAMEWORK.local.md またはプロジェクトのドキュメントで計画に追加のセクションが求められている場合は、それらを追加します。

5. 憲章の確認

   完了前に、そして設計の完了後にも、計画が FRAMEWORK.md の必須ルールに違反していないことを確認します。 違反があれば、計画内で修正するか、## Exceptions に例外として記録します。明記せずに残してはいけません。

出力

計画の作成後：

• ファイルの場所を確認します。
• ユーザーが留意すべきアーキテクチャ上の決定、例外、影響を受けるレコードを強調します。
• 次のステップ：「spec-kit-tasks スキルを使ってタスクリストを生成します。」必要であれば、その前に spec-kit-checklist スキルを使って特定の領域（セキュリティ、UX、API）の要件を監査できます。

ガードレール

• コードは生成せず、計画だけを作成します。
• アーキテクチャに影響する仕様上の確認事項が未解決の場合は、推測せず明示します。
• まずドメインモデルを保護し、その周囲にインフラストラクチャを適合させます。
• 仕様で求められていることを決して変更しません。計画で満たせない要件はユーザーに差し戻します。