speckit-specify

speckit-specify

このスキルの内容は、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_specify キーの下にあるエントリーを探します。
• 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 が存在しない場合は、何も出力せずにスキップします。

アウトライン

トリガーメッセージ内で __SPECKIT_COMMAND_SPECIFY__ の後にユーザーが入力したテキストが、機能の説明です。以下に {ARGS} が文字どおり記載されていても、この会話内で常にその説明を参照できるものとします。コマンドが空の場合を除き、ユーザーに繰り返しを求めないでください。

その機能の説明に基づいて、次の操作を行います。

1. 簡潔な短い名前を生成します（2～4語）。

   • 機能の説明を分析し、最も重要なキーワードを抽出します。
   • 機能の要点を表す2～4語の短い名前を作成します。
   • 可能であれば、動作と対象を組み合わせた形式にします（例：「add-user-auth」、「fix-payment-bug」）。
   • 技術用語や頭字語（OAuth2、API、JWT など）はそのまま使用します。
   • 簡潔さを保ちつつ、機能をひと目で把握できる名前にします。
   • 例：
     • 「ユーザー認証を追加したい」→「user-auth」
     • 「API に OAuth2 統合を実装する」→「oauth2-api-integration」
     • 「分析用のダッシュボードを作成する」→「analytics-dashboard」
     • 「決済処理のタイムアウトのバグを修正する」→「fix-payment-timeout」

2. ブランチの作成（任意、フック経由）：

   上記の実行前の確認で before_specify フックが正常に実行された場合、そのフックによって git ブランチが作成または切り替えられ、BRANCH_NAME と FEATURE_NUM を含む JSON が出力されています。これらの値を参照用に控えておきます。ただし、ブランチ名によって仕様ディレクトリ名が決まるわけではありません。

   ユーザーが GIT_BRANCH_NAME を明示的に指定した場合は、その値をフックに渡し、ブランチ名として正確に使用するようブランチスクリプトに指示します（すべてのプレフィックス／サフィックス生成を回避します）。

3. 仕様の機能ディレクトリを作成します：

   ユーザーが SPECIFY_FEATURE_DIRECTORY を明示的に指定しない限り、仕様はデフォルトの specs/ ディレクトリに配置されます。

   SPECIFY_FEATURE_DIRECTORY の解決順序：

   1. ユーザーが SPECIFY_FEATURE_DIRECTORY を明示的に指定した場合（例：環境変数、引数、設定経由）、その値をそのまま使用します
   2. それ以外の場合は、specs/ の下に自動生成します：
      • .specify/init-options.json で feature_numbering（推奨）または branch_numbering（非推奨、移行時のみ使用。今後のリリースで削除予定）を確認します
      • "timestamp" の場合：プレフィックスは YYYYMMDD-HHMMSS（現在のタイムスタンプ）です
      • "sequential" または未指定の場合：プレフィックスは NNN（specs/ 内の既存ディレクトリを確認して割り当てる、次の利用可能な3桁の番号）です
      • ディレクトリ名を作成します：<prefix>-<short-name>（例：003-user-auth または 20260319-143022-user-auth）
      • SPECIFY_FEATURE_DIRECTORY を specs/<directory-name> に設定します
      • branch_numbering が使用され（かつ feature_numbering が未指定の）場合、1行の警告を出力します："⚠️ branch_numbering in init-options.json is deprecated. Rename to feature_numbering."

   ディレクトリと仕様ファイルを作成します：

   • mkdir -p SPECIFY_FEATURE_DIRECTORY
   • Spec Kit のプリセット／テンプレート解決スタックを通じて、アクティブな spec-template を解決します（specify preset resolve spec-template と同等）
   • 解決した spec-template ファイルを SPECIFY_FEATURE_DIRECTORY/spec.md にコピーし、ひな形として使用します
   • SPEC_FILE を SPECIFY_FEATURE_DIRECTORY/spec.md に設定します
   • 解決したパスを .specify/feature.json に保存します：

     {
       "feature_directory": "<resolved feature dir>"
     }
     

     文字列 SPECIFY_FEATURE_DIRECTORY そのものではなく、実際に解決されたディレクトリパス（例：specs/003-user-auth）を書き込みます。 これにより、後続のコマンド（__SPECKIT_COMMAND_PLAN__、__SPECKIT_COMMAND_TASKS__ など）は、git ブランチ名の慣例に依存せずに機能ディレクトリを特定できます。

   重要：

   • __SPECKIT_COMMAND_SPECIFY__ の1回の実行につき、作成できる機能は1つだけです
   • 仕様ディレクトリ名と git ブランチ名は独立しています。同じ名前でもかまいませんが、それはユーザーが選択します
   • 仕様ディレクトリとファイルは常にこのコマンドが作成し、フックが作成することはありません

4. 解決されたアクティブな spec-template ファイルを読み込み、必要なセクションを確認します。

5. 存在する場合：プロジェクトの原則とガバナンス上の制約を確認するため、/memory/constitution.md を読み込みます。

6. 次の実行フローに従います：

   1. 引数からユーザーの説明を解析します 空の場合：ERROR "機能の説明がありません"
   2. 説明から主要な概念を抽出します アクター、アクション、データ、制約を特定します
   3. 不明確な点について：
      • 文脈と業界標準に基づいて、妥当な推測を行います
      • 次の場合に限り、[NEEDS CLARIFICATION: specific question] を付けます：
        • 選択によって機能の範囲やユーザー体験が大きく変わる
        • 異なる影響をもたらす、妥当な解釈が複数存在する
        • 妥当なデフォルトがない
      • 上限：[NEEDS CLARIFICATION] マーカーは合計3つまで
      • 影響度の高い順に明確化します：範囲 > セキュリティ／プライバシー > ユーザー体験 > 技術的詳細
   4. ユーザーシナリオとテストのセクションを記入します 明確なユーザーフローを特定できない場合：ERROR "ユーザーシナリオを特定できません"
   5. 機能要件を作成します 各要件はテスト可能である必要があります 指定されていない詳細には妥当なデフォルトを使用し、前提条件のセクションに記録します
   6. 成功基準を定義します テクノロジーに依存しない、測定可能な成果を設定します 定量的指標（時間、パフォーマンス、量）と定性的な尺度（ユーザー満足度、タスク完了）の両方を含めます 各基準は、実装の詳細がなくても検証可能である必要があります
   7. 主要なエンティティを特定します（データが関係する場合）
   8. 結果を返します：SUCCESS（仕様は計画の準備完了）

7. テンプレートの構成を使用し、プレースホルダーを機能の説明（引数）から得られる具体的な詳細に置き換え、セクションの順序と見出しを維持して、仕様をSPEC_FILEに書き込みます。

8. 仕様の品質検証：初期仕様を書き込んだ後、品質基準に照らして検証します。

   a. 仕様品質チェックリストを作成：次の検証項目を含め、チェックリストのテンプレート構成を使用して、SPECIFY_FEATURE_DIRECTORY/checklists/requirements.mdにチェックリストファイルを生成します。

   # 仕様品質チェックリスト：[FEATURE NAME]
   
   **目的**：計画に進む前に、仕様の完全性と品質を検証します
   **作成日**：[DATE]
   **機能**：[spec.mdへのリンク]
   
   ## コンテンツの品質
   
   - [ ] 実装の詳細（言語、フレームワーク、API）が含まれていない
   - [ ] ユーザーの価値とビジネスニーズに焦点を当てている
   - [ ] 技術者以外の関係者向けに書かれている
   - [ ] すべての必須セクションが完成している
   
   ## 要件の完全性
   
   - [ ] [NEEDS CLARIFICATION]マーカーが残っていない
   - [ ] 要件がテスト可能で、曖昧さがない
   - [ ] 成功基準が測定可能である
   - [ ] 成功基準が技術に依存しない（実装の詳細を含まない）
   - [ ] すべての受け入れシナリオが定義されている
   - [ ] エッジケースが特定されている
   - [ ] スコープが明確に定められている
   - [ ] 依存関係と前提条件が特定されている
   
   ## 機能の準備状況
   
   - [ ] すべての機能要件に明確な受け入れ基準がある
   - [ ] ユーザーシナリオが主要なフローを網羅している
   - [ ] 機能が成功基準で定義された測定可能な成果を満たしている
   - [ ] 仕様に実装の詳細が漏れ込んでいない
   
   ## メモ
   
   - 未完了の項目がある場合、`__SPECKIT_COMMAND_CLARIFY__`または`__SPECKIT_COMMAND_PLAN__`に進む前に仕様を更新する必要があります
   

   b. 検証チェックを実行：各チェック項目に照らして仕様を確認します。

   • 各項目について、合格か不合格かを判断します
   • 見つかった問題を具体的に記録します（該当する仕様のセクションを引用します）

   c. 検証結果に対応：

   • すべての項目に合格した場合：チェックリストを完了としてマークし、「実行後の必須フック」セクションに進みます

   • 不合格の項目がある場合（[NEEDS CLARIFICATION]を除く）：

     1. 不合格の項目と具体的な問題を列挙します
     2. 各問題に対応するよう仕様を更新します
     3. すべての項目に合格するまで検証を再実行します（最大3回）
     4. 3回の再実行後も不合格の項目が残る場合は、残る問題をチェックリストのメモに記録し、ユーザーに警告します

   • [NEEDS CLARIFICATION]マーカーが残っている場合：

     1. 仕様からすべての[NEEDS CLARIFICATION: ...]マーカーを抽出します

     2. 上限の確認：マーカーが3つを超える場合、最も重要な3つ（スコープ／セキュリティ／UXへの影響に基づく）だけを残し、それ以外は妥当な推測で補います

     3. 明確化が必要な項目ごとに（最大3つ）、次の形式で選択肢をユーザーに提示します。

        ## 質問[N]：[トピック]
        
        **背景**：[該当する仕様セクションの引用]
        
        **確認が必要な内容**：[NEEDS CLARIFICATIONマーカーにある具体的な質問]
        
        **回答の候補**：
        
        | 選択肢 | 回答 | 影響 |
        |--------|------|------|
        | A      | [最初の回答候補] | [機能にとっての意味] |
        | B      | [2番目の回答候補] | [機能にとっての意味] |
        | C      | [3番目の回答候補] | [機能にとっての意味] |
        | その他 | 独自の回答を記入してください | [独自の回答を入力する方法を説明] |
        
        **選択内容**：_[ユーザーの回答を待つ]_
        

     4. 重大 — 表の書式：Markdown の表が正しく書式設定されていることを確認します。

        • パイプの位置を揃え、一貫したスペースを使用します
        • 各セルの内容の前後にスペースを入れます：| Content |（|Content| ではありません）
        • ヘッダー区切り行には、少なくとも 3 つのハイフンを入れます：|--------|
        • Markdown プレビューで表が正しく表示されることを確認します

     5. 質問には連番を付けます（Q1、Q2、Q3 — 最大 3 問）

     6. 回答を待つ前に、すべての質問をまとめて提示します

     7. すべての質問に対する選択肢をユーザーが回答するまで待ちます（例：「Q1: A, Q2: Custom - [details], Q3: B」）

     8. 各 [NEEDS CLARIFICATION] マーカーを、ユーザーが選択または提示した回答に置き換えて仕様書を更新します

     9. すべての確認事項が解決したら、検証を再実行します

   d. チェックリストの更新：検証を繰り返すたびに、現在の合格／不合格状況でチェックリストファイルを更新します

実行後の必須フック

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

プロジェクトルートに .specify/extensions.yml が存在するか確認します。

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

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

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

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

完了レポート

以下をユーザーに報告してください。

• SPECIFY_FEATURE_DIRECTORY — 機能ディレクトリのパス
• SPEC_FILE — 仕様ファイルのパス
• チェックリスト結果の概要
• 次のフェーズへの準備状況（__SPECKIT_COMMAND_CLARIFY__ または __SPECKIT_COMMAND_PLAN__）

注： ブランチの作成は before_specify フック（git 拡張機能）が処理します。仕様ディレクトリとファイルの作成は、常にこのコアコマンドが処理します。

クイックガイドライン

• ユーザーが何を必要としているか、そしてなぜ必要としているかに重点を置きます。
• 実装方法には触れません（技術スタック、API、コード構成は記載しません）。
• 開発者ではなく、ビジネス関係者向けに記述します。
• 仕様書に埋め込まれたチェックリストは作成しないでください。チェックリストは別のコマンドで作成します。

セクションの要件

• 必須セクション：すべての機能で記述する必要があります
• 任意セクション：機能に関連する場合にのみ含めます
• セクションが該当しない場合は、完全に削除します（「N/A」として残さないでください）

AI 生成时

ユーザープロンプトからこの仕様を作成する場合：

1. 十分な情報に基づいて推測する：文脈、業界標準、一般的なパターンを使って不足を補います
2. 前提を記録する：「前提」セクションに妥当なデフォルトを記載します
3. 確認事項を最小限に抑える：[NEEDS CLARIFICATION] マーカーは最大 3 つとし、次の条件に該当する重要な判断にのみ使用します：
   • 機能の範囲やユーザー体験に大きな影響を与える
   • 妥当な解釈が複数あり、それぞれに異なる影響がある
   • 妥当なデフォルトが存在しない
4. 確認事項に優先順位を付ける：範囲 > セキュリティ／プライバシー > ユーザー体験 > 技術的な詳細
5. テスターの視点で考える：曖昧な要件はすべて「テスト可能で曖昧でない」というチェック項目を満たせないものとして扱います
6. 確認が必要になりやすい一般的な項目（妥当なデフォルトが存在しない場合のみ）：
   • 機能の範囲と境界（特定のユースケースを含めるか除外するか）
   • ユーザーの種類と権限（解釈が複数あり、互いに矛盾する可能性がある場合）
   • セキュリティ／コンプライアンス要件（法務または財務に重大な影響がある場合）

妥当なデフォルトの例（これらについて確認しないでください）：

• データ保持：その分野の業界標準に従った運用
• パフォーマンス目標：指定がない限り、一般的なウェブ／モバイルアプリの期待値
• エラー処理：適切な代替手段を備えた、ユーザーにわかりやすいメッセージ
• 認証方法：ウェブアプリで一般的なセッションベースまたは OAuth2
• 統合パターン：プロジェクトに適したパターンを使用（ウェブサービスでは REST／GraphQL、ライブラリでは関数呼び出し、ツールでは CLI 引数など）

成功基準のガイドライン

成功基準は次の条件を満たす必要があります：

1. 測定可能である：時間、割合、件数、率などの具体的な指標を含めます
2. テクノロジーに依存しない：フレームワーク、言語、データベース、ツールに言及しません
3. ユーザーを中心にしている：システム内部の仕組みではなく、ユーザーやビジネスにとっての成果を記述します
4. 検証可能である：実装の詳細を知らなくてもテストまたは検証できます

良い例：

• 「ユーザーは 3 分以内にチェックアウトを完了できます」
• 「システムは同時に 10,000 人のユーザーをサポートします」
• 「検索の 95％で 1 秒以内に結果が返されます」
• 「タスク完了率が 40％向上します」

悪い例（実装に焦点を当てています）：

• 「API の応答時間が 200ms 未満です」（技術的すぎます。「ユーザーは結果をすぐに確認できます」とします）
• 「データベースは 1000 TPS を処理できます」（実装の詳細です。ユーザー向けの指標を使用します）
• 「React コンポーネントが効率よくレンダリングされます」（フレームワークに依存しています）
• 「Redis のキャッシュヒット率が 80％を超えています」（特定の技術に依存しています）

完了条件

• 仕様を SPEC_FILE に記述し、品質チェックリストに照らして検証している
• 上記の「必須の実行後フック」に記載されたルールに従って、拡張フックを実行またはスキップしている
• 機能ディレクトリ、仕様ファイルのパス、チェックリストの結果をユーザーに報告している