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: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 agent-symbol-searcher で既存仕様・実装の網羅的調査
  - 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> を使用
    - 重要: 各受け入れ基準とテストケースに信頼性レベル（🔵🟡🔴）と出典を記載
    - 信頼性レベル分布を含める
作成した要件定義書の内容について、品質判定基準に基づいて以下を評価：
- 要件の曖昧さの有無
- 入出力定義の完全性
- 制約条件の明確性
- 実装可能性
- 信頼性レベル（🔵🟡🔴の分布）- すべてのファイルを通じて集計
品質判定結果をユーザーに表示する（全ファイル統合の信頼性レベル分布を含む）
step6 を実行する

step6: 完了報告とTODO更新

TodoWrite ツールで TODO ステータスを更新する
- 現在のTODOを「completed」にマーク
- 要件定義フェーズの完了をTODO内容に反映
- 次のフェーズ「設計文書作成」をTODOに追加
- 品質判定結果をTODO内容に記録
完了報告を表示：
- Phase 0で収集した既存プロジェクト情報のサマリー
- Phase 1でのヒアリング結果と既存情報との差分
- 作成したファイルのパス一覧（requirements.md, interview-record.md, user-stories.md, acceptance-criteria.md）
- 各ファイルの信頼性レベル分布
- 全体の信頼性レベル分布（すべてのファイルを通じた集計）
- 既存要件からの変更点・追加点の件数
- 各ファイル内のリンクが正しく設定されていることを確認
- 既存設計書・実装との整合性確認を促すメッセージ
次のステップ表示: 「次のお勧めステップ: /tsumiki:kairo-design {要件名} で技術設計文書を作成します。」

rules

ファイル名のルール

出力ファイルのパス形式

docs/spec/{要件名}/requirements.md
docs/spec/{要件名}/interview-record.md
docs/spec/{要件名}/user-stories.md (フル機能開発のみ)
docs/spec/{要件名}/acceptance-criteria.md (フル機能開発のみ)
docs/spec/{要件名}/note.md (コンテキストノート)

ファイル名の命名規則

要件名を簡潔な英語に変換する
ケバブケース（kebab-case）を使用
最大50文字程度に収める
例:
- "ユーザー認証システム" → "user-auth-system"
- "データエクスポート機能" → "data-export"
- "パスワードリセット" → "password-reset"

品質判定基準

✅ 高品質:
- 要件の曖昧さ: なし
- 入出力定義: 完全
- 制約条件: 明確
- 実装可能性: 確実
- 信頼性レベル: 🔵（青信号）が多い

⚠️ 要改善:
- 要件に曖昧な部分がある
- 入出力の詳細が不明確
- 技術的制約が不明
- ユーザー意図の確認が必要
- 信頼性レベル: 🟡🔴（黄・赤信号）が多い

TODO更新パターン

- 現在のTODOを「completed」にマーク
- 要件定義フェーズの完了をTODO内容に反映
- 次のフェーズ「設計文書作成」をTODOに追加
- 品質判定結果をTODO内容に記録

信頼性レベル指示

各項目について、元の資料（PRD・EARS要件定義書・設計文書・ユーザヒアリング含む）との照合状況を以下の信号でコメントしてください：

🔵 青信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングを参考にしてほぼ推測していない場合
🟡 黄信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測の場合
🔴 赤信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングにない推測の場合

ファイルパスの記載ルール

プロジェクトルートを基準とした相対パスを使用する
フルパス（絶対パス）は記載しない
例:
- ❌ /Users/username/projects/myapp/src/utils/helper.ts
- ✅ src/utils/helper.ts

作業規模別の出力調整

フル機能開発

すべてのセクションを含む
詳細なユーザーストーリー作成
包括的な受け入れ基準作成
非機能要件・エッジケースを網羅

軽量開発

機能要件の主要項目のみ（3-5項目）
ユーザーストーリーは requirements.md 内に簡易記載
受け入れ基準は基本項目のみ
非機能要件は最低限

カスタム

選択された項目のみ含める
必要に応じてファイルを分割

info

AskUserQuestion ツールの使用例

すべてのヒアリングは AskUserQuestion ツールを使用して行います。以下は具体的な使用例です。

既存設計確認系質問

AskUserQuestion({
  questions: [{
    question: "現在のCLAUDE.mdで定義されている{具体的な制約事項}について、実際の運用で問題ないでしょうか？",
    header: "制約確認",
    multiSelect: false,
    options: [
      {
        label: "問題ない",
        description: "現在の制約事項で運用可能"
      },
      {
        label: "変更が必要",
        description: "制約の見直しが必要"
      }
    ]
  }]
})

詳細化系質問（複数選択）

AskUserQuestion({
  questions: [{
    question: "この機能で必要な操作を選択してください",
    header: "必要な操作",
    multiSelect: true,
    options: [
      {
        label: "データの追加",
        description: "新しいデータを追加する機能"
      },
      {
        label: "データの編集",
        description: "既存データを編集する機能"
      },
      {
        label: "データの削除",
        description: "データを削除する機能"
      },
      {
        label: "データの検索",
        description: "データを検索する機能"
      }
    ]
  }]
})

追加要件系質問

AskUserQuestion({
  questions: [{
    question: "レポート・分析機能は必要ですか？",
    header: "レポート機能",
    multiSelect: false,
    options: [
      {
        label: "必要",
        description: "レポート・分析機能を実装する"
      },
      {
        label: "不要",
        description: "レポート機能は不要"
      }
    ]
  }]
})

優先順位確認（複数質問）

AskUserQuestion({
  questions: [
    {
      question: "以下の要件の中で、Must Have（必須）の項目を選択してください",
      header: "Must Have",
      multiSelect: true,
      options: [
        {
          label: "ユーザー認証",
          description: "ログイン・ログアウト機能"
        },
        {
          label: "データ管理",
          description: "CRUD操作"
        },
        {
          label: "レポート機能",
          description: "データの集計・出力"
        }
      ]
    },
    {
      question: "リリーススコープについて教えてください",
      header: "リリース計画",
      multiSelect: false,
      options: [
        {
          label: "一括リリース",
          description: "すべての機能を同時にリリース"
        },
        {
          label: "段階的リリース",
          description: "フェーズごとに段階的にリリース"
        }
      ]
    }
  ]
})

影響確認系質問

AskUserQuestion({
  questions: [{
    question: "この新機能により、既存の{機能名}の変更は許容できますか？",
    header: "影響許容度",
    multiSelect: false,
    options: [
      {
        label: "許容できる",
        description: "既存機能の変更を許容"
      },
      {
        label: "最小限にしてほしい",
        description: "既存機能への影響を最小限に"
      },
      {
        label: "変更不可",
        description: "既存機能は変更しない"
      }
    ]
  }]
})

注意事項

header は12文字以内の短いラベル
question は明確で具体的な質問文
options は2-4個の選択肢
multiSelect は複数選択可能にする場合true
ユーザーは常に「その他」を選択して自由記述できる（自動提供）

<full_requirements_template>

{要件名} 要件定義書

概要

{要件の概要}

機能要件（EARS記法）

【信頼性レベル凡例】:

🔵 青信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実な要件
🟡 黄信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測による要件
🔴 赤信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングにない推測による要件

通常要件

REQ-001: システムは {通常の動作} しなければならない 🔵 PRD第3章より
REQ-002: システムは {通常の動作} しなければならない 🟡 設計文書から妥当な推測

条件付き要件

REQ-101: {条件} の場合、システムは {動作} しなければならない 🔵 ユーザヒアリング2024-01-15より

状態要件

REQ-201: {状態} にある場合、システムは {動作} しなければならない 🟡 DB設計書から妥当な推測

オプション要件

REQ-301: システムは {オプション機能} してもよい 🔵 CLAUDE.md技術制約より

制約要件

REQ-401: システムは {制約事項} しなければならない 🔵 CLAUDE.md・既存実装より

非機能要件

パフォーマンス

NFR-001: {パフォーマンス要件} 🟡 CLAUDE.md制約から妥当な推測

セキュリティ

NFR-101: {セキュリティ要件} 🔵 セキュリティ設計書・実装より

ユーザビリティ

NFR-201: {ユーザビリティ要件} 🔵 ユーザヒアリング2024-01-20 UX要望より

Edgeケース

エラー処理

EDGE-001: {エラーケース} 🟡 既存実装から妥当な推測

境界値

EDGE-101: {境界値ケース} 🔵 API仕様書・テストケースより </full_requirements_template>

<minimal_requirements_template>

{要件名} 要件定義書（軽量版）

概要

{要件の概要}

主要機能要件

【信頼性レベル凡例】:

🔵 青信号: PRD・設計文書・ユーザヒアリングを参考にした確実な要件
🟡 黄信号: PRD・設計文書・ユーザヒアリングから妥当な推測による要件
🔴 赤信号: PRD・設計文書・ユーザヒアリングにない推測による要件

必須機能（Must Have）

REQ-001: {主要機能1} 🔵 PRDより
REQ-002: {主要機能2} 🔵 ユーザヒアリングより
REQ-003: {主要機能3} 🟡 設計文書から妥当な推測

基本的な制約

REQ-401: {基本的な制約事項} 🔵 CLAUDE.mdより

簡易ユーザーストーリー

ストーリー1: {機能名}

私は {ユーザー種別} として {具体的な行動} をしたい そうすることで {得られる価値}

関連要件: REQ-001

基本的な受け入れ基準

REQ-001: {要件名}

Given（前提条件）: {テスト実行前の状態} When（実行条件）: {実行するアクション} Then（期待結果）: {期待される出力・状態}

テストケース:

正常系: {正常なケースの詳細}
主要な異常系: {主要な異常ケース}

最小限の非機能要件

パフォーマンス: {基本的な性能要求}
セキュリティ: {最低限のセキュリティ要求} </minimal_requirements_template>

<interview_record_template>

{要件名} ヒアリング記録

作成日: {作成日時} ヒアリング実施: step4 既存情報ベースの差分ヒアリング

ヒアリング目的

既存の設計文書・PRD・実装を確認し、不明点や曖昧な部分を明確化するためのヒアリングを実施しました。

質問と回答

Q1: {質問内容}

質問日時: {日時} カテゴリ: {既存設計確認/未定義部分詳細化/追加要件/影響範囲/優先順位} 背景: {なぜこの質問が必要だったか}

回答: {ユーザーからの回答}

信頼性への影響:

この回答により、{影響を受けた要件ID} の信頼性レベルが 🔴 → 🔵 に向上
{具体的な影響内容}

Q2: {質問内容}

質問日時: {日時} カテゴリ: {カテゴリ名} 背景: {背景説明}

回答: {ユーザーからの回答}

信頼性への影響:

この回答により、新規要件 {要件ID} を追加（信頼性レベル: 🔵）

ヒアリング結果サマリー

確認できた事項

{確認できた事項1}
{確認できた事項2}

追加/変更要件

{追加要件1}
{変更要件1}

残課題

{まだ不明確な点1}
{まだ不明確な点2}

信頼性レベル分布

ヒアリング前:

🔵 青信号: {件数}
🟡 黄信号: {件数}
🔴 赤信号: {件数}

ヒアリング後:

🔵 青信号: {件数} (+{増加数})
🟡 黄信号: {件数} ({増減数})
🔴 赤信号: {件数} (-{減少数})

{要件名} ユーザストーリー

作成日: {作成日時} 関連要件定義: requirements.md ヒアリング記録: interview-record.md

【信頼性レベル凡例】:

🔵 青信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実なストーリー
🟡 黄信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測によるストーリー
🔴 赤信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングにない推測によるストーリー

エピック1: {エピック名}

ストーリー 1.1: {ストーリー名} 🔵

信頼性: 🔵 PRD第2章・ユーザヒアリング2024-01-15より

私は {ユーザー種別（例: 一般ユーザー）} として {具体的な行動（例: タスクを作成したい）} そうすることで {得られる価値（例: 日々のタスクを管理できる）}

関連要件: REQ-001, REQ-002

詳細シナリオ:

{ステップ1の説明}
{ステップ2の説明}
{ステップ3の説明}

前提条件:

{前提条件1}
{前提条件2}

制約事項:

{制約事項1}
{制約事項2}

優先度: Must Have / Should Have / Could Have / Won't Have

ストーリー 1.2: {ストーリー名} 🟡

信頼性: 🟡 設計文書から妥当な推測

私は {ユーザー種別} として {具体的な行動} そうすることで {得られる価値}

関連要件: REQ-003

詳細シナリオ:

{ステップ1の説明}
{ステップ2の説明}

前提条件:

{前提条件1}

優先度: Should Have

備考: {この推測の根拠や確認が必要な理由}

エピック2: {エピック名}

ストーリー 2.1: {ストーリー名} 🔵

信頼性: 🔵 ユーザヒアリング2024-01-20より

私は {ユーザー種別} として {具体的な行動} そうすることで {得られる価値}

関連要件: REQ-101, REQ-102

詳細シナリオ:

{ステップ1の説明}
{ステップ2の説明}
{ステップ3の説明}

優先度: Must Have

ストーリーマップ

エピック1: {エピック名}
├── ストーリー 1.1 (🔵 Must Have)
├── ストーリー 1.2 (🟡 Should Have)
└── ストーリー 1.3 (🔵 Could Have)

エピック2: {エピック名}
├── ストーリー 2.1 (🔵 Must Have)
└── ストーリー 2.2 (🟡 Should Have)

信頼性レベルサマリー

🔵 青信号: {件数}件 ({割合}%)
🟡 黄信号: {件数}件 ({割合}%)
🔴 赤信号: {件数}件 ({割合}%)

品質評価: {高品質/要改善/要ヒアリング} </user_stories_template>

<acceptance_criteria_template>

{要件名} 受け入れ基準

作成日: {作成日時} 関連要件定義: requirements.md 関連ユーザストーリー: user-stories.md ヒアリング記録: interview-record.md

【信頼性レベル凡例】:

🔵 青信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングを参考にした確実な基準
🟡 黄信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングから妥当な推測による基準
🔴 赤信号: PRD・EARS要件定義書・設計文書・ユーザヒアリングにない推測による基準

REQ-001: {要件名} 🔵

信頼性: 🔵 PRD第3章・テストケース仕様書より

Given（前提条件）

{テスト実行前の状態1}
{テスト実行前の状態2}

When（実行条件）

{ユーザーが実行するアクション}

Then（期待結果）

{期待される出力1}
{期待される状態変化2}

テストケース

正常系

TC-001-01: {テストケース名} 🔵
- 入力: {入力データ}
- 期待結果: {期待される出力}
- 信頼性: 🔵 既存テストケースより
TC-001-02: {テストケース名} 🔵
- 入力: {入力データ}
- 期待結果: {期待される出力}
- 信頼性: 🔵 ユーザヒアリングより

異常系

TC-001-E01: {エラーケース名} 🟡
- 入力: {異常な入力データ}
- 期待結果: {エラーメッセージ/エラー処理}
- 信頼性: 🟡 既存実装から妥当な推測
TC-001-E02: {エラーケース名} 🔵
- 入力: {異常な入力データ}
- 期待結果: {エラーメッセージ/エラー処理}
- 信頼性: 🔵 エラー処理仕様書より

境界値

TC-001-B01: {境界値ケース名} 🔵
- 入力: {境界値データ}
- 期待結果: {期待される動作}
- 信頼性: 🔵 API仕様書より

REQ-002: {要件名} 🟡

信頼性: 🟡 設計文書から妥当な推測

Given（前提条件）

{テスト実行前の状態}

When（実行条件）

{ユーザーが実行するアクション}

Then（期待結果）

{期待される出力}

テストケース

正常系

TC-002-01: {テストケース名} 🟡
- 入力: {入力データ}
- 期待結果: {期待される出力}
- 信頼性: 🟡 設計文書から推測
- 備考: {確認が必要な理由}

非機能要件テスト

NFR-001: パフォーマンス 🟡

信頼性: 🟡 CLAUDE.md制約から妥当な推測

TC-NFR-001-01: {パフォーマンステスト名}
- 測定項目: {レスポンスタイム/スループット等}
- 目標値: {具体的な数値}
- 測定条件: {負荷条件等}
- 信頼性: 🟡 技術制約から推測

NFR-101: セキュリティ 🔵

信頼性: 🔵 セキュリティ設計書・実装より

TC-NFR-101-01: {セキュリティテスト名}
- 検証内容: {検証する脆弱性}
- 期待結果: {期待される防御動作}
- 信頼性: 🔵 セキュリティ設計書より

Edgeケーステスト

EDGE-001: {エラー処理ケース} 🟡

信頼性: 🟡 既存実装から妥当な推測

TC-EDGE-001-01: {エッジケーステスト名}
- 条件: {特殊な条件}
- 期待結果: {期待される動作}
- 信頼性: 🟡 実装から推測

テストケースサマリー

カテゴリ別件数

カテゴリ	正常系	異常系	境界値	合計
機能要件	{件数}	{件数}	{件数}	{件数}
非機能要件	{件数}	{件数}	{件数}	{件数}
Edgeケース	{件数}	{件数}	{件数}	{件数}
合計	{件数}	{件数}	{件数}	{件数}

信頼性レベル分布

🔵 青信号: {件数}件 ({割合}%)
🟡 黄信号: {件数}件 ({割合}%)
🔴 赤信号: {件数}件 ({割合}%)

品質評価: {高品質/要改善/要ヒアリング}

優先度別テストケース

Must Have: {件数}件
Should Have: {件数}件
Could Have: {件数}件

テスト実施計画

Phase 1: 基本機能テスト

REQ-001 ~ REQ-050
優先度: Must Have
実施予定: {日付}

Phase 2: 拡張機能テスト

REQ-051 ~ REQ-100
優先度: Should Have
実施予定: {日付}

Phase 3: 非機能・Edgeケーステスト

NFR-001 ~ NFR-999, EDGE-001 ~ EDGE-999
優先度: Must Have + Should Have
実施予定: {日付} </acceptance_criteria_template>

/kairo-requirements

context

step

step2: 作業規模の確認

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

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

フル機能開発の場合

軽量開発の場合

カスタム開発の場合

step5: 統合要件定義書作成

step6: 完了報告とTODO更新

rules

ファイル名のルール

出力ファイルのパス形式

ファイル名の命名規則

品質判定基準

TODO更新パターン

信頼性レベル指示

ファイルパスの記載ルール

作業規模別の出力調整

フル機能開発

軽量開発

カスタム

info

AskUserQuestion ツールの使用例

既存設計確認系質問

詳細化系質問（複数選択）

追加要件系質問

優先順位確認（複数質問）

影響確認系質問

注意事項

{要件名} 要件定義書

概要

関連文書

機能要件（EARS記法）

通常要件

条件付き要件

状態要件

オプション要件

制約要件

非機能要件

パフォーマンス

セキュリティ

ユーザビリティ

Edgeケース

エラー処理

境界値

{要件名} 要件定義書（軽量版）

概要

関連文書

主要機能要件

必須機能（Must Have）

基本的な制約

簡易ユーザーストーリー

ストーリー1: {機能名}

基本的な受け入れ基準

REQ-001: {要件名}

最小限の非機能要件

{要件名} ヒアリング記録

ヒアリング目的

質問と回答

Q1: {質問内容}

Q2: {質問内容}

ヒアリング結果サマリー

確認できた事項

追加/変更要件

残課題

信頼性レベル分布

関連文書

{要件名} ユーザストーリー

エピック1: {エピック名}

ストーリー 1.1: {ストーリー名} 🔵

ストーリー 1.2: {ストーリー名} 🟡

エピック2: {エピック名}

ストーリー 2.1: {ストーリー名} 🔵

ストーリーマップ

信頼性レベルサマリー

{要件名} 受け入れ基準

REQ-001: {要件名} 🔵

Given（前提条件）