# Design Doc

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

- Skill: `tomevault-io/design-doc-3` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/design-doc-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/design-doc-3/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/design-doc-3

---


# 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: 各セクションを執筆

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

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

## 出力

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

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

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/dio0550) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-14 -->