yodogawa 1.0.3 → 1.0.4

package/.windsurf/scripts/setup-docs.sh

@@ -1,92 +1,92 @@
-#!/bin/bash
-
-# setup-docs.sh
-# プロジェクトのドキュメントディレクトリ構造を作成するスクリプト
-
-set -e
-
-DOCS_DIR="docs"
-
-echo "📂 ドキュメント構造のセットアップを開始します..."
-
-# 1. 現在の状態確認
-if [ -d "$DOCS_DIR" ]; then
-  echo "⚠️  '$DOCS_DIR' ディレクトリは既に存在します。"
-  read -p "既存の構造を保持したまま、不足しているディレクトリを追加しますか？ (y/N): " confirm
-  if [[ ! "$confirm" =~ ^[Yy]$ ]]; then
-    echo "❌ 中断しました。"
-    exit 0
-  fi
-fi
-
-# 2. ディレクトリ構造の作成
-echo "🔨 ディレクトリを作成中..."
-mkdir -p "$DOCS_DIR/project/01-requirements"
-mkdir -p "$DOCS_DIR/project/02-behavior"
-mkdir -p "$DOCS_DIR/project/03-domain"
-mkdir -p "$DOCS_DIR/project/04-design"
-mkdir -p "$DOCS_DIR/tasks"
-
-# 3. docs/README.md の作成
-README_FILE="$DOCS_DIR/README.md"
-if [ -f "$README_FILE" ]; then
-  echo "⚠️  '$README_FILE' は既に存在します。"
-  read -p "上書きしますか？ (y/N): " confirm_readme
-  if [[ ! "$confirm_readme" =~ ^[Yy]$ ]]; then
-    echo "ℹ️  READMEの作成をスキップしました。"
-  else
-    CREATE_README=true
-  fi
-else
-  CREATE_README=true
-fi
-
-if [ "$CREATE_README" = true ]; then
-  echo "📝 README.md を作成中..."
-  cat > "$README_FILE" <<EOF
-# プロジェクトドキュメント
-
-このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
-
-## 構成
-
-### project/
-プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
-
-- **01-requirements/**: 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリーなど）
-- **02-behavior/**: 振る舞い定義（シナリオ、ユースケース、ユーザージャーニーなど）
-- **03-domain/**: ドメインモデル（エンティティ、用語集など）
-- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
-
-### tasks/
-個別タスクのドキュメント。Issue やチケット単位で作成します。
-
-## 更新方針
-
-### プロジェクト全体のドキュメント (project/)
-- プロジェクトのスコープ全体に影響する情報を記載
-- チーム全体で共有すべき要件・設計・アーキテクチャを管理
-- 更新時は関係者にレビューを依頼
-
-### 個別タスクのドキュメント (tasks/)
-- 特定の Issue やチケットに紐づく情報を記載
-- タスク単位で作成・完了・アーカイブ
-- 完了後は参照資料として保持、または削除
-
-## ドキュメント作成ガイドライン
-
-- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
-- **測定可能**: 成功基準やパフォーマンス目標を定量化
-- **最新**: 変更があれば速やかに更新し、古い情報を残さない
-- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
-EOF
-fi
-
-# 4. 完了報告
-echo ""
-echo "✅ ドキュメントディレクトリ構造のセットアップが完了しました！"
-echo ""
-find "$DOCS_DIR" -maxdepth 2 | sort
-echo ""
-echo "次のステップ:"
-echo "  - 必要に応じて 'git add $DOCS_DIR' を実行してください。"
+#!/bin/bash
+
+# setup-docs.sh
+# プロジェクトのドキュメントディレクトリ構造を作成するスクリプト
+
+set -e
+
+DOCS_DIR="docs"
+
+echo "📂 ドキュメント構造のセットアップを開始します..."
+
+# 1. 現在の状態確認
+if [ -d "$DOCS_DIR" ]; then
+  echo "⚠️  '$DOCS_DIR' ディレクトリは既に存在します。"
+  read -p "既存の構造を保持したまま、不足しているディレクトリを追加しますか？ (y/N): " confirm
+  if [[ ! "$confirm" =~ ^[Yy]$ ]]; then
+    echo "❌ 中断しました。"
+    exit 0
+  fi
+fi
+
+# 2. ディレクトリ構造の作成
+echo "🔨 ディレクトリを作成中..."
+mkdir -p "$DOCS_DIR/project/01-requirements"
+mkdir -p "$DOCS_DIR/project/02-behavior"
+mkdir -p "$DOCS_DIR/project/03-domain"
+mkdir -p "$DOCS_DIR/project/04-design"
+mkdir -p "$DOCS_DIR/tasks"
+
+# 3. docs/README.md の作成
+README_FILE="$DOCS_DIR/README.md"
+if [ -f "$README_FILE" ]; then
+  echo "⚠️  '$README_FILE' は既に存在します。"
+  read -p "上書きしますか？ (y/N): " confirm_readme
+  if [[ ! "$confirm_readme" =~ ^[Yy]$ ]]; then
+    echo "ℹ️  READMEの作成をスキップしました。"
+  else
+    CREATE_README=true
+  fi
+else
+  CREATE_README=true
+fi
+
+if [ "$CREATE_README" = true ]; then
+  echo "📝 README.md を作成中..."
+  cat > "$README_FILE" <<EOF
+# プロジェクトドキュメント
+
+このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
+
+## 構成
+
+### project/
+プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
+
+- **01-requirements/**: 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリーなど）
+- **02-behavior/**: 振る舞い定義（シナリオ、ユースケース、ユーザージャーニーなど）
+- **03-domain/**: ドメインモデル（エンティティ、用語集など）
+- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
+
+### tasks/
+個別タスクのドキュメント。Issue やチケット単位で作成します。
+
+## 更新方針
+
+### プロジェクト全体のドキュメント (project/)
+- プロジェクトのスコープ全体に影響する情報を記載
+- チーム全体で共有すべき要件・設計・アーキテクチャを管理
+- 更新時は関係者にレビューを依頼
+
+### 個別タスクのドキュメント (tasks/)
+- 特定の Issue やチケットに紐づく情報を記載
+- タスク単位で作成・完了・アーカイブ
+- 完了後は参照資料として保持、または削除
+
+## ドキュメント作成ガイドライン
+
+- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
+- **測定可能**: 成功基準やパフォーマンス目標を定量化
+- **最新**: 変更があれば速やかに更新し、古い情報を残さない
+- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
+EOF
+fi
+
+# 4. 完了報告
+echo ""
+echo "✅ ドキュメントディレクトリ構造のセットアップが完了しました！"
+echo ""
+find "$DOCS_DIR" -maxdepth 2 | sort
+echo ""
+echo "次のステップ:"
+echo "  - 必要に応じて 'git add $DOCS_DIR' を実行してください。"

package/.windsurf/templates/project/03-domain/01-domain-model.md

@@ -52,6 +52,7 @@ Event Storming形式とは:
 <!-- このBounded Contextが担当するビジネス機能を1-2文で記述 -->
 
 **主要な責任**:
+
 - <!-- 責任1 -->
 - <!-- 責任2 -->
 - <!-- 責任3 -->

package/.windsurf/templates/project/04-design/01-tech-stack.md

@@ -172,6 +172,7 @@
 ### 初期フェーズ（プロジェクト開始時）
 
 **決定すべき技術**:
+
 - プログラミング言語、フレームワーク
 - データベース（RDBMS/NoSQL）
 - インフラプロバイダー（AWS/GCP/Azure）
@@ -182,6 +183,7 @@
 **理由**: これらは後から変更するコストが非常に高い。アーキテクチャの基盤となる技術。
 
 **例**:
+
 - フロントエンド: React, Vue, Angular の選択
 - バックエンド: Node.js, Python, Go の選択
 - データベース: PostgreSQL, MySQL, MongoDB の選択
@@ -192,6 +194,7 @@
 ### 中期フェーズ（主要機能実装後）
 
 **決定すべき技術**:
+
 - E2E テストフレームワーク（Playwright, Cypress）
 - パフォーマンステストツール
 - セキュリティスキャンツール
@@ -200,6 +203,7 @@
 **理由**: UI/UX がある程度安定してから導入すべき。初期は画面変更が多く、E2E テストの保守コストが高い。
 
 **導入タイミングの目安**:
+
 - 主要画面の実装完了
 - MVP（Minimum Viable Product）リリース前
 - ユーザーストーリーの 70% 完了時点
@@ -209,6 +213,7 @@
 ### 後期フェーズ（本番運用開始時）
 
 **決定すべき技術**:
+
 - 監視・Observability ツール（Sentry, Datadog, New Relic）
 - ログ集約（CloudWatch Logs, ELK Stack）
 - APM（Application Performance Monitoring）
@@ -219,6 +224,7 @@
 **理由**: 本番環境の実際の負荷やエラーパターンを見てから導入する方が効果的。初期導入はコストのみで価値が低い。
 
 **導入タイミングの目安**:
+
 - 本番リリース 1-2 週間前（監視ツール）
 - パフォーマンス問題が顕在化した時点（キャッシュ層）
 - ユーザー数が一定規模を超えた時点（例: 月間 10,000 アクティブユーザー）
@@ -228,6 +234,7 @@
 ### 随時フェーズ（必要に応じて）
 
 **決定すべき技術**:
+
 - 特定の機能要件に必要なライブラリ
 - 開発効率化ツール
 - 実験的なツール（A/B テスト、Feature Flag など）

package/.windsurf/templates/project/04-design/02-repository-structure.md

@@ -218,8 +218,8 @@ components/ → features/ (NG、コンポーネントは汎用部品)
 | **ファイル・ディレクトリ** | | |
 | React コンポーネント | PascalCase、拡張子 .tsx | `UserProfile.tsx`, `LoginForm.tsx` |
 | TypeScript ファイル | camelCase、拡張子 .ts | `formatDate.ts`, `apiClient.ts` |
-| CSS Modules | *.module.css, *.module.scss | `Button.module.css` |
-| テストファイル | *.test.ts, *.spec.ts | `user.test.ts`, `auth.spec.ts` |
+| CSS Modules | *.module.css,*.module.scss | `Button.module.css` |
+| テストファイル | *.test.ts,*.spec.ts | `user.test.ts`, `auth.spec.ts` |
 | 設定ファイル | ドット始まり、特定の名前 | `.eslintrc.json`, `.env`, `tsconfig.json` |
 | ディレクトリ | kebab-case または camelCase | `user-management/` または `userManagement/` |
 | **コード要素** | | |
@@ -300,6 +300,7 @@ components/ → features/ (NG、コンポーネントは汎用部品)
 **採用戦略**: <!-- 例: 機能別コロケーション -->
 
 **配置例**:
+
 ```
 features/user/
 ├── UserProfile.tsx          # コンポーネント

package/.windsurf/templates/project/04-design/03-screen-design.md

@@ -166,12 +166,14 @@ Mermaidの記法:
   - flowchart TD: 上から下へのフロー
   - flowchart LR: 左から右へのフロー
   - A[画面名] --> B[画面名]: 遷移
-  - A --> |条件| B: 条件付き遷移
+
+- A --> |条件| B: 条件付き遷移
 
 よくあるパターン:
-  - 未認証 → ログイン → ダッシュボード → 各機能画面
-  - エラー画面 → トップページ
-  - 管理画面は別フローで記載
+
+- 未認証 → ログイン → ダッシュボード → 各機能画面
+- エラー画面 → トップページ
+- 管理画面は別フローで記載
 -->
 
 ```mermaid
@@ -239,6 +241,7 @@ flowchart TD
 **役割**: ユーザーの認証・認可を管理し、システムへの安全なアクセスを提供
 
 **含まれる画面**:
+
 - ログイン画面（SCR-001）
 - サインアップ画面（SCR-002）
 - パスワードリセット画面（SCR-003）
@@ -256,6 +259,7 @@ flowchart TD
 **役割**: システムの主要な業務機能を提供
 
 **含まれる画面**:
+
 - ダッシュボード（SCR-010）
 - ユーザー一覧（SCR-011）
 - ユーザー詳細（SCR-012）
@@ -332,6 +336,7 @@ flowchart TD
 | **2xl** (2X Large) | `≥ 1536px` | 大型デスクトップ、4Kモニター | 最大コンテンツ幅制限 |
 
 **実装例（Tailwind CSS形式）**:
+
 ```css
 /* tailwind.config.js */
 module.exports = {
@@ -348,6 +353,7 @@ module.exports = {
 ```
 
 **CSS変数での実装例**:
+
 ```css
 :root {
   --breakpoint-sm: 640px;
@@ -380,6 +386,7 @@ module.exports = {
 | **大型モニター (4K)** | 検討中 | 1920px 以上 | コンテンツ最大幅で制限 (max-width: 1536px) |
 
 **モバイルファースト戦略を採用**:
+
 - デザイン・実装はスマートフォン画面から開始
 - 段階的にタブレット、デスクトップに対応
 - パフォーマンス最適化をモバイル基準で実施
@@ -452,6 +459,7 @@ module.exports = {
 | **動画** | モバイルは自動再生オフ、データ通信量考慮 | `preload="metadata"`, 解像度別エンコード |
 
 **実装例**:
+
 ```html
 <picture>
   <source srcset="image.avif" type="image/avif">
@@ -484,6 +492,7 @@ module.exports = {
 | **ピンチズーム** | 画像ギャラリーで有効化 | `user-scalable=yes` を設定 |
 
 **アクセシブルなボタン実装例**:
+
 ```css
 .button {
   min-width: 44px;
@@ -522,6 +531,7 @@ module.exports = {
 | **TTI (Time to Interactive)** | < 3.5秒（3G回線） | Critical CSS インライン化、遅延ローディング |
 
 **モバイルネットワーク対応**:
+
 - 3G回線でのテストを実施（Chrome DevTools のネットワークスロットリング使用）
 - オフライン時の適切なフォールバック表示
 - プログレッシブWebアプリ（PWA）化を検討

package/.windsurf/templates/project/04-design/05-api-spec.md

@@ -146,6 +146,7 @@ API のセキュリティ方式の基本情報
 ### 成功レスポンス
 
 **基本構造**:
+
 ```json
 {
   "data": { /* リソースデータ */ },
@@ -154,6 +155,7 @@ API のセキュリティ方式の基本情報
 ```
 
 **単一リソース取得の例**:
+
 ```json
 {
   "data": {
@@ -166,6 +168,7 @@ API のセキュリティ方式の基本情報
 ```
 
 **リスト取得の例**:
+
 ```json
 {
   "data": [
@@ -183,6 +186,7 @@ API のセキュリティ方式の基本情報
 ### エラーレスポンス
 
 **基本構造**:
+
 ```json
 {
   "error": {
@@ -193,6 +197,7 @@ API のセキュリティ方式の基本情報
 ```
 
 **バリデーションエラーの例**:
+
 ```json
 {
   "error": {

package/.windsurf/templates/tasks/task-template/c-implementation.md

@@ -154,6 +154,7 @@
 -->
 
 ### フェーズ 1 の受け入れ基準
+
 - [ ] データベースマイグレーションが成功する
 - [ ] 型定義が正しく適用される（TypeScript コンパイルエラーなし）
 - [ ] メール送信 API がトークンを生成し、メールを送信する
@@ -161,6 +162,7 @@
 - [ ] トークンの有効期限切れが正しく検出される
 
 ### フェーズ 2 の受け入れ基準
+
 - [ ] メール認証ページが正しく表示される
 - [ ] 認証成功時に成功メッセージが表示される
 - [ ] 認証失敗時にエラーメッセージが表示される
@@ -168,6 +170,7 @@
 - [ ] 認証済みユーザーは全ての機能にアクセスできる
 
 ### フェーズ 3 の受け入れ基準
+
 - [ ] 全てのユニットテストが通る
 - [ ] 全ての統合テストが通る
 - [ ] E2E テストが通る（CI 環境でも実行）

package/.windsurf/workflows/a-001-SetupDocStructure.md

@@ -43,6 +43,7 @@ auto_execution_mode: 1
 
 - スクリプトの実行結果を確認し、エラーがないことを確認してください。
 - 生成された構造：
+
   ```
   docs/
   ├── README.md
@@ -58,10 +59,12 @@ auto_execution_mode: 1
 
 - ユーザーに確認：「作成したディレクトリ構造を Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/
   git status
   ```
+
 - Git status の結果を表示し、コミットメッセージの提案をする：
 
   ```

package/.windsurf/workflows/a-002-InitializeProject.md

@@ -36,20 +36,24 @@ auto_execution_mode: 1
 1. **コードベースの規模確認**:
 
    - プロジェクトのルートにあるファイルやディレクトリを確認する。
+
      ```bash
      ls -F
      ```
+
    - **スキップ判断**:
      - ファイルがほとんど存在しない（例: `.git` ディレクトリのみ、あるいは `README.md` だけなど）、または有意なソースコードが見当たらない場合は、このステップをスキップする。
      - スキップする場合、ユーザーに「コードベースが空、または十分な情報がないため、自動分析をスキップします。」と通知し、次のステップへ進む。
 
 2. **詳細調査と分析（コードが存在する場合）**:
    - `README.md`, `package.json`, および主要なソースコードを読み込む。
+
      ```bash
      cat package.json 2>/dev/null
      cat README.md 2>/dev/null
      find src app lib -maxdepth 2 2>/dev/null
      ```
+
    - 読み込んだ情報を基に、以下の内容を分析・推測し、ユーザーに提示する。
      - **システム概要**: プロジェクトの目的、主要な技術スタック。
      - **実装済み機能**: ファイル構造やコードから推測される機能。
@@ -91,12 +95,14 @@ auto_execution_mode: 1
 2. **コードベースの調査と提案**:
 
    - プロジェクト内のソースコードを簡易検索し、実装済みの兆候を探す。
+
      ```bash
      # 主要なソースディレクトリの構造を確認（例）
      find src app lib -maxdepth 2 -type d 2>/dev/null
      # 特徴的なファイル名を検索
      find . -type f -name "*Controller*" -o -name "*Service*" -o -name "*Component*" | head -n 20
      ```
+
    - 検出されたディレクトリ名やファイル名から機能を推測し、ユーザーに提案する。
      - 「`src/auth` ディレクトリが見つかりました。認証機能（ログイン、登録など）は実装済みですか？」
      - 「`PaymentController` があります。決済機能は稼働していますか？」
@@ -246,10 +252,12 @@ auto_execution_mode: 1
 
 - ユーザーに確認：「作成した要件定義ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/requirements/
   git status
   ```
+
 - Git status の結果を表示し、コミットメッセージの提案をする：
 
   ```

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

@@ -21,6 +21,7 @@ description: ユーザーストーリーから具体的なGherkinシナリオを
 ### 1. ディレクトリと前提条件の確認
 
 - `docs/project/behavior/` ディレクトリの存在を確認：
+
   ```bash
   ls -la docs/project/behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
   ```
@@ -34,6 +35,7 @@ description: ユーザーストーリーから具体的なGherkinシナリオを
 ### 2. テンプレートの準備
 
 - テンプレートをコピーして作業用ファイルを作成する：
+
   ```bash
   cp ".windsurf/templates/project/02-behavior/01-scenarios.md" "docs/project/behavior/01-scenarios.md"
   ```
@@ -52,19 +54,23 @@ description: ユーザーストーリーから具体的なGherkinシナリオを
 各機能について、以下の順序でヒアリングを行い、`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` など）を付与する。
 
@@ -84,6 +90,7 @@ description: ユーザーストーリーから具体的なGherkinシナリオを
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # シナリオ一覧テーブルの確認
      grep "| シナリオID | 機能 |" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Table Header"
@@ -103,11 +110,14 @@ description: ユーザーストーリーから具体的なGherkinシナリオを
 
 - ユーザーに確認：「作成したシナリオドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/behavior/
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: 振る舞い仕様（シナリオ）の作成
 

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

@@ -21,6 +21,7 @@ description: Event Storming形式でドメインモデルを定義し、ユビ
 ### 1. ディレクトリと前提条件の確認
 
 - `docs/project/domain/` ディレクトリの存在を確認：
+
   ```bash
   ls -la docs/project/domain/ 2>/dev/null || echo "ディレクトリが存在しません"
   ```
@@ -34,6 +35,7 @@ description: Event Storming形式でドメインモデルを定義し、ユビ
 ### 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"
@@ -51,15 +53,18 @@ description: Event Storming形式でドメインモデルを定義し、ユビ
 **同時に、新しい用語が登場するたびに `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**）
@@ -87,6 +92,7 @@ description: Event Storming形式でドメインモデルを定義し、ユビ
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # Bounded Context定義の確認
      grep "Bounded Context:" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Bounded Context definition"
@@ -105,11 +111,14 @@ description: Event Storming形式でドメインモデルを定義し、ユビ
 
 - ユーザーに確認：「作成したドメインモデルドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/domain/
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: ドメインモデルとユビキタス言語の定義
 

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

@@ -20,6 +20,7 @@ description: ドメインモデルをMermaid図で視覚化し、Context MapやA
 ### 1. ドキュメントの確認
 
 - `docs/project/domain/01-domain-model.md` を読み込み、内容を確認する。
+
   ```bash
   ls -la docs/project/domain/01-domain-model.md 2>/dev/null || echo "ファイルが存在しません"
   ```
@@ -70,6 +71,7 @@ description: ドメインモデルをMermaid図で視覚化し、Context MapやA
 - 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
 
   1. **構造確認**:
+
      ```bash
      # Mermaidブロックの存在確認
      grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Mermaid diagram"
@@ -86,11 +88,14 @@ description: ドメインモデルをMermaid図で視覚化し、Context MapやA
 
 - ユーザーに確認：「更新したドメインモデルドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
+
   ```bash
   git add docs/project/domain/01-domain-model.md
   git status
   ```
+
 - 推奨コミットメッセージ：
+
   ```
   docs: ドメインモデル図（Context Map）の追加