yodogawa 1.0.0

package/.windsurf/workflows/a-003-CreateScenarios.md

@@ -0,0 +1,130 @@
+---
+description: ユーザーストーリーから具体的なGherkinシナリオを作成し、BDD形式で振る舞いを定義するワークフロー
+---
+
+# CreateScenarios (a-003)
+
+## 目的
+
+- ユーザーストーリーから具体的なシナリオ（振る舞い）を抽出し、Gherkin形式で記述する。
+- Given-When-Then構造で、開発者・QA・ステークホルダーが共通理解できる実行可能なドキュメントを作成する。
+- ハッピーパス（正常系）からエラーケース、境界値テストまでを網羅的に定義する。
+
+## 前提
+
+- `docs/project/requirements/05-user-stories.md` が作成されていること（先に `InitializeProject` (a-002) を実行）。
+- `docs/project/behavior/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) を実行）。
+- ユーザーが各機能の具体的な動作例を説明できること。
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+- `docs/project/behavior/` ディレクトリの存在を確認：
+  ```bash
+  ls -la docs/project/behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
+  ```
+
+- ディレクトリが存在しない場合：
+  - ユーザーに通知：「`docs/project/behavior/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してください。」
+
+- ユーザーストーリーの確認：
+  - `docs/project/requirements/05-user-stories.md` を読み込み、内容を確認する。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/02-behavior/01-scenarios.md" "docs/project/behavior/01-scenarios.md"
+  ```
+
+### 3. 分析と提案
+
+- `docs/project/requirements/05-user-stories.md` を分析し、シナリオ作成対象の機能（Feature）をリストアップする。
+- 各機能について、考えられるシナリオ案（ハッピーパスと代表的なエラーケース）をユーザーに提案する：
+  - 「以下のユーザーストーリーに基づいて、シナリオを作成します：」
+  - 「機能: [機能名] (US-XXX)」
+    - 「シナリオ案1: [ハッピーパス]」
+    - 「シナリオ案2: [エラーケース]」
+
+### 4. ヒアリングと記入
+
+各機能について、以下の順序でヒアリングを行い、`docs/project/behavior/01-scenarios.md` を更新する。
+
+#### 4.1 Feature情報の定義
+- 機能名、説明、対応するユーザーストーリー（As a/I want/So that）を記入する。
+- **Background**（共通前提条件）がある場合は定義する。
+
+#### 4.2 シナリオの作成（ハッピーパス）
+- 「最も基本的な成功シナリオを教えてください。」
+- **Given**（前提）、**When**（アクション）、**Then**（結果）を確認し、Gherkin形式で記述する。
+- UI操作の詳細ではなく、ユーザーの意図を記述するよう注意する。
+
+#### 4.3 エラーケース・境界値の作成
+- 「エラーケースや境界値（エッジケース）はありますか？」
+- 必要に応じて **Scenario Outline**（パラメータ化）の使用を提案し、Examplesテーブルを作成する。
+
+#### 4.4 タグ付け
+- シナリオID（`@SC-XXX`）を採番する。
+- 適切なタグ（`@smoke`, `@happy-path`, `@error-handling` など）を付与する。
+
+### 5. シナリオ一覧テーブルの更新
+
+- ドキュメント冒頭の「シナリオ一覧」テーブルを更新し、作成した全シナリオのID、機能、シナリオ名、優先度を記載する。
+
+### 6. レビューと確認
+
+- 作成したシナリオをユーザーに提示し、以下を確認：
+  - 「シナリオは実際の動作を正しく表現していますか？」
+  - 「漏れているケースはありませんか？」
+  - 「非技術者でも理解できる表現になっていますか？」
+
+### 7. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # シナリオ一覧テーブルの確認
+     grep "| シナリオID | 機能 |" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Table Header"
+     # Feature定義の確認
+     grep "Feature:" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Feature definition"
+     # Scenario定義の確認
+     grep "Scenario:" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Scenario definition"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/behavior/01-scenarios.md` が作成されている
+     - [ ] シナリオ一覧テーブルが更新されている
+     - [ ] 各FeatureがGherkin形式で記述されている
+     - [ ] 正常系と異常系のシナリオが網羅されている
+
+### 8. Git への追加（オプション）
+
+- ユーザーに確認：「作成したシナリオドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/behavior/
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: 振る舞い仕様（シナリオ）の作成
+
+  - ユーザーストーリーに基づくGherkinシナリオを追加
+  - 正常系・異常系・境界値ケースを定義
+  ```
+
+## 完了条件
+
+- `docs/project/behavior/01-scenarios.md` が作成されている。
+- ユーザーストーリーに対応する具体的なシナリオ（Given-When-Then）が記述されている。
+- シナリオ一覧テーブルがメンテナンスされている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- ユーザーストーリーが不明確でシナリオ化できない場合：
+  - 「ユーザーストーリーの詳細化が必要です。`InitializeProject` ワークフローに戻って要件を明確にしましょう。」と提案する。
+- 実装詳細への依存が強すぎる場合：
+  - 「UI操作（ボタンクリック等）ではなく、ユーザーの意図（登録する等）に焦点を当てた記述に変更しましょう。」とリファクタリングを提案する。

package/.windsurf/workflows/a-004-DefineDomainModel.md

@@ -0,0 +1,133 @@
+---
+description: Event Storming形式でドメインモデルを定義し、ユビキタス言語を反復的に洗練させるワークフロー
+---
+
+# DefineDomainModel (a-004)
+
+## 目的
+
+- Event Storming形式でドメインモデルを体系的に定義する。
+- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
+- Bounded Context（境界づけられたコンテキスト）を特定し、各コンテキスト内のActors、Commands、Events、Policies、Aggregatesを明確化する。
+
+## 前提
+
+- `docs/project/behavior/01-scenarios.md` が作成されていること（先に `CreateScenarios` (a-003) を実行）。
+- `docs/project/domain/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) を実行）。
+- ドメインエキスパート（ビジネス側の専門家）と協力できること。
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+- `docs/project/domain/` ディレクトリの存在を確認：
+  ```bash
+  ls -la docs/project/domain/ 2>/dev/null || echo "ディレクトリが存在しません"
+  ```
+
+- ディレクトリが存在しない場合：
+  - ユーザーに通知：「`docs/project/domain/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してください。」
+
+- シナリオの確認：
+  - `docs/project/behavior/01-scenarios.md` を読み込み、内容を確認する。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/03-domain/01-domain-model.md" "docs/project/domain/01-domain-model.md"
+  cp ".windsurf/templates/project/03-domain/02-ubiquitous-language.md" "docs/project/domain/02-ubiquitous-language.md"
+  ```
+
+### 3. Bounded Context の特定
+
+- シナリオとユーザーストーリーを分析し、Bounded Context（ビジネス領域）を提案する。
+  - 「シナリオから、以下のBounded Contextが考えられます：[コンテキスト一覧]」
+- 各Contextの戦略的分類（Core/Supporting/Generic）を確認する。
+
+### 4. 各Bounded Context のドメインモデル定義
+
+各Bounded Contextについて、以下の要素をヒアリング・定義し、`01-domain-model.md` を更新する。
+**同時に、新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記する。**
+
+#### 4.1 概要とアクター
+- Contextの責務と主要な責任
+- 登場するアクター（Actors）とその役割
+
+#### 4.2 コマンドとイベント (Event Storming)
+- アクターが実行するアクション（**Commands**、命令形）
+- その結果発生するビジネス上の出来事（**Domain Events**、過去形）
+- 自動化ルール（**Policies**、"Whenever ..., then ..."）
+
+#### 4.3 集約とモデル
+- 一貫性を保つエンティティの塊（**Aggregates**）
+- 画面表示用の参照モデル（**Read Models**）
+- 連携する外部システム（**External Systems**）
+
+### 5. ユビキタス言語の洗練
+
+- `02-ubiquitous-language.md` を見直し、以下の点を確認・修正する：
+  - 用語の重複や曖昧さがないか
+  - 禁止用語（Data, Processなど曖昧な語）が含まれていないか
+  - 定義が具体的で、Context内での意味に限定されているか
+
+### 6. Context Map の定義
+
+- 各Context間の関係性（Customer-Supplier, Shared Kernelなど）を定義し、`01-domain-model.md` のContext Mapセクション（Mermaid図）を更新する。
+
+### 7. レビューと確認
+
+- 作成したドキュメントを提示し、以下を確認する：
+  - 「ビジネス用語は正確に表現されていますか？」
+  - 「Aggregateの境界は適切ですか？」
+  - 「ユビキタス言語の定義は明確ですか？」
+
+### 8. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # Bounded Context定義の確認
+     grep "Bounded Context:" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Bounded Context definition"
+     # Aggregate定義の確認
+     grep "### Aggregates" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Aggregates section"
+     # ユビキタス言語定義の確認
+     grep "| 用語 | 定義 |" docs/project/domain/02-ubiquitous-language.md && echo "OK" || echo "MISSING: Terminology table"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/domain/01-domain-model.md` が作成され、主要なEvent Storming要素が含まれている
+     - [ ] `docs/project/domain/02-ubiquitous-language.md` が作成され、用語が定義されている
+     - [ ] ドメインモデルとユビキタス言語の整合性が取れている
+
+### 9. Git への追加（オプション）
+
+- ユーザーに確認：「作成したドメインモデルドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/domain/
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: ドメインモデルとユビキタス言語の定義
+
+  - Event Stormingによるドメインモデルの作成
+  - Bounded Contextごとのユビキタス言語の整備
+  ```
+
+## 完了条件
+
+- `docs/project/domain/01-domain-model.md` が作成されている。
+- `docs/project/domain/02-ubiquitous-language.md` が作成されている。
+- 各Bounded Contextについて、主要なドメイン要素（Aggregates, Commands, Events）が定義されている。
+- ドメインモデルで使用される用語がユビキタス言語として定義されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- シナリオが不足していてドメインモデルを作成できない場合：
+  - 「シナリオ不足のためモデル化が困難です。`CreateScenarios` (a-003) に戻ってシナリオを充実させましょう。」と提案する。
+- Bounded Contextの境界が不明確な場合：
+  - 「境界が曖昧です。暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」と提案する。

package/.windsurf/workflows/a-005-CreateDomainDiagram.md

@@ -0,0 +1,114 @@
+---
+description: ドメインモデルをMermaid図で視覚化し、Context MapやAggregate構造を図示するワークフロー
+---
+
+# CreateDomainDiagram (a-005)
+
+## 目的
+
+- ドメインモデルドキュメント（`01-domain-model.md`）を基に、視覚的なダイアグラムを作成する。
+- Context Map（Bounded Context間の関係図）をMermaid形式で図示する。
+- 各Bounded Context内のAggregate構造や関係性を図示する（オプション）。
+
+## 前提
+
+- `docs/project/domain/01-domain-model.md` が作成されていること（先に `DefineDomainModel` (a-004) を実行）。
+- ドメインモデルドキュメントにBounded Contextの一覧と関係性が記述されていること。
+
+## 手順
+
+### 1. ドキュメントの確認
+
+- `docs/project/domain/01-domain-model.md` を読み込み、内容を確認する。
+  ```bash
+  ls -la docs/project/domain/01-domain-model.md 2>/dev/null || echo "ファイルが存在しません"
+  ```
+
+- ファイルが存在しない場合：
+  - ユーザーに通知：「ドメインモデルが見つかりません。先に `DefineDomainModel` (a-004) を実行してください。」
+
+### 2. Context Map の情報収集と提案
+
+- `docs/project/domain/01-domain-model.md` から以下の情報を抽出する：
+  - Bounded Contextのリスト
+  - 戦略的分類（Core / Supporting / Generic）
+  - Context間の関係性
+
+- 抽出した情報に基づき、Mermaid図の構成案を提示する：
+  - 「以下の関係を図示します：」
+  - 「Context A --> Context B (関係パターン)」
+
+### 3. Context Map 図の作成
+
+- `docs/project/domain/01-domain-model.md` の `## Context Map` セクションに Mermaid図を追加（または更新）する。
+- **スタイル定義**:
+  - Core Domain: 金色 (`fill:#FFD700`)
+  - Supporting Domain: 水色 (`fill:#87CEEB`)
+  - Generic Domain: グレー (`fill:#D3D3D3`)
+- **エッジ定義**:
+  - 関係パターンと通信方法をラベルに記載する。
+
+### 4. 詳細図の作成（オプション）
+
+- ユーザーに確認：「以下の詳細図も作成しますか？」
+  - **Aggregate構造図**: クラス図形式でAggregateの内部構造と関係性を表現。
+  - **イベントフロー図**: シーケンス図形式で主要なビジネスフロー（Command -> Event -> Policy）を表現。
+
+- 「はい」の場合、対象のBounded Contextやシナリオを確認し、図を作成してドキュメント内の適切な箇所に追加する。
+
+### 5. レビューと確認
+
+- 作成した図をユーザーに提示し、以下を確認：
+  - 「関係性は正しく表現されていますか？」
+  - 「分類の色分けは適切ですか？」
+  - 「複雑すぎて読みにくい箇所はありませんか？」
+
+- フィードバックに基づき、レイアウト（TD/LR）や配置を調整する。
+
+### 6. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # Mermaidブロックの存在確認
+     grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Mermaid diagram"
+     # Context Mapセクションの確認
+     grep "## Context Map" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Context Map section"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/domain/01-domain-model.md` にContext Map図が含まれている
+     - [ ] Mermaid図が正しくレンダリングされる（構文エラーがない）
+     - [ ] 戦略的分類に応じて色分けされている
+
+### 7. Git への追加（オプション）
+
+- ユーザーに確認：「更新したドメインモデルドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/domain/01-domain-model.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: ドメインモデル図（Context Map）の追加
+
+  - Bounded Context間の関係をMermaid図で視覚化
+  - 戦略的分類に基づく色分けを追加
+  ```
+
+## 完了条件
+
+- `docs/project/domain/01-domain-model.md` にContext Map図が追加されている。
+- Bounded Context間の関係性が正しく表現されている。
+- 戦略的分類が視覚的に区別されている。
+- オプションの詳細図（Aggregate図、シーケンス図）が必要に応じて追加されている。
+- ユーザーが図の内容を承認している。
+
+## エスカレーション
+
+- ドメインモデルが不完全で図を作成できない場合：
+  - 「必要な情報（関係性など）が不足しています。`DefineDomainModel` (a-004) に戻って定義を補完しましょう。」と提案する。
+- 図が複雑すぎて読みにくい場合：
+  - 「関係が複雑すぎます。主要な関係のみに絞るか、図を分割することを検討しましょう。」と提案する。

package/.windsurf/workflows/a-006-ReviewRequirementsDomain.md

@@ -0,0 +1,132 @@
+---
+description: 要件定義からドメインモデルまでのドキュメント間の一貫性をチェックし、不整合や漏れを検出するレビューワークフロー
+auto_execution_mode: 1
+---
+
+# ReviewRequirementsDomain (a-006)
+
+## 目的
+
+- ここまでに作成されたすべてのドキュメント間の一貫性を体系的にチェックする。
+- ドキュメント間の不整合、漏れ、矛盾を検出し、修正提案を提供する。
+- ユビキタス言語の遵守状況を確認し、用語の一貫性を保証する。
+- レビュー結果レポートを作成し、修正すべき項目を優先度付きでリストアップする。
+
+## 前提
+
+- 以下のドキュメントが作成されていること：
+  - `docs/project/requirements/01-system-overview.md`
+  - `docs/project/requirements/02-features-implemented.md`
+  - `docs/project/requirements/03-features-planned.md`
+  - `docs/project/requirements/04-non-functional-requirements.md`
+  - `docs/project/requirements/05-user-stories.md`
+  - `docs/project/behavior/01-scenarios.md`
+  - `docs/project/domain/01-domain-model.md`
+  - `docs/project/domain/02-ubiquitous-language.md`
+
+## 手順
+
+### 1. ドキュメント存在確認
+
+- 必要なすべてのドキュメントが存在するか確認する：
+  ```bash
+  ls -l docs/project/requirements/*.md docs/project/behavior/*.md docs/project/domain/*.md
+  ```
+- 不足しているドキュメントがある場合、対応するワークフロー（a-002, a-003, a-004）の実行を促す。
+
+### 2. 一貫性チェックの実行
+
+以下の項目について、自動検索（grep等）と手動確認を組み合わせて検証する。
+
+#### 2.1 ユーザーストーリー ↔ シナリオ
+- **カバレッジ**: すべてのユーザーストーリー（US-XXX）に対応するシナリオ（SC-XXX）が存在するか。
+- **整合性**: ストーリーの「価値」とシナリオの「結果」が一致しているか。
+
+#### 2.2 実装済み機能・予定機能 ↔ シナリオ
+- **実装済み機能**: `02-features-implemented.md` に記載の機能に、リグレッションテスト用のシナリオが存在するか。
+- **予定機能**: `03-features-planned.md` の優先度High機能にシナリオが存在するか。
+
+#### 2.3 非機能要件 ↔ ドメインモデル
+- **パフォーマンス**: `04-non-functional-requirements.md` の要件（読み込み速度など）に対し、Read ModelやCQRSが検討されているか。
+- **セキュリティ**: 認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
+
+#### 2.4 シナリオ ↔ ドメインモデル
+- **Command**: シナリオのWhen（アクション）がドメインモデルのCommandとして定義されているか。
+- **Event**: シナリオのThen（結果）がドメインモデルのDomain Eventとして定義されているか。
+- **Actor**: シナリオのActorがドメインモデルに存在するか。
+
+#### 2.5 ユビキタス言語の遵守
+- **用語定義**: ドメインモデルの主要要素（Aggregate, Command, Event）がユビキタス言語一覧にあるか。
+- **禁止用語**: 各ドキュメントに禁止用語（Data, Process等）が使われていないか。
+  ```bash
+  # 禁止用語の簡易検索（例）
+  grep -r "Data" docs/project/domain/ || echo "No 'Data' found"
+  grep -r "Process" docs/project/domain/ || echo "No 'Process' found"
+  ```
+
+#### 2.6 目的との整合性
+- システム概要の「目的」と、ドメインモデルの「Core Domain」が一致しているか。
+
+### 3. レビュー結果レポートの作成
+
+- 検出された問題（Error/Warning）をまとめ、`docs/project/REVIEW-REPORT.md` を作成する。
+
+**レポートフォーマット例**:
+```markdown
+# ドキュメント一貫性レビュー結果
+**実施日**: YYYY-MM-DD
+
+## サマリー
+- ✅ OK: X項目
+- ⚠️ Warning: X項目
+- ❌ Error: X項目
+
+## 詳細
+
+### 1. ユーザーストーリー ↔ シナリオ
+- ❌ **Error**: US-005 に対応するシナリオが見つかりません。
+- ✅ OK: 優先度Highのストーリーはすべてカバーされています。
+
+### 2. 機能要件・非機能要件
+- ⚠️ **Warning**: 実装済み機能「決済」のシナリオが不足しています。
+- ✅ OK: パフォーマンス要件に対応するRead Modelが定義されています。
+
+### 3. シナリオ ↔ ドメインモデル
+- ⚠️ **Warning**: シナリオSC-003のCommand「在庫を引き当てる」がドメインモデルに未定義です。
+
+### 4. ユビキタス言語
+- ❌ **Error**: 用語「ShippingAddress」がユビキタス言語一覧にありません。
+- ⚠️ **Warning**: 禁止用語「User Data」が `01-domain-model.md` で使用されています。
+
+## 推奨アクション
+1. `CreateScenarios` (a-003) で US-005 のシナリオを追加する。
+2. `DefineDomainModel` (a-004) で「在庫を引き当てる」コマンドを定義する。
+3. `01-domain-model.md` の「User Data」を「User Profile」に修正する。
+```
+
+### 4. 結果の報告と修正提案
+
+- ユーザーにレポートの内容を要約して伝える。
+- 重大なエラー（❌）がある場合は、優先的に修正することを提案する。
+- 「修正作業を開始しますか？それともレポートをGitに保存して終了しますか？」
+
+### 5. Git への追加（オプション）
+
+- ユーザーが希望する場合、レポートをコミットする。
+  ```bash
+  git add docs/project/REVIEW-REPORT--YYYYMMDDHHMMSS.md
+  git commit -m "docs: 要件・ドメイン整合性レビューレポートの作成"
+  ```
+
+## 完了条件
+
+- `docs/project/REVIEW-REPORT.md` が作成されている。
+- 全ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
+- 具体的な修正アクションが提案されている。
+
+## エスカレーション
+
+- 多数のエラーが検出された場合：
+  - 「不整合が多いため、ドキュメントの信頼性が低くなっています。関係者を集めて大規模なレビュー会議を行うことを推奨します。」
+- 重要機能（Core Domain）で不整合がある場合：
+  - 「Core Domainにおける不整合はリスクが高いです。実装前に必ず解消してください。」

package/.windsurf/workflows/a-007-DefineTechStack.md

@@ -0,0 +1,121 @@
+---
+description: 要件を分析して推奨技術スタックを提案し、ユーザーとの詳細なインタビューを通じて最適な技術選定を行うワークフロー
+---
+
+# DefineTechStack (a-007)
+
+## 目的
+
+- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
+- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
+- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
+
+## 前提
+
+- `docs/project/requirements/` 配下のドキュメントが作成されていること。
+- `docs/project/domain/` 配下のドキュメントが作成されていること。
+- `docs/project/design/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) を実行）。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+- `docs/project/design/` ディレクトリの存在を確認
+  ```bash
+  ls -la docs/project/design/ 2>/dev/null || echo "ディレクトリが存在しません"
+  ```
+- 存在しない場合：ユーザーに通知し、`SetupDocStructure` (a-001) を実行するよう促す。
+
+- 必要な要件ドキュメントを読み込む：
+  - `docs/project/requirements/01-system-overview.md`
+  - `docs/project/requirements/03-features-planned.md`
+  - `docs/project/requirements/04-non-functional-requirements.md`
+  - `docs/project/domain/01-domain-model.md`
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/04-design/01-tech-stack.md" "docs/project/design/01-tech-stack.md"
+  ```
+
+### 3. 要件分析と推奨技術スタックの生成
+
+- **システム特性の分析**: アプリケーションタイプ（SPA/SSR等）、非機能要件（パフォーマンス/セキュリティ）、ドメイン複雑度を分析する。
+- **推奨案の作成**: 以下のレイヤーごとに推奨技術を選定する。
+  1. フロントエンド
+  2. バックエンド
+  3. データベース
+  4. インフラ・CI/CD
+  5. 監視・テスト
+
+- **推奨案の提示**:
+  - 「要件分析の結果、以下の技術スタックを推奨します：」
+  - 各技術について「推奨理由」と「代替案」を提示する。
+
+### 4. 詳細インタビューと選定
+
+ユーザーからのフィードバックを受け、各レイヤーについて詳細を確認する。
+
+- **フロントエンド**: フレームワーク（React/Vue等）、TypeScript利用、状態管理、スタイリング。
+- **バックエンド**: 言語、フレームワーク、APIスタイル（REST/GraphQL）。
+- **データベース**: RDBMS/NoSQL、ORM、マイグレーション戦略。
+- **インフラ**: クラウド/PaaS、コンテナ化（Docker）、IaC。
+- **開発ツール**: リンター/フォーマッター、テストツール、CI/CD。
+
+### 5. ドキュメント作成
+
+- ヒアリング結果を `docs/project/design/01-tech-stack.md` に記入する。
+- **必須項目**:
+  - 技術名、バージョン
+  - 選定理由（要件とのマッピング）
+  - 選定タイミング（初期/中期/後期）
+
+### 6. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # フロントエンドセクションの確認
+     grep "### フロントエンド" docs/project/design/01-tech-stack.md && echo "OK" || echo "MISSING: Frontend section"
+     # バックエンドセクションの確認
+     grep "### バックエンド" docs/project/design/01-tech-stack.md && echo "OK" || echo "MISSING: Backend section"
+     # 技術選定理由の確認（メモ欄など）
+     grep "|" docs/project/design/01-tech-stack.md | head -n 5
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/design/01-tech-stack.md` が作成されている
+     - [ ] 主要なレイヤー（FE, BE, DB, Infra）の技術が選定されている
+     - [ ] 選定理由が明確に記載されている
+
+### 7. Git への追加（オプション）
+
+- ユーザーに確認：「作成した技術スタックドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/design/01-tech-stack.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: 技術スタック選定ドキュメントの作成
+
+  - フロントエンド、バックエンド、インフラ等の技術選定を定義
+  - 選定理由と導入フェーズを明記
+  ```
+
+## 完了条件
+
+- `docs/project/design/01-tech-stack.md` が作成されている。
+- すべてのレイヤーについて技術選定が完了している（または「保留」として記録されている）。
+- 選定理由とバージョンが明確になっている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- ユーザーが決められない場合：
+  - 「要件に基づき、最も標準的でリスクの少ない[技術名]を仮採用とし、実装フェーズで再評価しませんか？」と提案する。
+- コストや学習コストの懸念がある場合：
+  - 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑な要件が出てきた段階で移行を検討しましょう。」と提案する。