tdd-requirements

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内容に記録