speckit-plan

ユーザー入力

$ARGUMENTS

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

実行前の確認

拡張フックを確認します（計画を立てる前に実施）：

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

  • 任意のフック（optional: true）：

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

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

    ## Extension Hooks
    
    **Automatic Pre-Hook**: {extension}
    Executing: `/{command}`
    EXECUTE_COMMAND: {command}
    
    Wait for the result of the hook command before proceeding to the Outline.
    

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

• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何もせずにスキップします。

概要

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

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

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

   • Technical Context を記入します（不明な点は「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 の実装に委ねます。
• フックのコマンド名からコマンド呼び出しを作成する際は、ドット（.）をハイフン（-）に置き換えます。例：speckit.git.commit → /speckit-git-commit。
• 実行可能なフックごとに、optional フラグに応じて以下を出力します。

  • 必須フック（optional: false）— 必須フックごとに EXECUTE_COMMAND: を必ず出力してください。

    ## 拡張フック
    
    **自動フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    

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

  • 任意のフック（optional: true）：

    ## 拡張フック
    
    **任意のフック**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{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 に以下の形式で調査結果をまとめます。

   • 決定：[選択した内容]
   • 根拠：[選択した理由]
   • 検討した代替案：[評価した他の選択肢]

出力：すべての 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

主なルール

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

完了条件

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