| name | draft-spec |
| description | 新機能の要件定義。自然言語の入力から質問→要件定義書を自動生成する。
「通知機能を作りたい」「こういう機能がほしい」「○○ができるようにして」
「新しく○○を追加したい」「○○機能の要件を作って」などのリクエストで使用する。
まだコードが存在しない新機能を定義するときに使う。既存コードのSpec化にはspec-featureを使う。
|
| context | {"required":["_shared/spec-writing-standard.md","_shared/spec-unified-base.md","_shared/screen-transition-diagram.md"]} |
新機能の要件定義
統一基盤の確認
Spec 統一基盤確認 を実施する。
入力の受け取り方（優先順）
- ユーザーが会話で伝えた内容（「通知機能がほしい」等）
- docs/drafts/ にファイルがあればそれも参照
- デザインファイル（スクショや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: ヒアリング（親エージェント）
- ユーザーの入力を分析し、要件のドラフトをまとめる
- 不足情報を質問する（最大8問、Yes/Noで答えやすい形式）
- 担当者も確認する。ユーザーが指定しなければ「未定」とする
- システム全体の共通仕様（技術スタック、非機能要件、外部サービス依存、法的要件等）も確認する
- 質問カテゴリチェックリスト（該当するもののみ質問に含める）：
- バリデーション（文字数上限、入力フォーマット、許容値の範囲）
- エラー・異常系（重複登録、上限超過、期限切れ時の振る舞い）
- 権限・アクセス制御（ロール別の操作可否、データの可視範囲）
- 状態遷移（ステータスの遷移制約、無効な遷移の扱い）
- 同時操作（先勝ち/後勝ち/排他制御の方針）
- データ削除（論理削除/物理削除、関連データの連鎖削除）
- OVERVIEW Specの確認・作成判定: docs/requirements/features/ にOVERVIEW（サービス概要）Specが存在するか確認する
- 存在しない場合: 個別機能の要件定義の前に、まずOVERVIEW Specを作成する（後述「OVERVIEW Specルール」参照）
- 存在する場合: 内容を読み、今回の要件で追記すべき共通仕様があればOVERVIEW Specも同時に更新する
- 共通コンポーネントの確認:
docs/design/shared-components.md が存在する場合、既存の共通コンポーネントを確認する
- 今回の要件で再利用できそうな共通コンポーネント（UI部品、ユーティリティ、フック等）を洗い出す
- 関連機能の発見: 今回の要件に関連する既存機能を特定する
overview.md の機能一覧と依存関係セクションを読み、関連する既存Specを特定する
フェーズ2: 執筆プラン整理（親エージェント）
- 以下を整理し、spec-writer へ渡す委任プロンプトを組み立てる:
- REQ-ID採番（OVERVIEWの場合は
REQ-OVERVIEW-001）
- 担当者・ステータス・受入条件
- 生成対象ドキュメントの要否判定:
- 要件定義書: 常に必須（
docs/requirements/features/[REQ-ID].md）
- 業務フロー図: 既存業務プロセスの変更を伴う、または複雑な業務フローがある場合
- ユースケース: 複数アクターが異なる操作を行う場合
- 画面一覧: UIを持つ機能の場合（常に更新）
- 非機能要件定義書: OVERVIEW Specの初回作成時、または大幅な非機能要件追加時
- 関連Spec、共通コンポーネントの活用可能性
フェーズ3: 執筆委任（spec-writer、並列可）
-
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 系に触らないため、親が責任を持って更新する:
docs/requirements/overview.md を更新
- 機能一覧テーブルに REQ-ID・担当を追加
- 依存関係セクションに今回の機能の依存先・依存元を追記
spec-map.yml に新規REQ-IDのエントリを追加し、depends_on に依存先を記載docs/design/dependency-graph.md が存在する場合、新規Specの依存関係を追記（Mermaid図 + 依存マトリクス）mkdocs.yml の nav を更新docs/design/screen-flow.md を更新（UI を持つ機能の場合）
- テンプレート（
docs/templates/phase1/screen-flow.md）に従い画面情報を追記
- 注: 画面遷移図は screen-flow.md に一元管理。docs/requirements/ には配置しない
フェーズ5: レビューと整合性チェック（親エージェント）
- spec-writer が生成したドキュメントを本体が直接レビューする（Agent委任不可）
- 要確認マーカーの確認と対応（必要ならユーザーに追加ヒアリング）
- ヒアリング結果との整合性確認
- テンプレート構造の再現確認
Agent(subagent_type: integrity-checker) を起動して機械的整合性チェック
- 変更ファイルリスト・新規REQ-ID を prompt で渡す
- チェック項目:
.claude/skills/_shared/doc-integrity-check.md 参照
- FAIL があれば修正 → 再チェック（最大3ループ）
フェーズ6: コミット（親エージェント）
- 変更を
git add してコミット
フェーズ7: 次ステップ提案
- 次のステップを提案（以下の優先順）:
- 基本設計が未作成の場合（推奨）: 「detail-design を実行して基本設計書（API仕様・DB設計・画面設計）を作成しますか？ 実装に必要な設計書が揃います」
- 他の機能の要件も作る場合: 「他の機能の要件も作りますか？」
- 基本設計が既にある場合: 「実装に進みますか？」
OVERVIEW Spec（サービス概要）ルール
OVERVIEW Specはシステム全体の共通仕様を一元管理するファイルである。
必須セクション
- サービス概要（このシステムが何であるか）
- 背景・目的
- ターゲットユーザー
- 技術スタック（フロントエンド、バックエンド、DB、インフラ、認証方式）
- 外部サービス依存（メール送信、決済、地図API、ファイルストレージ等）
- 非機能要件（パフォーマンス、可用性、スケーラビリティ、セキュリティ）
- 法的・コンプライアンス要件（該当する場合）
- 共通の制約事項・前提条件
- 受入条件（チェックリスト形式）
運用ルール
- OVERVIEW は常に最初に生成する。 個別機能の要件定義より先にOVERVIEW Specが存在していなければならない
- 個別Specには機能固有の要件のみ記載する。 技術スタック・非機能要件・セキュリティ・法的要件など、システム全体に共通する仕様はOVERVIEWに集約し、個別Specでは重複させない
- 個別Spec作成時にOVERVIEWも更新する。 個別機能の要件を検討した結果、新たな外部サービス依存・非機能要件等が判明した場合は、個別Specのコミットと同時にOVERVIEW Specにも追記する
ルール
- 受入条件、非機能要件、ID採番は全てAIが行う
- デザインがあれば画面構成を分析して受入条件に反映する
- ユーザーにフォーマットに沿った入力を求めない
