/kairo-design

description: 承認された要件定義書に基づいて、技術設計文書を生成する。データフロー図、TypeScriptインターフェース、データベーススキーマ、APIエンドポイントを含む包括的な設計を行います。
allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite, WebFetch, AskUserQuestion
argument-hint: "[要件名]"

Kairo開発の技術設計を実施し、PRD・EARS要件定義書・既存設計文書を参照しながら技術仕様を明確化します。信頼性レベルを示しながら設計文書を作成します。

context

出力ディレクトリ="docs/design" 要件名={{requirement_name}} 作業規模={{work_scope}} 信頼性評価=[]

step

• $ARGUMENTS がない場合、「引数に要件名を指定してください（例: ユーザー認証システム）」と言って終了する
• $ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
• step2 を実行する

step2: 作業規模の確認

• AskUserQuestion ツールを使って作業規模を質問する：
• question: "この設計の作業規模について教えてください"
• header: "設計規模"
• multiSelect: false
• options:
• label: "フル設計（推奨）"

description: "包括的なアーキテクチャ設計、詳細なデータフロー、完全な型定義、DBスキーマ、API仕様を含む"

• label: "軽量設計"

description: "必要最小限の設計、基本的なアーキテクチャとデータフロー、主要な型定義のみ"

• label: "カスタム"

description: "含めたい設計項目を個別に選択"

• ユーザーの選択を context の {{work_scope}} に保存

• カスタムを選択した場合は、AskUserQuestion ツールを使って以下を質問：
• question: "設計文書に含める項目を選択してください（複数選択可）"
• header: "含める項目"
• multiSelect: true
• options:
• label: "詳細なデータフロー図"

description: "包括的なデータフロー図とシーケンス図を作成"

• label: "TypeScript型定義"

description: "詳細な型定義ファイルを作成"

• label: "データベーススキーマ"

description: "データベース設計とスキーマ定義"

• label: "API仕様"

description: "APIエンドポイントとリクエスト/レスポンス定義"

• step3 を実行する

step3: 開発コンテキストの準備

• **タスクノートの読み込み**
• `docs/spec/{要件名}/note.md` が存在する場合は読み込み
• 存在しない場合:
• Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki-legacy:kairo-tasknote {要件名}` コマンドを実行してノートを生成
• 生成されたノートファイルを読み込み
• ノートには技術スタック、開発ルール、関連実装、設計文書、注意事項が含まれる

• **要件定義書の読み込み**
• `./docs/spec/{要件名}-requirements.md` を読み込み
• `./docs/spec/{要件名}/requirements.md` を読み込み
• `./docs/spec/{要件名}-user-stories.md` が存在する場合は読み込み
• `./docs/spec/{要件名}/user-stories.md` が存在する場合は読み込み
• `./docs/spec/{要件名}-acceptance-criteria.md` が存在する場合は読み込み
• `./docs/spec/{要件名}/acceptance-criteria.md` が存在する場合は読み込み
• EARS要件定義から機能要件と非機能要件を抽出

• **追加ルールの読み込み**
• `docs/rule` ディレクトリが存在する場合は読み込み
• `docs/rule/kairo` ディレクトリが存在する場合は読み込み
• `docs/rule/kairo/design` ディレクトリが存在する場合は読み込み
• 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用

• **技術スタック定義の読み込み**
• `docs/tech-stack.md` が存在する場合は読み込み
• 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み
• どちらも存在しない場合は note.md の技術スタック情報を使用

• **既存設計文書の調査**
• `docs/design/` ディレクトリ配下の既存設計文書を確認
• 既存のアーキテクチャ設計・データフロー図を読み込み
• 既存のTypeScript型定義・DBスキーマ・API仕様を読み込み
• Task tool (subagent_type: Explore, thoroughness: quick) を使用して関連設計文書を探索

• **既存コードベース・実装の分析**（オプション）
• AskUserQuestion ツールを使ってユーザーに確認:
• question: "既存実装の詳細分析が必要ですか？"
• header: "コード分析"
• multiSelect: false
• options:
• label: "必要"

description: "既存実装の網羅的調査、アーキテクチャパターンの確認、技術的制約の特定"

• label: "不要"

description: "要件定義と設計文書のみで設計を作成"

• 「必要」を選択した場合のみ:
• Task tool (subagent_type: Explore, thoroughness: medium) を使用して既存実装の網羅的調査
• アーキテクチャパターン・実装パターンの確認
• 技術的制約・依存関係の特定
• 既存型定義・インターフェースの確認

• **収集情報のサマリー作成**
• 既存プロジェクトのアーキテクチャ全体像整理
• 定義済み設計・未定義部分の特定
• 技術制約・非機能要件の整理
• ギャップ分析（要件 vs 既存設計 vs 実装）

• 読み込み完了後、step4 を実行する

step4: 既存情報ベースの差分ヒアリング

作業規模に応じてヒアリング項目を調整。 **重要**: 以下の質問は例示であり、実際のプロジェクト状況に応じて AskUserQuestion ツールを使用して適切な質問を作成すること。

フル設計の場合

以下のカテゴリごとに、既存情報（要件定義、設計文書、実装）から特定した具体的な課題・不明点について AskUserQuestion ツールで質問する：

**既存アーキテクチャの妥当性確認**

• 既存のアーキテクチャパターンが要件に適合するか確認が必要な場合、その内容について質問
• 技術スタック選択について確認が必要な場合、その理由とともに質問
• 既存設計で実現困難・非効率な部分を発見した場合、代替案とともに質問

例: AskUserQuestion ツールで以下のように質問

• question: "現在のアーキテクチャは{具体的なパターン}ですが、{新要件}には{別のパターン}の方が適している可能性があります。変更を検討しますか？"
• header: "アーキテクチャ"
• multiSelect: false
• options:
• label: "現行維持"

description: "現在のアーキテクチャを維持"

• label: "変更検討"

description: "新しいアーキテクチャパターンを検討（その他で詳細を記入）"

**未定義設計の詳細化ヒアリング**

• データモデルの詳細について質問
• 状態管理方法について質問
• 認証・認可方式について質問
• エラーハンドリング戦略について質問

**技術選択の確認**

• 使用するライブラリ・フレームワークの選択について質問
• データベース種別・ORMの選択について質問
• キャッシュ戦略について質問
• 外部サービス連携方法について質問

**パフォーマンス・スケーラビリティ要件**

• パフォーマンス要件の具体的な数値について質問
• スケーラビリティの要件について質問
• データ量・トラフィック予測について質問

**セキュリティ・コンプライアンス要件**

• セキュリティ要件の詳細について質問
• データ保護要件について質問
• コンプライアンス要件について質問

**優先順位・フェーズ分け** 複数の設計要素がある場合、AskUserQuestion ツールで優先順位を質問:

• question: "以下の設計要素の優先順位を教えてください（複数選択可）"
• header: "優先順位"
• multiSelect: true
• options: （実際の設計要素リストから動的に生成）

軽量設計の場合

**必須項目のみ確認** AskUserQuestion ツールを使って、以下の項目について簡潔に質問:

• 基本的なアーキテクチャ方針の確認
• 主要な技術選択の確認（3-5項目程度）
• 最低限のデータモデル確認
• 優先順位（Phase 1 のみ）

カスタム設計の場合

step2 で選択した項目に関連するヒアリングのみ実施。 AskUserQuestion ツールを使って、選択された項目に応じた質問を作成する。

**注意事項**:

• すべての質問を一度に投げるのではなく、文脈に応じて段階的に質問する
• ユーザーの回答を受けて、必要に応じて追加質問を行う
• 質問は具体的で、はい/いいえで答えられるか、選択肢から選べる形式にする
• 自由記述が必要な場合は「その他」オプションを用意する

**ヒアリング記録の作成**:

• すべての質問と回答を記録する
• 各質問について、以下を記録：
• 質問内容
• 質問日時
• カテゴリ（アーキテクチャ/データモデル/技術選択/パフォーマンス/セキュリティ）
• 質問の背景（なぜこの質問が必要だったか）
• ユーザーからの回答
• 信頼性への影響（この回答により信頼性レベルがどう変化したか）
• ヒアリング結果のサマリーを作成：
• 確認できた事項
• 設計方針の決定事項
• 残課題
• 信頼性レベル分布（ヒアリング前後の比較）
• この記録は後で `{要件名}-design-interview.md` として出力する

• step5 を実行する

step5: 統合設計文書作成

• 作業規模に応じた設計テンプレートを選択：
• フル設計: 全ファイルを作成
• 軽量設計: architecture.md と dataflow.md のみ作成
• カスタム: 選択項目に応じた組み合わせ

• context の情報でテンプレートを埋めて、以下のファイルを直接作成する
• 読み込んだコンテキスト情報（タスクノート、追加ルール、要件定義等）を活用
• **重要**: すべてのファイルのすべての項目に信頼性レベル（🔵🟡🔴）を記載
• Write ツールを使用して出力ファイルに保存

• **出力ファイル**:

1. `docs/design/{要件名}/architecture.md`: アーキテクチャ概要

• <architecture_template> を使用
• 各設計決定に信頼性レベル（🔵🟡🔴）と出典を記載

2. `docs/design/{要件名}/dataflow.md`: データフロー図

• <dataflow_template> を使用
• 各フローに信頼性レベル（🔵🟡🔴）と出典を記載

3. `docs/design/{要件名}/design-interview.md`: ヒアリング記録

• <design_interview_template> を使用
• step4の質問と回答を記録
• 信頼性レベルの変化を記録

4. フル設計の場合:

• `docs/design/{要件名}/interfaces.ts` または対応する型定義ファイル: 型定義
• <interfaces_template> を使用
• **重要**: 対象言語がTypeScriptでない場合はそれに合わせたファイル形式に変更
• **重要**: インターフェース定義が不要なら生成しない
• 既存のnote.mdやtech-stack.mdの型定義パターンに合わせる
• 既存の設計文書に型定義がある場合はそれを参照して追加
• 各型定義に信頼性レベル（🔵🟡🔴）と出典をコメントで記載

• `docs/design/