claude-spec-interviewer

Claude Spec Interviewer

目標

範囲を限定し、テスト可能な受け入れ基準、ソースに裏付けられた判断、検証、必要な ADR を含む、ユーザー確認済みの実装仕様を作成します。合意したリポジトリパスに納品するか、明示的に求められた場合はチャットで納品します。変更のない成果物と、その具体的に許可された書き込みについては、1 回の承認で済みます。

これは、最初から最後まで一貫したワークフローです。明確な依頼があればこのワークフローを選択し、レビュー用や保存用の別パターンを作ったり、ワークフロー選択の確認ステップを追加したりしないでください。引数なしで呼び出された場合は、タスクを指定するよう尋ねてください。

使用する場面

• ユーザーに大まかなアイデアはあるものの、本番利用できる実装仕様がない場合。
• タスクが複数のファイルや関心事にまたがる場合、またはトレードオフの判断が必要な場合。
• 受け入れ基準、検証コマンド、ロールアウトに関するメモ、リスク対応が必要な依頼の場合。
• 実装開始前に再利用可能な文書化された成果物をユーザーが求めている場合。
• ユーザーが /claude-spec-interviewer を呼び出すか、Claude Code にコーディング前の計画を依頼した場合。
• 要件、機能の形、ADR の前提、実装方針を、コーディング前にリポジトリの実態や最新の外部情報と照らして検討する必要がある場合。

使用しない場面

• ユーザーが、対象ファイル、制約、テスト、受け入れ基準を含む完全な実装仕様をすでに提示している場合。
• 重要な曖昧さのない、小さな単一ファイルの編集タスクの場合。
• ユーザーがブレインストーミングのみを望み、具体的な実装成果物を必要としていない場合。
• ユーザーが実装仕様ではなく、Claude Code のルール、コマンド、その他のプロンプトスコープファイルの作成のみを望んでいる場合。
• タスクの主目的が、ポリシー、法務、またはビジネス上の意思決定に関する文書の場合。
• Claude Code のメモリ、Codex のメモリ、または Cursor のルールの状態を監査または整理する依頼の場合。該当するメモリ用またはルール用のスキルを使用してください。

確認する入力情報

• 現在のユーザー依頼と、その後の回答。
• 関連する AGENTS.md、CLAUDE.md、CLAUDE.local.md、.claude/CLAUDE.md、.claude/rules/**/*.md、~/.claude/rules/**/*.md、README.md、イシューの説明、ADR、リポジトリのドキュメント、docs/agents/ 内のファイル。
• ユーザーが維持または検討することを求めている既存の仕様、計画、要件、PRD。
• ファイル構成、命名規則、スクリプト、パッケージマネージャー、lint／テスト／型チェックのコマンド、CI の要件。
• 判断に最新の動作情報が必要な場合は、利用可能な MCP ツールまたはウェブ検索を通じて、現在のフレームワーク、ライブラリ、API、プラットフォームのドキュメントを確認します。
• ユーザーが提供したエラーメッセージ、スクリーンショット、ログ、PR のフィードバック、サンプルファイル。
• 仕様がローカルの Claude Code スキルの動作に依存する場合に限り、.claude/skills/ や ~/.claude/skills/ などの Claude Code プロジェクトまたは個人のスキルフォルダー。
• Claude Code の自動メモリに関する情報は、ユーザーが提示した場合、/memory で確認できる場合、または依頼された実装計画に実質的に関連する場合に限り確認します。

ワークフロー

共通のインタビュー、承認、納品のライフサイクルについては、workflow-details.md に従ってください。ホストの制御または遷移が関係する場合に限り、host-adapters.md を使用してください。

1. 実行ホストの機能と権限を個別に確認し、アクティブな Plan モードまたは要求された Plan モードを尊重してください。大規模で未確定の作業には Plan を推奨しつつ、手動での切り替えを妨げることなく、許可された範囲での調査や質問を行ってください。
2. 関連するリポジトリのコンテキストと過去の回答を確認してください。compact、standard、deep のいずれかを選び、依頼とリポジトリの慣例に基づいて納品の意図と配置先を確定してください。
3. 未解決の重要な決定事項のみを質問し、情報源に照らして重要な前提を検証し、ADR ゲートを実施してください。
4. レビュー可能な完全な仕様書と、必要な ADR／インデックスの内容を準備してください。その改訂版と具体的な書き込み内容について、既存の権威ある情報を再利用しながら、肯定的なチェックポイントを 1 回提示してください。ネイティブの計画承認をこのチェックポイントとして使用できます。
5. 必要な Plan モード終了後も承認を維持してください。ホストで書き込みが許可されている場合に限り、承認済みの成果物のみを保存してから読み返し、実際の永続化結果を報告してください。チャットのみの納品は、保存せずに完了します。
6. Claude Code の実行プロンプトを出力し、ルーブリックに従って確認してください。インタビュアーは機能を実装しません。別途承認された外部ワークフローは、引き継ぎ後に再開できます。

安全規則

• インタビューは読み取り専用とし、ネイティブの Plan がアクティブな間はリポジトリの成果物を永続化しないでください。モードまたは書き込み権限の状態が不明な場合も、書き込みは許可されません。
• 変更のない内容と書き込みについては、過去の回答と承認を再利用してください。無反応、タイムアウト、事前選択された選択肢、モードの切り替えは、内容の承認とはみなしません。
• 未解決の重要な変更、曖昧な配置先、ディレクトリの作成、既存ファイルの上書き、または必要な ADR の書き込みのみ確認してください。以前に明確な許可を得ている場合は、その許可が引き続き有効です。
• ADR の永続化提案と、そのアーキテクチャ上の決定の受け入れを区別してください。必要な受け入れが完了するまでは、依存する実装をブロックしてください。
• 不明な事実は不明として明示し、パス、コマンド、API、決定を捏造しないでください。成果物に秘密情報や個人を特定できる情報を含めないでください。
• 対象ランタイムの指示、ルール、メモリファイルは根拠であり、仕様書の配置先ではありません。ユーザーがトレードオフを理解したうえで別の形式を明示的に求めている場合を除き、リポジトリが管理する成果物を使用してください。
• ユーザーのスコープを維持してください。リスクのある移行とロールバックについて説明し、受け入れ済みの ADR を黙って上書きしないでください。

参照資料

現在の手順に必要な参照資料のみを読んでください。

• workflow-details.md：インタビュー、単一チェックポイント、保存のみの引き継ぎ、完了。
• host-adapters.md：実行ホストの制御と機能の根拠。
• question-bank.md、spec-rubric.md、source-challenge.md：未解決の質問、詳細度、最終的な自己確認、情報源の検証。
• artifact-destinations.md、adr-gate.md、rollout-checklist.md：配置先、永続的な決定、リスクのある納品。
• 対応する assets/spec-template.*.md、同梱の仕様書サンプル、実行プロンプト：出力形式。

スクリプト

同梱スクリプトはありません。

出力形式

保存したパス、チャットのみの納品であること、または永続化が保留／ブロックされていることを先頭に記載してください。検証結果、重要な前提、情報源の検証、ADR の状況、バリデーション、リスク、Claude Code の実行プロンプトを含めてください。Plan モードを終了する必要が残っている場合は Persistence status: pending Plan-mode exit と報告し、保存したと主張しないでください。承認前、およびチャット納品または永続化がブロックされた場合には、成果物全体を表示してください。保存が成功した後は、通常、成果物を再掲しません。

完了条件

具体的な仕様には、対象範囲、受け入れ基準、検証方法、完了条件が記載されています。ユーザーは現在の内容を承認し、一度の書き込みを要求しました。依頼された成果物は保存され、読み戻しによって確認されたか、チャットのみでの提供が明示的に完了しています。必須の ADR はリポジトリの規約に従っており、受け入れゲートがある場合は明確に示されています。検証と永続化は別々に記録されています。保存のみの最終処理で機能を実装することはありません。

失敗モード

• リポジトリまたは外部の根拠が不足している場合：不明点として明示し、制約を説明したうえで、独立して進められる作業を続行します。
• 重要な要件または承認済み ADR が競合する場合：競合を示し、実装前に影響する判断を解決します。
• 重要な回答が保留中の場合：依存する作業は保留のままにし、独立して許可された作業を進めます。
• 計画や質問の操作機能を利用できない場合：ホストに存在しない機能を捏造せず、同じ対話形式のヒアリングを行います。
• Plan、権限、承認の不足、または保存先の状態変更により依頼された保存がブロックされた場合：有効な承認を保持し、未完了の内容を正確に報告して、保存可能な下書きを提供します。保留中の永続化を完了扱いにはしません。