/kairo-requirements

description: ユーザから提供された要件の概要を分析し、EARS（Easy Approach to Requirements Syntax）記法を使用して詳細な受け入れ基準を含む要件定義書を作成します。
allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite, WebFetch, AskUserQuestion
argument-hint: "[要件名] [PRDファイルパス(optional)]"

Kairo開発の要件整理を実施し、PRD・EARS要件定義書・設計文書を参照しながら機能仕様を明確化します。信頼性レベルを示しながら要件定義を作成します。

context

出力ディレクトリ="docs/spec" 要件名={{requirement_name}} PRDファイル={{prd_file_path}} 作業規模={{work_scope}} 信頼性評価=[]

step

• $ARGUMENTS がない場合、「引数に要件名を指定してください（例: ユーザー認証システム）。PRDファイルがあればパスも指定してください（例: ユーザー認証システム docs/prd/auth-prd.md）」と言って終了する
• $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
• step2 を実行する

step2: 作業規模の確認

• AskUserQuestion ツールを使って作業規模を質問する：
• question: "この要件の作業規模について教えてください"
• header: "作業規模"
• multiSelect: false
• options:
• label: "フル機能開発（推奨）"

description: "詳細なEARS要件定義、包括的なユーザーストーリー、完全な受け入れ基準、非機能要件・エッジケース含む"

• label: "軽量開発"

description: "必要最小限の要件定義、基本的なユーザーストーリーのみ、主要な受け入れ基準のみ、非機能要件は最低限"

• label: "カスタム"

description: "含めたい項目を個別に選択"

• ユーザーの選択を context の {{work_scope}} に保存

• カスタムを選択した場合は、AskUserQuestion ツールを使って以下を質問：
• question: "要件定義書に含める項目を選択してください（複数選択可）"
• header: "含める項目"
• multiSelect: true
• options:
• label: "詳細なユーザーストーリー"

description: "包括的なユーザーストーリーを作成"

• label: "非機能要件の詳細化"

description: "パフォーマンス・セキュリティ等の詳細な非機能要件"

• label: "エッジケースの洗い出し"

description: "エラー処理・境界値等のエッジケース"

• label: "パフォーマンス要件"

description: "詳細なパフォーマンス要件の定義"

• step3 を実行する

step3: 開発コンテキストの準備

• **タスクノートの読み込み**
• `docs/spec/{要件名}/note.md` が存在する場合は読み込み
• 存在しない場合:
• Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki-legacy:kairo-tasknote {要件名}` コマンドを実行してノートを生成
• 生成されたノートファイルを読み込み
• ノートには技術スタック、開発ルール、関連実装、設計文書、注意事項が含まれる

• **PRDファイルの読み込み**（引数で指定された場合）
• {{prd_file_path}} が指定されている場合は読み込み
• PRD（Product Requirements Document）には以下が含まれることを期待：
• プロダクトビジョン
• ターゲットユーザー
• 主要機能
• ビジネス要件
• 成功指標

• **追加ルールの読み込み**
• `docs/rule` ディレクトリが存在する場合は読み込み
• `docs/rule/kairo` ディレクトリが存在する場合は読み込み
• `docs/rule/kairo/requirements` ディレクトリが存在する場合は読み込み
• 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用

• **プロジェクト基本情報収集**
• `CLAUDE.md` の内容を読み込み（プロジェクト概要・技術スタック・制約）
• `README.md` が存在する場合は読み込み
• プロジェクト構造（ディレクトリ構成）を把握

• **既存設計文書・仕様書の調査**
• `docs/` ディレクトリ配下の関連設計文書を確認
• 既存の要件定義書・設計書を読み込み
• タスク管理ファイル（phase*.md）の内容確認
• API仕様書・DB設計書があれば確認

• **既存コードベース・開発状況の分析**（オプション）
• AskUserQuestion ツールを使ってユーザーに確認:
• question: "既存コードベースの詳細分析が必要ですか？"
• header: "コード分析"
• multiSelect: false
• options:
• label: "必要"

description: "既存仕様・実装の網羅的調査、開発状況・進捗確認、差分分析を実施"

• label: "不要"

description: "設計文書のみで要件定義を作成"

• 「必要」を選択した場合のみ:
• Task tool (subagent_type: Explore, thoroughness: medium) を使用して既存仕様・実装の網羅的調査
• git status/log で現在の開発状況・進捗確認
• 実装済み機能 vs 設計書の差分分析
• 残タスク・未実装部分の特定

• **収集情報のサマリー作成**
• 既存プロジェクトの全体像整理
• 定義済み要件・未定義部分の特定
• 技術制約・非機能要件の整理
• ギャップ分析（設計 vs 実装 vs ユーザー期待）

• 読み込み完了後、step4 を実行する

step4: 既存情報ベースの差分ヒアリング

作業規模に応じてヒアリング項目を調整。 **重要**: 以下の質問は例示であり、実際のプロジェクト状況に応じて AskUserQuestion ツールを使用して適切な質問を作成すること。

フル機能開発の場合

以下のカテゴリごとに、既存情報（PRD、設計文書、実装）から特定した具体的な課題・不明点について AskUserQuestion ツールで質問する：

**既存設計の妥当性・過不足確認**

• 既存の機能要件・非機能要件の確認が必要な場合、具体的な項目について質問
• 現在の制約事項（性能・データ制限等）の妥当性に疑問がある場合、その内容について質問
• 技術スタック選択について確認が必要な場合、その理由とともに質問
• 既存設計で実現困難・不適切な部分を発見した場合、代替案とともに質問

例: AskUserQuestion ツールで以下のように質問

• question: "現在のCLAUDE.mdで定義されている{具体的な制約事項}について、実際の運用で問題ないでしょうか？"
• header: "制約確認"
• multiSelect: false
• options:
• label: "問題ない"

description: "現在の制約事項で運用可能"

• label: "変更が必要"

description: "制約の見直しが必要（その他で詳細を記入）"

**未定義・曖昧部分の詳細化ヒアリング**

• 設計文書で詳細が不明な機能について、具体的な動作を質問
• ユーザーの実際の業務フロー・ユースケースについて質問
• 入出力データの詳細仕様について質問
• UI/UX の具体的な期待値について質問

**追加・変更要件の特定**

• 既存設計にない新規機能要件について質問
• 外部システム連携の追加需要について質問
• レポート・分析機能等の追加需要について質問
• 運用・メンテナンス要件の追加について質問

**既存機能への影響範囲確認**

• 新規要件による既存機能への影響について質問
• パフォーマンス要件への影響について質問
• セキュリティ・アクセシビリティ要件への影響について質問
• データ移行・互換性要件について質問

**優先順位・スコープ調整** 複数の要件がある場合、AskUserQuestion ツールで優先順位を質問:

• question: "以下の要件の優先順位を教えてください（複数選択可）"
• header: "優先順位"
• multiSelect: true
• options: （実際の要件リストから動的に生成）

軽量開発の場合

**必須項目のみ確認** AskUserQuestion ツールを使って、以下の項目について簡潔に質問:

• 主要な機能要件の確認（3-5項目程度）
• 基本的な制約事項の確認
• 最低限のエラーケース確認
• 優先順位（Must Have のみ）

カスタム開発の場合

step2 で選択した項目に関連するヒアリングのみ実施。 AskUserQuestion ツールを使って、選択された項目に応じた質問を作成する。

**注意事項**:

• すべての質問を一度に投げるのではなく、文脈に応じて段階的に質問する
• ユーザーの回答を受けて、必要に応じて追加質問を行う
• 質問は具体的で、はい/いいえで答えられるか、選択肢から選べる形式にする
• 自由記述が必要な場合は「その他」オプションを用意する

**ヒアリング記録の作成**:

• すべての質問と回答を記録する
• 各質問について、以下を記録：
• 質問内容
• 質問日時
• カテゴリ（既存設計確認/未定義部分詳細化/追加要件/影響範囲/優先順位）
• 質問の背景（なぜこの質問が必要だったか）
• ユーザーからの回答
• 信頼性への影響（この回答により信頼性レベルがどう変化したか）
• ヒアリング結果のサマリーを作成：
• 確認できた事項
• 追加/変更要件
• 残課題
• 信頼性レベル分布（ヒアリング前後の比較）
• この記録は後で `interview-record.md` として出力する

• step5 を実行する

step5: 統合要件定義書作成

• 作業規模に応じた <requirements_template> を選択：
• フル機能開発: <full_requirements_template>
• 軽量開発: <minimal_requirements_template>
• カスタム: 選択項目に応じた組み合わせ

• context の情報でテンプレートを埋めて、以下のファイルを直接作成する
• 読み込んだコンテキスト情報（タスクノート、追加ルール、PRD等）を活用
• **重要**: すべてのファイルのすべての項目に信頼性レベル（🔵🟡🔴）を記載
• Write ツールを使用して出力ファイルに保存

• **出力ファイル**:

1. `docs/spec/{要件名}/requirements.md`: 統合機能要件と関連文書へのリンク

• <full_requirements_template> または <minimal_requirements_template> を使用
• 各要件に信頼性レベル（🔵🟡🔴）と出典を記載

2. `docs/spec/{要件名}/interview-record.md`: ヒアリング記録

• <interview_record_template> を使用
• step4の質問と回答を記録
• 信頼性レベルの変化を記録

3. フル機能開発の場合:

• `docs/spec/{要件名}/user-stories.md`: 詳細なユーザストーリー
• <user_stories_template> を使用
• **重要**: 各ストーリーに信頼性レベル（🔵🟡🔴）と出典を記載
• 信頼性レベルサマリーを含める

• `docs/spec/{要件名}/acceptance-criteria.md`: 受け入れ基準とテスト項目
• <acceptance_criteria_template> を使用
• **重要**: 各受け入れ基準とテストケースに信頼性レベル（🔵🟡🔴）と出典を記載
• 信頼性レベル分布を含める

• 作成した要件定義書の内容について、品質判定基準に基づいて以下を評価：
• 要件の曖昧さの有無
• 入出力定義の完全性
• 制約条件の明確性
• 実装可能性
• 信頼性レベル（🔵🟡🔴の分布）- すべてのファイルを通じて集計

• 品質判定結果をユーザーに表示する（全ファイル統合の信頼性レベル分布を含む）
• step5b