Uat test design

任意のプロジェクトから UAT・受入試験の試験項目一覧を生成する汎用 skill。特定プロジェクトのパス・番号体系はハードコードせず、毎回実測して適応する。

アーキテクチャ原則（必ず守る）

1. 親（この skill を実行するエージェント）は試験項目の本文を読まない・書かない（Phase 4 の散発修正を除く）。抽出サブエージェントが出力ファイルに直接書き、親はメタデータ要約のみ扱う
2. ID レンジは親が事前配布し、サブエージェントはレンジ内でのみ採番する
3. 読込は予算制: サブエージェント 1 体 10,000 行 / 30 ファイルまで。超える担当範囲は分割してから委譲
4. 除外は機械基準（references/source-categories.md §2）。名指し除外はしない
5. ★（低優先）情報源は逆引き専用。全読み禁止
6. 過去メモ・ドキュメント記載の件数・パスを信用しない。inventory.sh で毎回実測する
7. 自動化カバレッジ判定を必ず行う（references/test-levels.md §7）。L2 の各項目について UnitTest / E2E でのカバー状況を判定し、分離条件を満たす項目は本文ごと L2-<group>-covered.md へ分離する（UAT 本体の件数肥大を防ぐ。迷ったら UAT 本体に残す）
8. 出力先は実行ごとに日付ディレクトリ: 既定 <repo>/docs/uat/<yyyymmdd>/。実行開始時に date +%Y%m%d で決定し、同名ディレクトリが既に存在する場合は date +%H%M を付けた <yyyymmdd>-<HHMM> を使う。以降の全フェーズ・全サブエージェントで同じ出力先を固定する

Phase 1: インベントリ

1. 実測: bash {skill_dir}/scripts/inventory.sh <repo-root> を実行し、集計のみ読む（対象ファイルの本文は読まない）
2. 判定: references/source-categories.md に従い、(a) カテゴリごとの情報源候補、(b) [閾値超過]/[生成物] フラグから「精読 / 分割精読 / 逆引き専用 / 除外」の扱い、(c) 性質タグ（正 / 逆 / なし）を決める。カテゴリ検出のヒットが曖昧な場合のみ、候補パスの見出し・冒頭 20 行程度で裏取りしてよい
3. ユーザ確認（AskUserQuestion、必須バッテリー）: スキャン結果の要約（見つかった情報源 / 見つからなかったカテゴリ / 規模感）を提示した上で聞く:
   • 追加資料: リポジトリ外の要件定義・設計書・議事録等の有無（性質「正」が無い場合は特に強調して確認）
   • 実施環境: 環境名 / テナント / 外部サービス（決済・認証・通知）のサンドボックス・テストアカウントの有無（「不明」も回答として許容し前提欄に明記）
   • 方針（既定値を推奨として提示): 実施主体の範囲（UAT＋受入の両方が既定）/ 自動テストとの重複方針（カバレッジ判定して分離条件該当項目を L2-<group>-covered.md へ分離するが既定。test-levels.md §7。「分離せず判定列のみ付ける」も選択可）/ 非機能の範囲（含めるが既定）
   • 出力: フォーマット（markdown 既定、xlsx 追加可）/ 出力先（<repo>/docs/uat/<yyyymmdd>/ 既定。原則 8 の規則で決定した実パスを提示する）/ 対象範囲の絞り込み
4. 成果物: _inventory.md（情報源マップ。列: カテゴリ / パス / 規模 / 性質タグ / 扱い / 備考）を出力先に書く。以降の全フェーズはこれを正とする

Phase 2: 分類（委譲計画）

1. 機能グループ一覧の導出（優先順）:
   1. 機能グループを列挙した既存ドキュメント（feature-groups、機能一覧、README）があれば採用
   2. なければ Explore サブエージェント 1 体に「ルーティング定義＋仕様ディレクトリ名から機能グループ一覧（10〜20 個目安）を合成」させる（読むのはファイル名・見出しのみ）
   3. それも困難なら画面一覧をグループとし、ユーザに提示して調整
2. 名寄せ表: グループごとに「仕様 / E2E spec / 単体テスト / 画面・ルート」の対応パスを表にする（単体テストは inventory.sh §3.5 の検出結果から対応づける。カバレッジ判定の入力になる）。パス名・見出しの文字列マッチで機械的に対応づけ、不確かな対応は ? を付けて抽出サブエージェントに検証させる
3. 委譲計画: グループごとの読込見積り（対応パスの行数合計）を出し、予算超過グループは分割。L3 用に非機能・運用担当 1 体を別途計画
4. ID レンジ配布: references/output-format.md §4 の規約で割当。inventory.sh §3 の検出接頭辞と衝突しないか確認
5. 成果物: _group-map.md（名寄せ表＋ID レンジ＋読込見積り）

Phase 3: 抽出（並列委譲）

references/extraction-prompts.md のテンプレートを実値で埋めて委譲する。独立した委譲は 1 メッセージにまとめて並列実行（model: 既定 sonnet）。

1. グループ担当 × N（テンプレート A）: L2 項目を抽出し、カバレッジ判定（test-levels.md §7）の上で UAT 対象を L2-<group>.md、分離条件該当を L2-<group>-covered.md に直接書かせ、YAML メタデータ要約のみ受け取る。L1 候補は 1 行サマリで回収
2. L3 担当 × 1(テンプレート C): L3-nonfunctional.md と gaps.md（情報源が無く項目化できない確認活動）を書かせる
3. 全グループの要約が揃ったら L1 統合担当 × 1（テンプレート B）: 全グループの L1 候補サマリを渡し、重複統合した End-to-End シナリオを L1-scenarios.md に書かせる
4. 要約の sources_missing / budget_note に問題があれば、該当グループのみ範囲を調整して再委譲

Phase 4: 統合・レビュー

1. index 生成: 親がメタデータ要約と各ファイルの見出し行（grep '^### UAT-'、covered ファイル含む）から index.md を生成（前提欄は references/output-format.md §2。性質「正」なしの場合のフォールバック文言を忘れない）。各項目に手動実施階層（test-levels.md §7。区分×カバレッジから機械導出）を付与し、L2 のサマリ表は階層①〜④でサブセクション分割、冒頭に機能グループ×階層の件数サマリを置く。サマリ表上で対象機能×観点が近い ID ペアを重複疑いとして列挙
2. 独立レビュー: references/review-prompt.md でレビューサブエージェントに委譲（総数 150 件超はサンプリング 30%）。指摘の反映は同ファイルの「親の後処理」に従う（系統的問題→グループ再実行 / 散発→親が該当セクションのみ Edit）
3. 件数妥当性: references/test-levels.md §6 の規模別目安と比較し、大きく外れたら原因（情報源不足 / 分割ミス / カバレッジ分離の効きすぎ・効かなさすぎ）をユーザに報告。UAT 本体件数と分離件数を分けて評価する
4. xlsx 変換（ユーザが選択した場合のみ): output-format.md §6 の構成で生成
5. 完了報告: 件数サマリ（L1 / L2 を手動実施階層①〜④別 / L3 / gaps）、トレース率、sources_missing・gaps の要点、レビュー指摘の反映状況、出力先ディレクトリを簡潔に報告する。項目本文の再掲はしない

途中で詰まったら

• 情報源カテゴリが軒並み「なし」: 続行せず、ユーザに資料所在を確認（コードのみからの生成は L2 の期待結果が創作になるため）
• グループ数が 30 超 or L2 見込みが 800 超: 対象範囲の絞り込み（フェーズ分割・優先機能の選定）を AskUserQuestion で提案
• サブエージェントの要約が YAML 形式で返らない: 結果ファイルの見出し数（grep -c '^### UAT-'）で件数を代替集計し、再委譲はしない