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