Kairo開発の要件整理を実施し、PRD・EARS要件定義書・設計文書を参照しながら機能仕様を明確化します。信頼性レベルを示しながら要件定義を作成します。
Analyzes existing project context and requirements to create comprehensive functional specifications with reliability levels.
/plugin marketplace add classmethod/tsumiki/plugin install tsumiki@tsumikiKairo開発の要件整理を実施し、PRD・EARS要件定義書・設計文書を参照しながら機能仕様を明確化します。信頼性レベルを示しながら要件定義を作成します。
出力ディレクトリ="docs/spec" 要件名={{requirement_name}} PRDファイル={{prd_file_path}} 作業規模={{work_scope}} 信頼性評価=[]
AskUserQuestion ツールを使って作業規模を質問する:
ユーザーの選択を context の {{work_scope}} に保存
カスタムを選択した場合は、AskUserQuestion ツールを使って以下を質問:
step3 を実行する
タスクノートの読み込み
docs/spec/{要件名}/note.md が存在する場合は読み込み/tsumiki:kairo-tasknote {要件名} コマンドを実行してノートを生成PRDファイルの読み込み(引数で指定された場合)
追加ルールの読み込み
docs/rule ディレクトリが存在する場合は読み込みdocs/rule/kairo ディレクトリが存在する場合は読み込みdocs/rule/kairo/requirements ディレクトリが存在する場合は読み込みプロジェクト基本情報収集
CLAUDE.md の内容を読み込み(プロジェクト概要・技術スタック・制約)README.md が存在する場合は読み込み既存設計文書・仕様書の調査
docs/ ディレクトリ配下の関連設計文書を確認既存コードベース・開発状況の分析(オプション)
収集情報のサマリー作成
読み込み完了後、step4 を実行する
作業規模に応じてヒアリング項目を調整。 重要: 以下の質問は例示であり、実際のプロジェクト状況に応じて AskUserQuestion ツールを使用して適切な質問を作成すること。
以下のカテゴリごとに、既存情報(PRD、設計文書、実装)から特定した具体的な課題・不明点について AskUserQuestion ツールで質問する:
既存設計の妥当性・過不足確認
例: AskUserQuestion ツールで以下のように質問
未定義・曖昧部分の詳細化ヒアリング
追加・変更要件の特定
既存機能への影響範囲確認
優先順位・スコープ調整 複数の要件がある場合、AskUserQuestion ツールで優先順位を質問:
必須項目のみ確認 AskUserQuestion ツールを使って、以下の項目について簡潔に質問:
step2 で選択した項目に関連するヒアリングのみ実施。 AskUserQuestion ツールを使って、選択された項目に応じた質問を作成する。
注意事項:
ヒアリング記録の作成:
すべての質問と回答を記録する
各質問について、以下を記録:
ヒアリング結果のサマリーを作成:
この記録は後で interview-record.md として出力する
step5 を実行する
作業規模に応じた <requirements_template> を選択:
context の情報でテンプレートを埋めて、以下のファイルを直接作成する
出力ファイル:
docs/spec/{要件名}/requirements.md: 統合機能要件と関連文書へのリンク
docs/spec/{要件名}/interview-record.md: ヒアリング記録
フル機能開発の場合:
docs/spec/{要件名}/user-stories.md: 詳細なユーザストーリー
docs/spec/{要件名}/acceptance-criteria.md: 受け入れ基準とテスト項目
作成した要件定義書の内容について、品質判定基準に基づいて以下を評価:
品質判定結果をユーザーに表示する(全ファイル統合の信頼性レベル分布を含む)
step6 を実行する
TodoWrite ツールで TODO ステータスを更新する
完了報告を表示:
次のステップ表示: 「次のお勧めステップ: /tsumiki:kairo-design {要件名} で技術設計文書を作成します。」
docs/spec/{要件名}/requirements.mddocs/spec/{要件名}/interview-record.mddocs/spec/{要件名}/user-stories.md (フル機能開発のみ)docs/spec/{要件名}/acceptance-criteria.md (フル機能開発のみ)docs/spec/{要件名}/note.md (コンテキストノート)✅ 高品質:
- 要件の曖昧さ: なし
- 入出力定義: 完全
- 制約条件: 明確
- 実装可能性: 確実
- 信頼性レベル: 🔵(青信号)が多い
⚠️ 要改善:
- 要件に曖昧な部分がある
- 入出力の詳細が不明確
- 技術的制約が不明
- ユーザー意図の確認が必要
- 信頼性レベル: 🟡🔴(黄・赤信号)が多い
- 現在のTODOを「completed」にマーク
- 要件定義フェーズの完了をTODO内容に反映
- 次のフェーズ「設計文書作成」をTODOに追加
- 品質判定結果をTODO内容に記録
各項目について、元の資料(PRD・EARS要件定義書・設計文書・ユーザヒアリング含む)との照合状況を以下の信号でコメントしてください:
/Users/username/projects/myapp/src/utils/helper.tssrc/utils/helper.tsすべてのヒアリングは 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: "既存機能は変更しない"
}
]
}]
})
<full_requirements_template>
{要件の概要}
【信頼性レベル凡例】:
<minimal_requirements_template>
{要件の概要}
【信頼性レベル凡例】:
私は {ユーザー種別} として {具体的な行動} をしたい そうすることで {得られる価値}
関連要件: REQ-001
Given(前提条件): {テスト実行前の状態} When(実行条件): {実行するアクション} Then(期待結果): {期待される出力・状態}
テストケース:
<interview_record_template>
作成日: {作成日時} ヒアリング実施: step4 既存情報ベースの差分ヒアリング
既存の設計文書・PRD・実装を確認し、不明点や曖昧な部分を明確化するためのヒアリングを実施しました。
質問日時: {日時} カテゴリ: {既存設計確認/未定義部分詳細化/追加要件/影響範囲/優先順位} 背景: {なぜこの質問が必要だったか}
回答: {ユーザーからの回答}
信頼性への影響:
質問日時: {日時} カテゴリ: {カテゴリ名} 背景: {背景説明}
回答: {ユーザーからの回答}
信頼性への影響:
ヒアリング前:
ヒアリング後:
<user_stories_template>
作成日: {作成日時} 関連要件定義: requirements.md ヒアリング記録: interview-record.md
【信頼性レベル凡例】:
信頼性: 🔵 PRD第2章・ユーザヒアリング2024-01-15より
私は {ユーザー種別(例: 一般ユーザー)} として {具体的な行動(例: タスクを作成したい)} そうすることで {得られる価値(例: 日々のタスクを管理できる)}
関連要件: REQ-001, REQ-002
詳細シナリオ:
前提条件:
制約事項:
優先度: Must Have / Should Have / Could Have / Won't Have
信頼性: 🟡 設計文書から妥当な推測
私は {ユーザー種別} として {具体的な行動} そうすることで {得られる価値}
関連要件: REQ-003
詳細シナリオ:
前提条件:
優先度: Should Have
備考: {この推測の根拠や確認が必要な理由}
信頼性: 🔵 ユーザヒアリング2024-01-20より
私は {ユーザー種別} として {具体的な行動} そうすることで {得られる価値}
関連要件: REQ-101, REQ-102
詳細シナリオ:
優先度: 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第3章・テストケース仕様書より
TC-001-01: {テストケース名} 🔵
TC-001-02: {テストケース名} 🔵
TC-001-E01: {エラーケース名} 🟡
TC-001-E02: {エラーケース名} 🔵
信頼性: 🟡 設計文書から妥当な推測
信頼性: 🟡 CLAUDE.md制約から妥当な推測
信頼性: 🔵 セキュリティ設計書・実装より
信頼性: 🟡 既存実装から妥当な推測
| カテゴリ | 正常系 | 異常系 | 境界値 | 合計 |
|---|---|---|---|---|
| 機能要件 | {件数} | {件数} | {件数} | {件数} |
| 非機能要件 | {件数} | {件数} | {件数} | {件数} |
| Edgeケース | {件数} | {件数} | {件数} | {件数} |
| 合計 | {件数} | {件数} | {件数} | {件数} |
品質評価: {高品質/要改善/要ヒアリング}