speckit-plan

speckit-plan

このスキルの内容は、GitHub Spec Kit 公式のプロンプトテンプレートを基にしています。

• 上流：https://github.com/github/spec-kit
• ライセンス：MIT License, Copyright GitHub, Inc.（全文は同じディレクトリの LICENSE.txt を参照）
• 適応に関する説明：公式テンプレートはスラッシュコマンドの使用を想定しています。原文の $ARGUMENTS は、ユーザーが対話で指定するリクエストを指します。 また、speckit.plan などのコマンド間参照は、このスキル体系では同名の speckit-* スキルに対応します。 その他の内容は上流と同じで、書き換えていません。

---

ユーザー入力

$ARGUMENTS

ユーザー入力が空でない場合は、処理を続行する前に必ず確認してください。

実行前の確認

拡張フックを確認します（計画の前に実行）：

• プロジェクトのルートに .specify/extensions.yml が存在するか確認します。
• 存在する場合は読み込み、hooks.before_plan キーの下にあるエントリを確認します。
• YAML を解析できない、または無効な場合は、黙ってスキップしないでください。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録された必須（optional: false）フックも含め、フックを確認できなかったことをユーザーに伝え、その後は通常どおり続行します。
• enabled が明示的に false のフックは除外します。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、condition 式を解釈または評価しないでください。
  • フックに condition フィールドがない場合、またはその値が null／空の場合、実行可能なフックとして扱います。
  • フックに空でない condition が定義されている場合、フックをスキップし、条件の評価は HookExecutor の実装に委ねます。
• 実行可能な各フックについて、optional フラグに応じて次の内容を出力します。
  • 任意のフック（optional: true）：

    ## 拡張フック
    
    **任意の事前フック**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{command}`
    

  • 必須のフック（optional: false）：

    ## 拡張フック
    
    **自動事前フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    
    アウトラインに進む前に、フックコマンドの結果を待ってください。
    

    上記のブロックを出力した後は、続行する前に、実際にフックを呼び出して終了を待つ必要があります。このエージェント／セッションでコマンドを実行する場合と同じ方法で実行してください（呼び出し方法は、上記の {command} の文字列と異なる場合があります。たとえば、スキルモードのエージェントでは /skill:speckit-... や $speckit-... のように実行します）。ブロックを出力するだけでは、フックは実行されません。
• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何もせずにスキップします。

概要

1. セットアップ：リポジトリのルートから {SCRIPT} を実行し、JSON を解析して FEATURE_SPEC、IMPL_PLAN、FEATURE_DIR、BRANCH を取得します。"I'm Groot" のように引数にシングルクォートが含まれる場合は、エスケープ構文を使用します。例：'I'\''m Groot'（可能であればダブルクォートを使用："I'm Groot"）。

2. コンテキストの読み込み：FEATURE_SPEC と /memory/constitution.md を読み込みます。IMPL_PLAN テンプレートを読み込みます（コピー済みです）。

3. 計画ワークフローの実行：IMPL_PLAN テンプレートの構成に従って、以下を行います。

   • 技術コンテキストを記入します（不明点は「NEEDS CLARIFICATION」と記載）
   • 憲章に基づいて Constitution Check セクションを記入します
   • ゲートを評価します（正当化されていない違反があれば ERROR）
   • フェーズ 0：research.md を生成します（NEEDS CLARIFICATION をすべて解消）
   • フェーズ 1：data-model.md、contracts/、quickstart.md を生成します
   • 設計後に Constitution Check を再評価します

実行後の必須フック

ユーザーに完了を報告する前に、このセクションを必ず完了してください。

プロジェクトのルートに .specify/extensions.yml があるか確認してください。

• 存在しない場合、または hooks.after_plan の下に登録されたフックがない場合は、「完了レポート」に進みます。
• 存在する場合は読み込み、hooks.after_plan キーの下にあるエントリーを確認してください。
• YAML を解析できない場合、または無効な場合は、黙ってスキップしないでください。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録されている必須（optional: false）フックを含め、フックが一切確認されなかったことをユーザーに伝えたうえで、「完了レポート」に進んでください。
• enabled が明示的に false のフックは除外してください。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、フックの condition 式を解釈または評価しようとしてはいけません。
  • condition フィールドがない場合、または null／空の場合は、実行可能なフックとして扱います。
  • 空でない condition が定義されているフックはスキップし、条件の評価は HookExecutor の実装に任せます。
• 実行可能な各フックについて、optional フラグに応じて以下を出力してください。
  • 必須フック（optional: false）— 必須フックごとに、必ず EXECUTE_COMMAND: を出力してください：

    ## Extension Hooks
    
    **Automatic Hook**: {extension}
    Executing: `/{command}`
    EXECUTE_COMMAND: {command}
    

    上記のブロックを出力した後は、続行する前に、フックを実際に呼び出して終了まで待たなければなりません。このエージェント／セッションで自分自身がコマンドを実行する場合と同じ方法で実行してください（呼び出し方法は、表示する {command} の ID と異なる場合があります。たとえば、スキルモードのエージェントでは /skill:speckit-... または $speckit-... のように実行します）。ブロックを出力するだけでは、フックは実行されません。
  • 任意フック（optional: true）：

    ## Extension Hooks
    
    **Optional Hook**: {extension}
    Command: `/{command}`
    Description: {description}
    
    Prompt: {prompt}
    To execute: `/{command}`
    

完了レポート

コマンドはフェーズ 1 の設計後に終了します。ブランチ、IMPL_PLAN のパス、生成された成果物を報告してください。

フェーズ

フェーズ 0：概要と調査

1. 上記の「技術的コンテキスト」から不明点を抽出します。

   • NEEDS CLARIFICATION ごとに、調査タスクを作成します。
   • 依存関係ごとに、ベストプラクティスのタスクを作成します。
   • 統合ごとに、パターンのタスクを作成します。

2. 調査エージェントを生成して割り当てます。

   For each unknown in Technical Context:
     Task: "Research {unknown} for {feature context}"
   For each technology choice:
     Task: "Find best practices for {tech} in {domain}"
   

3. research.md に次の形式で調査結果をまとめます。

   • Decision: [選択した内容]
   • Rationale: [選択した理由]
   • Alternatives considered: [評価したその他の選択肢]

出力：すべての NEEDS CLARIFICATION が解決された research.md

フェーズ 1：設計と契約

前提条件： research.md が完成していること

1. 機能仕様からエンティティを抽出する → data-model.md：

   • エンティティ名、フィールド、関係
   • 要件に基づく検証ルール
   • 該当する場合は状態遷移

2. インターフェース契約を定義する（プロジェクトに外部インターフェースがある場合）→ /contracts/：

   • プロジェクトがユーザーまたは他のシステムに公開するインターフェースを特定する
   • プロジェクトの種類に適した契約形式を文書化する
   • 例：ライブラリの公開 API、CLI ツールのコマンドスキーマ、ウェブサービスのエンドポイント、パーサーの文法、アプリケーションの UI 契約
   • プロジェクトが純粋に内部向けの場合（ビルドスクリプト、単発ツールなど）は省略する

3. クイックスタート検証ガイドを作成する → quickstart.md：

   • 機能がエンドツーエンドで動作することを証明する、実行可能な検証シナリオを文書化する
   • 前提条件、セットアップコマンド、テスト／実行コマンド、期待される結果を含める
   • 内容の重複を避けるため、契約とデータモデルの詳細はリンクまたは参照を使用する
   • 実装コード全体、モデル／サービス／コントローラーの本体、マイグレーション、またはテストスイート全体は含めない
   • この成果物は検証／実行ガイドとし、実装の詳細は tasks.md と実装フェーズに記載する

出力：data-model.md、/contracts/*、quickstart.md

主なルール

• ファイルシステム操作には絶対パスを使用し、ドキュメント内の参照にはプロジェクト相対パスを使用する
• ゲートの失敗または未解決の確認事項がある場合はエラーにする

完了条件

• 計画ワークフローを実行し、設計成果物を生成した
• 上記の「必須の実行後フック」のルールに従って、拡張フックを実行したか、スキップした
• ブランチ、計画のパス、生成した成果物をユーザーに報告した