speckit.clarify

Prompt file imported from Chabana1591/my-project (.codex/prompts/speckit.clarify.md). Fill in {{arguments}} before use. Copyright stays with the author.

ユーザー入力

{{arguments}}

続行する前に、ユーザー入力を必ず考慮してください（空でない場合）。

概要

目標: アクティブな機能仕様の曖昧さまたは欠落している決定ポイントを検出して削減し、明確化を仕様ファイルに直接記録します。

注意: この明確化ワークフローは /speckit.plan を呼び出す前に実行（および完了）されることが期待されます。ユーザーが明確化をスキップすることを明示的に述べた場合（例: 探索的スパイク）、続行してもよいですが、下流の手戻りリスクが増加することを警告する必要があります。

実行ステップ:

1. リポジトリルートから .specify/scripts/bash/check-prerequisites.sh --json --paths-only を一度実行します（組み合わせた --json --paths-only モード / -Json -PathsOnly）。最小限の JSON ペイロードフィールドを解析します:

   • FEATURE_DIR
   • FEATURE_SPEC
   • （オプションで将来のチェーンフロー用に IMPL_PLAN、TASKS をキャプチャ）
   • JSON 解析に失敗した場合は中止し、ユーザーに /speckit.specify を再実行するか、機能ブランチ環境を確認するよう指示します。
   • "I'm Groot" のような引数内のシングルクォートには、エスケープ構文を使用してください：例 'I'''m Groot'（または可能であればダブルクォート: "I'm Groot"）。

2. 現在の spec ファイルを読み込みます。この分類法を使用して構造化された曖昧さとカバレッジスキャンを実行します。各カテゴリについてステータスをマーク: Clear / Partial / Missing。優先順位付けに使用する内部カバレッジマップを作成します（質問が尋ねられない場合を除き、生のマップを出力しないでください）。

   機能スコープと動作:

   • コアユーザー目標と成功基準
   • 明示的なスコープ外宣言
   • ユーザーロール/ペルソナの区別

   ドメインとデータモデル:

   • エンティティ、属性、関係
   • アイデンティティと一意性ルール
   • ライフサイクル/状態遷移
   • データ量/スケールの仮定

   インタラクションと UX フロー:

   • クリティカルユーザージャーニー/シーケンス
   • エラー/空/ローディング状態
   • アクセシビリティまたはローカリゼーションノート

   非機能品質属性:

   • パフォーマンス（レイテンシ、スループット目標）
   • スケーラビリティ（水平/垂直、制限）
   • 信頼性と可用性（アップタイム、リカバリ期待値）
   • オブザーバビリティ（ロギング、メトリクス、トレーシングシグナル）
   • セキュリティとプライバシー（認証/認可、データ保護、脅威の仮定）
   • コンプライアンス/規制制約（ある場合）

   統合と外部依存関係:

   • 外部サービス/API と障害モード
   • データインポート/エクスポート形式
   • プロトコル/バージョニングの仮定

   エッジケースと障害処理:

   • ネガティブシナリオ
   • レート制限/スロットリング
   • 競合解決（例: 同時編集）

   制約とトレードオフ:

   • 技術的制約（言語、ストレージ、ホスティング）
   • 明示的なトレードオフまたは却下された代替案

   用語と一貫性:

   • 正規の用語集の用語
   • 避けるべき同義語/非推奨用語

   完了シグナル:

   • 受け入れ基準のテスト可能性
   • 測定可能な Definition of Done スタイルの指標

   その他/プレースホルダー:

   • TODO マーカー/未解決の決定
   • 定量化がない曖昧な形容詞（"robust"、"intuitive"）

   Partial または Missing ステータスの各カテゴリについて、以下の場合を除き候補質問の機会を追加:

   • 明確化が実装または検証戦略を実質的に変更しない
   • 情報は計画フェーズに延期する方が良い（内部的にメモ）

3. 候補明確化質問の優先順位付けキューを（内部的に）生成します（最大 5）。すべてを一度に出力しないでください。以下の制約を適用:

   • セッション全体で合計最大 10 問。
   • 各質問は以下のいずれかで回答可能でなければならない:
     • 短い多肢選択（2〜5 つの明確で相互排他的なオプション）、または
     • 1 語/短いフレーズの回答（明示的に制約: 「5 語以下で回答」）
   • アーキテクチャ、データモデリング、タスク分解、テスト設計、UX 動作、運用準備、またはコンプライアンス検証に実質的に影響する回答のみを含める。
   • カテゴリカバレッジバランスを確保: まず最も影響の大きい未解決カテゴリをカバーするよう試みる；単一の高影響エリア（例: セキュリティ態勢）が未解決の場合、2 つの低影響質問を避ける。
   • 既に回答された質問、些細なスタイル上の好み、または計画レベルの実行詳細（正確性をブロックしない限り）を除外。
   • 下流の手戻りリスクを減らす、または受け入れテストのずれを防ぐ明確化を優先。
   • 5 つ以上のカテゴリが未解決のままの場合、(影響度 * 不確実性) ヒューリスティックで上位 5 つを選択。

4. シーケンシャル質問ループ（インタラクティブ）:

   • 一度に正確に 1 つの質問を提示。

   • 多肢選択質問の場合:

     • すべてのオプションを分析し、以下に基づいて最も適切なオプションを決定:
       • プロジェクトタイプのベストプラクティス
       • 類似実装の一般的なパターン
       • リスク削減（セキュリティ、パフォーマンス、保守性）
       • 仕様に見える明示的なプロジェクト目標や制約との整合
     • 推奨オプションを明確な理由付け（1〜2 文でこれが最良の選択である理由を説明）とともに上部に目立つように提示。
     • 形式: **推奨:** オプション [X] - <理由>
     • 次に、すべてのオプションを Markdown テーブルとしてレンダリング:

     オプション	説明
     A	<オプション A の説明>
     B	<オプション B の説明>
     C	<オプション C の説明>（必要に応じて最大 5 まで D/E を追加）
     Short	別の短い回答を提供（5 語以下）（自由形式の代替が適切な場合のみ含める）

     • テーブルの後に追加: オプション文字で回答できます（例: "A"）、"yes" または "recommended" と言って推奨を受け入れるか、独自の短い回答を提供してください。

   • 短い回答スタイルの場合（意味のある個別のオプションがない場合）:

     • ベストプラクティスとコンテキストに基づいて提案された回答を提供。
     • 形式: **提案:** <提案された回答> - <簡単な理由>
     • 次に出力: 形式: 短い回答（5 語以下）。"yes" または "suggested" と言って提案を受け入れるか、独自の回答を提供してください。

   • ユーザーが回答した後:

     • ユーザーが "yes"、"recommended"、または "suggested" と回答した場合、以前に述べた推奨/提案を回答として使用。
     • それ以外の場合、回答が 1 つのオプションにマップするか、5 語以下の制約に適合するか検証。
     • 曖昧な場合は、簡単な明確化を求める（カウントは同じ質問に属する；進行しない）。
     • 満足したら、作業メモリに記録し（まだディスクに書き込まない）、次のキューに入れられた質問に移動。

   • 以下の場合にさらなる質問を停止:

     • すべてのクリティカルな曖昧さが早期に解決された（残りのキューに入れられた項目が不要になる）、または
     • ユーザーが完了シグナルを送った（"done"、"good"、"no more"）、または
     • 5 つの質問に達した。

   • 将来のキューに入れられた質問を事前に明かさない。

   • 開始時に有効な質問がない場合は、すぐにクリティカルな曖昧さがないことを報告。

5. 各受け入れられた回答後の統合（インクリメンタル更新アプローチ）:

   • 仕様のメモリ内表現（開始時に一度読み込み）と生のファイル内容を維持。
   • このセッションで最初に統合された回答の場合:
     • ## 明確化 セクションが存在することを確認（欠落している場合、spec テンプレートに従って最高レベルのコンテキスト/概要セクションの直後に作成）。
     • その下に、（存在しない場合）今日の ### セッション YYYY-MM-DD 小見出しを作成。
   • 受け入れ直後に箇条書き行を追加: - Q: <質問> → A: <最終回答>。
   • 次に、最も適切なセクションに明確化を即座に適用:
     • 機能的曖昧さ → 機能要件の箇条書きを更新または追加。
     • ユーザーインタラクション/アクターの区別 → ユーザーストーリーまたはアクターサブセクション（存在する場合）を明確化されたロール、制約、またはシナリオで更新。
     • データ形状/エンティティ → データモデルを更新（フィールド、タイプ、関係を追加）順序を維持；追加された制約を簡潔にメモ。
     • 非機能制約 → 非機能/品質属性セクションに測定可能な基準を追加/変更（曖昧な形容詞をメトリクスまたは明示的なターゲットに変換）。
     • エッジケース/ネガティブフロー → エッジケース/エラーハンドリングの下に新しい箇条書きを追加（またはテンプレートにプレースホルダーがある場合はそのようなサブセクションを作成）。
     • 用語の競合 → 仕様全体で用語を正規化；必要な場合にのみ （以前は "X" と呼ばれていた） を一度追加して元の用語を保持。
   • 明確化が以前の曖昧な文を無効にする場合、重複する代わりにその文を置き換える；古い矛盾するテキストを残さない。
   • コンテキスト損失のリスクを最小限に抑えるため、各統合後に spec ファイルを保存（アトミック上書き）。
   • フォーマットを保持: 関係のないセクションを並べ替えない；見出し階層をそのまま維持。
   • 各挿入された明確化を最小限でテスト可能に保つ（物語のドリフトを避ける）。

6. 検証（各書き込み後 + 最終パス後に実行）:

   • 明確化セッションには受け入れられた回答ごとに正確に 1 つの箇条書きが含まれる（重複なし）。
   • 尋ねられた（受け入れられた）質問の合計 ≤ 5。
   • 更新されたセクションに新しい回答が解決するはずだった長引く曖昧なプレースホルダーがない。
   • 今は無効な以前の文が矛盾したまま残っていない（削除された選択肢の代替をスキャン）。
   • Markdown 構造が有効；許可される新しい見出しのみ: ## 明確化、### セッション YYYY-MM-DD。
   • 用語の一貫性: すべての更新されたセクションで同じ正規用語が使用されている。

7. 更新された仕様を FEATURE_SPEC に書き戻す。

8. 完了報告（質問ループ終了または早期終了後）:

   • 尋ねられた質問と回答の数。
   • 更新された仕様へのパス。
   • 影響を受けたセクション（名前のリスト）。
   • 各分類カテゴリをステータスでリストするカバレッジサマリーテーブル: Resolved（Partial/Missing で対処された）、Deferred（質問枠を超えるか、計画により適している）、Clear（既に十分）、Outstanding（まだ Partial/Missing だが低影響）。
   • Outstanding または Deferred が残っている場合、/speckit.plan に進むか、後で計画後に /speckit.clarify を再実行するかを推奨。
   • 提案される次のコマンド。

動作ルール:

• 意味のある曖昧さが見つからない場合（または潜在的なすべての質問が低影響になる場合）、「正式な明確化に値するクリティカルな曖昧さは検出されませんでした。」と応答し、進むことを提案。
• spec ファイルが欠落している場合は、最初に /speckit.specify を実行するようユーザーに指示（ここで新しい仕様を作成しない）。
• 合計 5 つの質問を超えない（単一の質問の明確化リトライは新しい質問としてカウントしない）。
• 機能的明確さをブロックしない限り、推測的な技術スタック質問を避ける。
• ユーザーの早期終了シグナルを尊重（"stop"、"done"、"proceed"）。
• 完全なカバレッジにより質問がない場合、コンパクトなカバレッジサマリー（すべてのカテゴリが Clear）を出力し、進むことを提案。
• 未解決の高影響カテゴリが残ったまま枠に達した場合、理由付けとともに Deferred の下に明示的にフラグを立てる。

優先順位付けのコンテキスト: {{arguments}}