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

step

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

step2

• 開発コンテキストの準備を実行する： タスクノートの読み込み

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

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

step3

• <requirements_template> の内容を context の情報で埋めて、要件定義書を直接作成する

  • 読み込んだコンテキスト情報（タスクノート、追加ルール等）を活用
  • 信頼性レベル（🔵🟡🔴）を各項目に記載
  • Write ツールを使用して出力ファイルに保存

• 作成した要件定義書の内容について、品質判定基準に基づいて以下を評価：

  • 要件の曖昧さの有無
  • 入出力定義の完全性
  • 制約条件の明確性
  • 実装可能性
  • 信頼性レベル（🔵🟡🔴の分布）

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

• step4 を実行する

step4

• TodoWrite ツールで TODO ステータスを更新する
  • 現在のTODOを「completed」にマーク
  • 要件定義フェーズの完了をTODO内容に反映
  • 次のフェーズ「テストケース洗い出し」をTODOに追加
  • 品質判定結果をTODO内容に記録
• 次のステップ表示: 「次のお勧めステップ: /tsumiki: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>