---

name: design-doc description: Design Doc（設計ドキュメント）作成スキル。プロジェクトの設計書を構造化して作成する。「設計書を作りたい」「Design Docを書きたい」「アーキテクチャを文書化したい」などのリクエスト時に使用。要件定義、システム設計、API設計、データモデル、テスト戦略、リスク管理を網羅。

Design Doc 作成

プロジェクトの設計ドキュメントを構造化して作成するスキル。

⚠️ 重要: システム図は必須

このスキルで生成するDesign Docには必ずシステム図（状態マシン図 + データフロー図）を含めること。 システム図がないDesign Docは不完全であり、生成完了とみなさない。

ワークフロー

Copy1. プロジェクト概要のヒアリング
   ↓
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: 各セクションを執筆

1. 概要（プロジェクト名、関係者、サマリー）
2. 背景と目的（課題、目的、スコープ）
3. 要件定義（機能要件、非機能要件、制約）
4. システム設計（アーキテクチャ、状態マシン図、データフロー図、技術スタック、データモデル、API）
5. 実装計画（フェーズ分け、タスク分解）
6. テスト戦略（テスト計画、品質基準）
7. リスク管理（リスク、影響度、対策）
8. 運用・保守（デプロイ、モニタリング、保守計画）
9. 成功指標（KPI）

Step 2-2: システム図を作成

状態マシン図とデータフロー図を必ず作成する。これにより：

• すべてのパス・分岐・エッジケースを可視化
• 実装の抜け漏れを防止
• システムレベルでの正しさを検証可能

CopyASCII図の例:

    入力
      │
      ▼
┌─────────────┐
│  STATE_A    │─── 条件1 ───▶ STATE_B
└─────────────┘                  │
      │                          │
   条件2                      条件3
      │                          │
      ▼                          ▼
┌─────────────┐           ┌─────────────┐
│  STATE_C    │           │  STATE_D    │
└─────────────┘           └─────────────┘

図に含めるべき要素：

• 状態（State）: 各状態を明確に命名
• 遷移条件: 何がトリガーで状態が変わるか
• 分岐: すべての条件分岐を網羅
• エッジケース: エラー時・タイムアウト時の遷移
• ループ: 繰り返し処理がある場合

Step 2-3: 完了チェックリスト

Design Doc生成後、以下を確認すること：

• 状態マシン図が含まれているか
• データフロー図が含まれているか
• 図にすべての状態・遷移条件・エッジケースが含まれているか
• 図と各セクションの内容が整合しているか

チェックリストを満たさない場合、生成完了とみなさない。

Step 3: ユーザー確認

生成したDesign Docをユーザーに提示:

1. 各セクションの概要サマリー
2. 「修正が必要な場合はお知らせください」

出力

Copy.specs/
└── {project-name}/
    └── design-doc.md

{project-name} はケバブケースで命名。