| name | design-doc |
| description | Design Doc（設計ドキュメント）作成スキル。プロジェクトの設計書を構造化して作成する。「設計書を作りたい」「Design Docを書きたい」「アーキテクチャを文書化したい」などのリクエスト時に使用。要件定義、システム設計、API設計、データモデル、テスト戦略、リスク管理を網羅。 Use when this capability is needed. |
| metadata | {"author":"dio0550"} |
Design Doc 作成
プロジェクトの設計ドキュメントを構造化して作成するスキル。
⚠️ 重要: システム図は必須
このスキルで生成するDesign Docには必ずシステム図（状態マシン図 + データフロー図）を含めること。
システム図がないDesign Docは不完全であり、生成完了とみなさない。
ワークフロー
1. プロジェクト概要のヒアリング
↓
2. 要件・制約の確認
↓
3. テンプレートに沿ってDesign Doc生成
↓
4. ユーザー確認・修正
Step 1: ヒアリング
ユーザーの要求を受けたら、以下の観点で質問する。
必須項目
概要
- プロジェクト名
- 目的（2-3文で）
- 作成者・関係者
背景と課題
スコープ
技術的項目
要件
- 機能要件（優先度付き）
- 非機能要件（パフォーマンス、可用性、セキュリティ）
- 制約条件（技術、予算、スケジュール）
設計
- 使用技術スタック
- アーキテクチャ概要
- データモデル
- API設計（エンドポイント、メソッド）
Step 2: Design Doc 生成
ヒアリング結果を元に .specs/{project-name}/design-doc.md を生成。
テンプレート: assets/templates/design-doc-template.md
Step 2-1: 各セクションを執筆
- 概要（プロジェクト名、関係者、サマリー）
- 背景と目的（課題、目的、スコープ）
- 要件定義（機能要件、非機能要件、制約）
- システム設計（アーキテクチャ、状態マシン図、データフロー図、技術スタック、データモデル、API）
- 実装計画（フェーズ分け、タスク分解）
- テスト戦略（テスト計画、品質基準）
- リスク管理（リスク、影響度、対策）
- 運用・保守（デプロイ、モニタリング、保守計画）
- 成功指標（KPI）
Step 2-2: システム図を作成
状態マシン図とデータフロー図を必ず作成する。これにより：
- すべてのパス・分岐・エッジケースを可視化
- 実装の抜け漏れを防止
- システムレベルでの正しさを検証可能
ASCII図の例:
入力
│
▼
┌─────────────┐
│ STATE_A │─── 条件1 ───▶ STATE_B
└─────────────┘ │
│ │
条件2 条件3
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ STATE_C │ │ STATE_D │
└─────────────┘ └─────────────┘
図に含めるべき要素：
- 状態（State）: 各状態を明確に命名
- 遷移条件: 何がトリガーで状態が変わるか
- 分岐: すべての条件分岐を網羅
- エッジケース: エラー時・タイムアウト時の遷移
- ループ: 繰り返し処理がある場合
Step 2-3: 完了チェックリスト
Design Doc生成後、以下を確認すること：
チェックリストを満たさない場合、生成完了とみなさない。
Step 3: ユーザー確認
生成したDesign Docをユーザーに提示:
- 各セクションの概要サマリー
- 「修正が必要な場合はお知らせください」
出力
.specs/
└── {project-name}/
└── design-doc.md
{project-name} はケバブケースで命名。
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
