新機能の要件定義

統一基盤の確認

Spec 統一基盤確認 を実施する。

入力の受け取り方（優先順）

1. ユーザーが会話で伝えた内容（「通知機能がほしい」等）
2. docs/drafts/ にファイルがあればそれも参照
3. デザインファイル（スクショやFigmaリンク）があれば分析

ユーザーにdocs/drafts/への記入を求めない。会話から直接要件を引き出すこと。

テンプレート参照

以下のテンプレートを参照し、生成する文書のセクション構成を合わせる：

テンプレート	用途
docs/templates/phase1/requirements-spec.md	要件定義書の構成
docs/templates/phase1/business-flow.md	業務フロー図の構成
docs/templates/phase1/usecase.md	ユースケースの構成
docs/templates/phase1/screen-flow.md	画面一覧・遷移図の構成
docs/templates/phase1/glossary.md	用語定義書の構成
docs/templates/phase2/non-functional.md	非機能要件定義書の構成（インデックス → 性能・可用性・運用の各テンプレートへリンク）

テンプレートが存在しない場合は、従来の手順でそのまま生成する（テンプレート不在でブロックしない）。

手順

本スキルは親=ヒアリング・方針・レビュー / spec-writer(Sonnet)=執筆の分担で進める。

フェーズ1: ヒアリング（親エージェント）

1. ユーザーの入力を分析し、要件のドラフトをまとめる
2. 不足情報を質問する（最大8問、Yes/Noで答えやすい形式）
   • 担当者も確認する。ユーザーが指定しなければ「未定」とする
   • システム全体の共通仕様（技術スタック、非機能要件、外部サービス依存、法的要件等）も確認する
   • 質問カテゴリチェックリスト（該当するもののみ質問に含める）：
     • バリデーション（文字数上限、入力フォーマット、許容値の範囲）
     • エラー・異常系（重複登録、上限超過、期限切れ時の振る舞い）
     • 権限・アクセス制御（ロール別の操作可否、データの可視範囲）
     • 状態遷移（ステータスの遷移制約、無効な遷移の扱い）
     • 同時操作（先勝ち/後勝ち/排他制御の方針）
     • データ削除（論理削除/物理削除、関連データの連鎖削除）
3. OVERVIEW Specの確認・作成判定: docs/requirements/features/ にOVERVIEW（サービス概要）Specが存在するか確認する
   • 存在しない場合: 個別機能の要件定義の前に、まずOVERVIEW Specを作成する（後述「OVERVIEW Specルール」参照）
   • 存在する場合: 内容を読み、今回の要件で追記すべき共通仕様があればOVERVIEW Specも同時に更新する
4. 共通コンポーネントの確認: docs/design/shared-components.md が存在する場合、既存の共通コンポーネントを確認する
   • 今回の要件で再利用できそうな共通コンポーネント（UI部品、ユーティリティ、フック等）を洗い出す
5. 関連機能の発見: 今回の要件に関連する既存機能を特定する
   • overview.md の機能一覧と依存関係セクションを読み、関連する既存Specを特定する

フェーズ2: 執筆プラン整理（親エージェント）

6. 以下を整理し、spec-writer へ渡す委任プロンプトを組み立てる:
   • REQ-ID採番（OVERVIEWの場合は REQ-OVERVIEW-001）
   • 担当者・ステータス・受入条件
   • 生成対象ドキュメントの要否判定:
     • 要件定義書: 常に必須（docs/requirements/features/[REQ-ID].md）
     • 業務フロー図: 既存業務プロセスの変更を伴う、または複雑な業務フローがある場合
     • ユースケース: 複数アクターが異なる操作を行う場合
     • 画面一覧: UIを持つ機能の場合（常に更新）
     • 非機能要件定義書: OVERVIEW Specの初回作成時、または大幅な非機能要件追加時
   • 関連Spec、共通コンポーネントの活用可能性

フェーズ3: 執筆委任（spec-writer、並列可）

7. Agent(subagent_type: spec-writer) に以下を並列で委任する（ファイル単位で独立しているため）:

   委任プロンプト形式:

   あなたは spec-writer です。以下のドキュメントを生成してください。
   
   ## 生成対象
   docs/requirements/features/[REQ-ID].md
   
   ## 参照テンプレート
   docs/templates/phase1/requirements-spec.md
   
   ## 埋める情報
   - REQ-ID: [採番値]
   - 担当者: [名前 or 未定]
   - ステータス: [値]
   - 受入条件: [親が整理した条件リスト]
   - 関連Spec: [特定済みREQ-IDリスト]
   - 活用可能な共通コンポーネント: [リスト]
   - 非機能要件: [OVERVIEWに集約する分は記載しない]
   
   ## ヒアリング結果サマリ
   [フェーズ1で得た回答を整理して渡す]
   
   ## 厳守事項
   - 要件定義書にはWHAT（何を作るか）だけ記載。HOW（API/DB/画面遷移図）は基本設計で別途生成
   - 不明点は「※ 要確認」マーカーを残し、推測で埋めない
   - index系ファイル（overview.md / spec-map.yml / mkdocs.yml / dependency-graph.md）は触らない（親が更新）
   - 完了時に軽量セルフチェックを実行し、結果を報告すること
   

   並列委任する対象（該当するもののみ）:

   • 要件定義書
   • 業務フロー図（docs/requirements/business-flow.md）
   • ユースケース（docs/requirements/usecase.md）
   • 非機能要件定義書（OVERVIEW 初回時のみ、docs/templates/phase2/non-functional.md のインデックス構成）

フェーズ4: index系更新（親エージェント）

spec-writer は index 系に触らないため、親が責任を持って更新する:

8. docs/requirements/overview.md を更新
   • 機能一覧テーブルに REQ-ID・担当を追加
   • 依存関係セクションに今回の機能の依存先・依存元を追記
9. spec-map.yml に新規REQ-IDのエントリを追加し、depends_on に依存先を記載
10. docs/design/dependency-graph.md が存在する場合、新規Specの依存関係を追記（Mermaid図 + 依存マトリクス）
11. mkdocs.yml の nav を更新
12. docs/design/screen-flow.md を更新（UI を持つ機能の場合）
    • テンプレート（docs/templates/phase1/screen-flow.md）に従い画面情報を追記
    • 注: 画面遷移図は screen-flow.md に一元管理。docs/requirements/ には配置しない

フェーズ5: レビューと整合性チェック（親エージェント）

13. spec-writer が生成したドキュメントを本体が直接レビューする（Agent委任不可）
    • 要確認マーカーの確認と対応（必要ならユーザーに追加ヒアリング）
    • ヒアリング結果との整合性確認
    • テンプレート構造の再現確認
14. Agent(subagent_type: integrity-checker) を起動して機械的整合性チェック
    • 変更ファイルリスト・新規REQ-ID を prompt で渡す
    • チェック項目: .claude/skills/_shared/doc-integrity-check.md 参照
    • FAIL があれば修正 → 再チェック（最大3ループ）

フェーズ6: コミット（親エージェント）

15. 変更を git add してコミット

フェーズ7: 次ステップ提案

16. 次のステップを提案（以下の優先順）:
    • 基本設計が未作成の場合（推奨）: 「detail-design を実行して基本設計書（API仕様・DB設計・画面設計）を作成しますか？ 実装に必要な設計書が揃います」
    • 他の機能の要件も作る場合: 「他の機能の要件も作りますか？」
    • 基本設計が既にある場合: 「実装に進みますか？」

OVERVIEW Spec（サービス概要）ルール

OVERVIEW Specはシステム全体の共通仕様を一元管理するファイルである。

必須セクション

• サービス概要（このシステムが何であるか）
• 背景・目的
• ターゲットユーザー
• 技術スタック（フロントエンド、バックエンド、DB、インフラ、認証方式）
• 外部サービス依存（メール送信、決済、地図API、ファイルストレージ等）
• 非機能要件（パフォーマンス、可用性、スケーラビリティ、セキュリティ）
• 法的・コンプライアンス要件（該当する場合）
• 共通の制約事項・前提条件
• 受入条件（チェックリスト形式）

運用ルール

• OVERVIEW は常に最初に生成する。 個別機能の要件定義より先にOVERVIEW Specが存在していなければならない
• 個別Specには機能固有の要件のみ記載する。 技術スタック・非機能要件・セキュリティ・法的要件など、システム全体に共通する仕様はOVERVIEWに集約し、個別Specでは重複させない
• 個別Spec作成時にOVERVIEWも更新する。 個別機能の要件を検討した結果、新たな外部サービス依存・非機能要件等が判明した場合は、個別Specのコミットと同時にOVERVIEW Specにも追記する

ルール

• 受入条件、非機能要件、ID採番は全てAIが行う
• デザインがあれば画面構成を分析して受入条件に反映する
• ユーザーにフォーマットに沿った入力を求めない