/tdd-requirements

description: TDD開発の要件整理を行います。機能要件を明確化し、テスト駆動開発のための準備を行います。
allowed-tools: Read, Glob, Grep, Task, Write, TodoWrite, Edit
argument-hint: "[要件名] [TASK-ID]"

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

context

出力ディレクトリ="./docs/implements" 機能名={{feature_name}} タスクID={{task_id}} 要件名={{requirement_name}} 信頼性評価=[] タスクファイル1=./docs/tasks/{要件名}/{{task_id}}.md タスクファイル2=./docs/tasks/{要件名}-phase*.md タスクoverviewファイル1=./docs/tasks/{要件名}/overview.md タスクoverviewファイル2=./docs/tasks/{要件名}-overview.md 出力ファイル=./docs/implements/{要件名}/{{task_id}}/{feature_name}-requirements.md

step

• $ARGUMENTS がない場合、「引数に要件名とTASK-IDを指定してください（例: ユーザー認証機能 TASK-0001）」と言って終了する
• $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
• step2 を実行する

step2

• 開発コンテキストの準備を実行する：

**タスクノートの読み込み**

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

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

step3

• <requirements_template> の内容を context の情報で埋めて、要件定義書を直接作成する
• 読み込んだコンテキスト情報（タスクノート、追加ルール等）を活用
• 信頼性レベル（🔵🟡🔴）を各項目に記載
• Write ツールを使用して 出力ファイル に保存

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

• 品質判定結果をユーザーに表示する
• step4 を実行する

step4

• TodoWrite ツールで TODO ステータスを更新する
• 現在のTODOを「completed」にマーク
• 要件定義フェーズの完了をTODO内容に反映
• 次のフェーズ「テストケース洗い出し」をTODOに追加
• 品質判定結果をTODO内容に記録
• 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:tdd-testcases {{要件名}} {{TASK-ID}}` でテストケースの洗い出しを行います。」

rules

ファイル名のルール

出力ファイルのパス形式

• `docs/implements/{要件名}/{task_id}/{feature_name}-requirements.md`
• 例: `docs/implements/user-auth/task-001/login-requirements.md`

ファイル名の命名規則

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

品質判定基準

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

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

TODO更新パターン

- 現在のTODOを「completed」にマーク
- 要件定義フェーズの完了をTODO内容に反映
- 次のフェーズ「テストケース洗い出し」をTODOに追加
- 品質判定結果をTODO内容に記録

信頼性レベル指示

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

• 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
• 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
• 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合

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

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

info

<requirements_template> あなたはTDD開発の要件整理担当者です。以下の情報に基づいて、機能要件を明確化してください。

要件整理対象の情報

機能名: {{機能名}} タスクID: {{タスクID}} 要件名: {{要件名}} 出力ファイル名: {{出力ファイル名}}

重要な注意事項

**すべてのファイルパスは、プロジェクトルートを基準とした相対パスで記載してください。** **絶対パス（/Users/... や C:\\... など）は使用しないでください。**

例:

• ❌ `/Users/username/projects/myapp/src/utils/helper.ts`
• ✅ `src/utils/helper.ts`

要件整理手順

既に読み込まれた以下のコンテキスト情報を活用してください：

• **タスクノート**（`note.md`）
• 技術スタック（使用技術・フレームワーク・アーキテクチャパターン）
• 開発ルール（コーディング規約・型チェック・テスト要件）
• 関連実装（既存の実装パターン・参考コード）
• 設計文書（データモデル・ディレクトリ構造）
• 注意事項（技術的制約・セキュリティ要件・パフォーマンス要件）
• 追加ルール（`docs/rule`, `docs/rule/tdd`, `docs/rule/tdd/requirements`）
• 既存の要件定義・テストケース

これらの情報を基に、以下のフォーマットで要件を整理してください。

TDD用要件整理フォーマット

**【信頼性レベル指示】**: 各項目について、元の資料（EARS要件定義書・設計文書含む）との照合状況を以下の信号でコメントしてください：

• 🔵 **青信号**: EARS要件定義書・設計文書を参考にしてほぼ推測していない場合
• 🟡 **黄信号**: EARS要件定義書・設計文書から妥当な推測の場合
• 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合

1. 機能の概要（EARS要件定義書・設計文書ベース）

• 🔵🟡🔴 各項目の信頼性レベルを記載
• 何をする機能か（ユーザストーリーから抽出）
• どのような問題を解決するか（As a / So that から抽出）
• 想定されるユーザー（As a から抽出）
• システム内での位置づけ（アーキテクチャ設計から抽出）
• **参照したEARS要件**: [具体的な要件ID]
• **参照した設計文書**: [architecture.md の該当セクション]

2. 入力・出力の仕様（EARS機能要件・TypeScript型定義ベース）

• 🔵🟡🔴 各項目の信頼性レベルを記載
• 入力パラメータ（型、範囲、制約）- interfaces.tsから抽出
• 出力値（型、形式、例）- interfaces.tsから抽出
• 入出力の関係性
• データフロー（dataflow.mdから抽出）
• **参照したEARS要件**: [具体的なREQ-XXX]
• **参照した設計文書**: [interfaces.ts の該当インターフェース]

3. 制約条件（EARS非機能要件・アーキテクチャ設計ベース）

• 🔵🟡🔴 各項目の信頼性レベルを記載
• パフォーマンス要件（NFR-XXXから抽出）
• セキュリティ要件（NFR-XXXから抽出）
• 互換性要件（REQ-XXX MUSTから抽出）
• アーキテクチャ制約（architecture.mdから抽出）
• データベース制約（database-schema.sqlから抽出）
• API制約（api-endpoints.mdから抽出）
• **参照したEARS要件**: [具体的なNFR-XXX, REQ-XXX]
• **参照した設計文書**: [architecture.md, database-schema.sql等の該当セクション]

4. 想定される使用例（EARSEdgeケース・データフローベース）

• 🔵🟡🔴 各項目の信頼性レベルを記載
• 基本的な使用パターン（通常要件REQ-XXXから抽出）
• データフロー（dataflow.mdから抽出）
• エッジケース（EDGE-XXXから抽出）
• エラーケース（EDGE-XXXエラー処理から抽出）
• **参照したEARS要件**: [具体的なEDGE-XXX]
• **参照した設計文書**: [dataflow.md の該当フロー図]

5. EARS要件・設計文書との対応関係

既存のEARS要件定義書・設計文書を参照した場合、以下の対応関係を明記してください：

• **参照したユーザストーリー**: [ストーリー名]
• **参照した機能要件**: [REQ-001, REQ-002, ...]
• **参照した非機能要件**: [NFR-001, NFR-101, ...]
• **参照したEdgeケース**: [EDGE-001, EDGE-101, ...]
• **参照した受け入れ基準**: [具体的なテスト項目]
• **参照した設計文書**:
• **アーキテクチャ**: [architecture.md の該当セクション]
• **データフロー**: [dataflow.md の該当フロー図]
• **型定義**: [interfaces.ts の該当インターフェース]
• **データベース**: [database-schema.sql の該当テーブル]
• **API仕様**: [api-endpoints.md の該当エンドポイント]

出力形式

上記のフォーマットに従って、要件定義書を作成してください。

必ず Write ツールを使用して、{{出力ファイル}} に結果を保存してください。 </requirements_template>