yodogawa 2.1.0 → 2.1.3

package/skills/a-002-initialize-project/reference/structure-check.md

@@ -6,23 +6,23 @@ SKILL.md 手順9で使う、生成済みドキュメントの構造確認用コ
 
 ```bash
 # 01-system-overview.md: 主要セクションの確認
-grep "## 背景" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
-grep "## 目的" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
+grep "## 背景" docs/project/01-requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
+grep "## 目的" docs/project/01-requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
 
 # 02-features-implemented.md: テーブルヘッダー
-grep "| 機能ID | Category 1 |" docs/project/requirements/02-features-implemented.md \
+grep "| 機能ID | Category 1 |" docs/project/01-requirements/02-features-implemented.md \
   && echo "OK" || echo "MISSING: Table Header"
 
 # 03-features-planned.md: テーブルヘッダー
-grep "| Category 1 | Category 2 |" docs/project/requirements/03-features-planned.md \
+grep "| Category 1 | Category 2 |" docs/project/01-requirements/03-features-planned.md \
   && echo "OK" || echo "MISSING: Table Header"
 
 # 04-non-functional-requirements.md: テーブルヘッダー
-grep "| カテゴリ | 要件 |" docs/project/requirements/04-non-functional-requirements.md \
+grep "| カテゴリ | 要件 |" docs/project/01-requirements/04-non-functional-requirements.md \
   && echo "OK" || echo "MISSING: Table Header"
 
 # 05-user-stories.md: テーブルヘッダー
-grep "| ストーリーID | ストーリー |" docs/project/requirements/05-user-stories.md \
+grep "| ストーリーID | ストーリー |" docs/project/01-requirements/05-user-stories.md \
   && echo "OK" || echo "MISSING: Table Header"
 ```
 
@@ -35,7 +35,7 @@ grep "| ストーリーID | ストーリー |" docs/project/requirements/05-user
 ## Git への追加（オプション）
 
 ```bash
-git add docs/project/requirements/
+git add docs/project/01-requirements/
 git status
 ```
 

package/skills/a-003-create-scenarios/SKILL.md

@@ -1,99 +1,96 @@
----
-name: a-003-create-scenarios
-description: ユーザーストーリーから Gherkin 形式のシナリオを生成し、BDD で振る舞いを定義する。要件定義後、ドメインモデル設計前の振る舞い明確化に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# CreateScenarios (a-003)
-
-## 目的
-
-- ユーザーストーリーから具体的なシナリオ（振る舞い）を抽出し、Gherkin 形式で記述する。
-- Given-When-Then 構造で、開発者・QA・ステークホルダーが共通理解できる実行可能なドキュメントを作成する。
-- ハッピーパス（正常系）からエラーケース、境界値テストまでを網羅的に定義する。
-
-## 前提
-
-- `docs/project/requirements/05-user-stories.md` が作成されていること（`/a-002-initialize-project` 実行済み）。
-- `docs/project/behavior/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
-- ユーザーが各機能の具体的な動作例を説明できること。
-
-## 手順
-
-### 1. ディレクトリと前提条件の確認
-
-```bash
-ls -la docs/project/behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
-```
-
-`docs/project/requirements/05-user-stories.md` を読み込み、シナリオ化対象を把握する。
-
-### 2. テンプレートの準備
-
-```bash
-SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/02-behavior/01-scenarios.md" "docs/project/behavior/01-scenarios.md"
-```
-
-### 3. 分析と提案
-
-ユーザーストーリーを機能（Feature）単位にグルーピングし、ハッピーパスと代表的なエラーケースの案を提示。
-
-- 「機能: [機能名] (US-XXX)」
-- 「シナリオ案1: [ハッピーパス] / シナリオ案2: [エラーケース]」
-
-### 4. ヒアリングと記入
-
-機能ごとに以下を詰めて `docs/project/behavior/01-scenarios.md` を更新する。Gherkin 記述例は [examples/gherkin-templates.md](examples/gherkin-templates.md) を参照。
-
-- **Feature 情報**: 機能名、As a/I want/So that、Background（共通前提）
-- **ハッピーパス**: Given-When-Then で最も基本的な成功シナリオ
-- **エラーケース・境界値**: 必要に応じて Scenario Outline（Examples テーブル）を使用
-- **タグ付け**: `@SC-XXX` ID 採番、`@smoke` `@happy-path` `@error-handling` 等
-
-UI 操作の詳細ではなく、ユーザーの意図を記述するよう注意する。
-
-### 5. シナリオ一覧テーブルの更新
-
-ドキュメント冒頭の一覧テーブルに、全シナリオの ID・機能・シナリオ名・優先度を記載する。テーブル例は [examples/gherkin-templates.md](examples/gherkin-templates.md#シナリオ一覧テーブル例) を参照。
-
-### 6. レビューと確認
-
-ユーザーに提示し、実際の動作の正確性、抜け漏れ、非技術者への理解可能性を確認する。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
-
-### 7. 構造チェック
-
-```bash
-grep "Feature:" docs/project/behavior/01-scenarios.md \
-  && grep "Scenario:" docs/project/behavior/01-scenarios.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細なチェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 8. Git への追加（任意）
-
-```bash
-git add docs/project/behavior/
-git commit -m "docs: 振る舞い仕様（シナリオ）の作成"
-```
-
-詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
-
-## 完了条件
-
-- `docs/project/behavior/01-scenarios.md` が作成されている。
-- ユーザーストーリーに対応する具体的なシナリオ（Given-When-Then）が記述されている。
-- シナリオ一覧テーブルがメンテナンスされている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **ユーザーストーリーが不明確でシナリオ化できない**: 「`/a-002-initialize-project` に戻って要件を明確にしましょう。」
-- **実装詳細への依存が強すぎる**: 「UI 操作（ボタンクリック等）ではなく、ユーザーの意図（登録する等）に焦点を当てた記述に変更しましょう。」
-
-## 参考
-
-- [examples/gherkin-templates.md](examples/gherkin-templates.md) — Feature / Scenario / Scenario Outline の記述例、タグ付けガイド、一覧テーブル例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、Git 追加例
+---
+name: a-003-create-scenarios
+description: ユーザーストーリーから Gherkin 形式のシナリオを生成し、BDD で振る舞いを定義する。要件定義後、ドメインモデル設計前の振る舞い明確化に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# CreateScenarios (a-003)
+
+## 目的
+
+- ユーザーストーリーから具体的なシナリオ（振る舞い）を抽出し、Gherkin 形式で記述する。
+- Given-When-Then 構造で、開発者・QA・ステークホルダーが共通理解できる実行可能なドキュメントを作成する。
+- ハッピーパス（正常系）からエラーケース、境界値テストまでを網羅的に定義する。
+
+## 前提
+
+- `docs/project/01-requirements/05-user-stories.md` が作成されていること（`/a-002-initialize-project` 実行済み）。
+- `docs/project/02-behavior/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
+- ユーザーが各機能の具体的な動作例を説明できること。
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+```bash
+ls -la docs/project/02-behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+`docs/project/01-requirements/05-user-stories.md` を読み込み、シナリオ化対象を把握する。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-003-create-scenarios/`）を起点に、相対パス `../../templates/project/02-behavior/01-scenarios.md` を Read で読み込み、その内容を `docs/project/02-behavior/01-scenarios.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/02-behavior/`）が無ければ作成する。
+
+### 3. 分析と提案
+
+ユーザーストーリーを機能（Feature）単位にグルーピングし、ハッピーパスと代表的なエラーケースの案を提示。
+
+- 「機能: [機能名] (US-XXX)」
+- 「シナリオ案1: [ハッピーパス] / シナリオ案2: [エラーケース]」
+
+### 4. ヒアリングと記入
+
+機能ごとに以下を詰めて `docs/project/02-behavior/01-scenarios.md` を更新する。Gherkin 記述例は [examples/gherkin-templates.md](examples/gherkin-templates.md) を参照。
+
+- **Feature 情報**: 機能名、As a/I want/So that、Background（共通前提）
+- **ハッピーパス**: Given-When-Then で最も基本的な成功シナリオ
+- **エラーケース・境界値**: 必要に応じて Scenario Outline（Examples テーブル）を使用
+- **タグ付け**: `@SC-XXX` ID 採番、`@smoke` `@happy-path` `@error-handling` 等
+
+UI 操作の詳細ではなく、ユーザーの意図を記述するよう注意する。
+
+### 5. シナリオ一覧テーブルの更新
+
+ドキュメント冒頭の一覧テーブルに、全シナリオの ID・機能・シナリオ名・優先度を記載する。テーブル例は [examples/gherkin-templates.md](examples/gherkin-templates.md#シナリオ一覧テーブル例) を参照。
+
+### 6. レビューと確認
+
+ユーザーに提示し、実際の動作の正確性、抜け漏れ、非技術者への理解可能性を確認する。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
+
+### 7. 構造チェック
+
+```bash
+grep "Feature:" docs/project/02-behavior/01-scenarios.md \
+  && grep "Scenario:" docs/project/02-behavior/01-scenarios.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細なチェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 8. Git への追加（任意）
+
+```bash
+git add docs/project/02-behavior/
+git commit -m "docs: 振る舞い仕様（シナリオ）の作成"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/02-behavior/01-scenarios.md` が作成されている。
+- ユーザーストーリーに対応する具体的なシナリオ（Given-When-Then）が記述されている。
+- シナリオ一覧テーブルがメンテナンスされている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **ユーザーストーリーが不明確でシナリオ化できない**: 「`/a-002-initialize-project` に戻って要件を明確にしましょう。」
+- **実装詳細への依存が強すぎる**: 「UI 操作（ボタンクリック等）ではなく、ユーザーの意図（登録する等）に焦点を当てた記述に変更しましょう。」
+
+## 参考
+
+- [examples/gherkin-templates.md](examples/gherkin-templates.md) — Feature / Scenario / Scenario Outline の記述例、タグ付けガイド、一覧テーブル例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、Git 追加例

package/skills/a-003-create-scenarios/reference/structure-check.md

@@ -6,16 +6,16 @@ SKILL.md 手順6〜7 で使う構造確認コマンドとレビュー観点。
 
 ```bash
 # シナリオ一覧テーブルの確認
-grep "| シナリオID | 機能 |" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Table Header"
+grep "| シナリオID | 機能 |" docs/project/02-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"
+grep "Feature:" docs/project/02-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"
+grep "Scenario:" docs/project/02-behavior/01-scenarios.md && echo "OK" || echo "MISSING: Scenario definition"
 ```
 
 ## チェックリスト
 
-- [ ] `docs/project/behavior/01-scenarios.md` が作成されている
+- [ ] `docs/project/02-behavior/01-scenarios.md` が作成されている
 - [ ] シナリオ一覧テーブルが更新されている
 - [ ] 各 Feature が Gherkin 形式で記述されている
 - [ ] 正常系と異常系のシナリオが網羅されている
@@ -32,7 +32,7 @@ grep "Scenario:" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MIS
 ## Git への追加（任意）
 
 ```bash
-git add docs/project/behavior/
+git add docs/project/02-behavior/
 git status
 ```
 

package/skills/a-004-define-domain-model/SKILL.md

@@ -1,99 +1,98 @@
----
-name: a-004-define-domain-model
-description: Event Storming 形式でドメインモデル（イベント・コマンド・集約）を定義し、ユビキタス言語を整備する。シナリオ作成後、ドメイン設計を開始する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineDomainModel (a-004)
-
-## 目的
-
-- Event Storming 形式でドメインモデルを体系的に定義する。
-- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
-- Bounded Context を特定し、Actors / Commands / Events / Policies / Aggregates を明確化する。
-
-## 前提
-
-- `docs/project/behavior/01-scenarios.md` が作成されている（`/a-003-create-scenarios` 実行済み）
-- `docs/project/domain/` ディレクトリが存在（なければ `/a-001-setup-doc-structure`）
-- ドメインエキスパートと協力できる
-
-## 手順
-
-### 1. ディレクトリと前提条件の確認
-
-```bash
-ls -la docs/project/domain/ 2>/dev/null || echo "ディレクトリが存在しません"
-```
-
-存在しなければ `/a-001-setup-doc-structure` を促す。`docs/project/behavior/01-scenarios.md` を読み込み内容確認。
-
-### 2. テンプレートの準備
-
-```bash
-SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/03-domain/01-domain-model.md" "docs/project/domain/01-domain-model.md"
-cp "$SCRIPT_DIR/templates/project/03-domain/02-ubiquitous-language.md" "docs/project/domain/02-ubiquitous-language.md"
-```
-
-### 3. Bounded Context の特定
-
-シナリオとユーザーストーリーから Bounded Context を提案し、戦略的分類（Core / Supporting / Generic）を確認。詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#bounded-context-の特定) を参照。
-
-### 4. 各 Bounded Context のドメインモデル定義
-
-各 Context について以下を定義し、`01-domain-model.md` を更新。新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記。
-
-- 概要とアクター
-- コマンド / イベント / ポリシー（Event Storming）
-- 集約 / Read Models / External Systems
-
-各要素の詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#各-context-の定義項目) を参照。
-
-### 5. ユビキタス言語の洗練
-
-`02-ubiquitous-language.md` を見直し、重複・曖昧さ・禁止用語を排除。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md#ユビキタス言語の洗練観点) を参照。
-
-### 6. Context Map の定義
-
-Context 間の関係性（Customer-Supplier, Shared Kernel 等）を Mermaid 図で定義。関係パターン: [reference/event-storming-guide.md](reference/event-storming-guide.md#context-map-の関係性)
-
-### 7. レビューと確認
-
-作成したドキュメントを提示し、ビジネス用語の正確性 / Aggregate 境界 / ユビキタス言語定義を確認。
-
-### 8. 完了条件と構造の確認
-
-構造確認コマンドは [reference/event-storming-guide.md](reference/event-storming-guide.md#構造確認コマンド) を参照。
-
-チェックリスト:
-
-- [ ] `01-domain-model.md` に主要な Event Storming 要素が含まれている
-- [ ] `02-ubiquitous-language.md` の用語が定義されている
-- [ ] ドメインモデルとユビキタス言語の整合性が取れている
-
-### 9. Git への追加（オプション）
-
-```bash
-git add docs/project/domain/
-git status
-```
-
-コミットメッセージ: [reference/event-storming-guide.md](reference/event-storming-guide.md#git-コミットメッセージ)
-
-## 完了条件
-
-- `docs/project/domain/01-domain-model.md` と `02-ubiquitous-language.md` が作成されている
-- 各 Bounded Context の主要ドメイン要素（Aggregates, Commands, Events）が定義されている
-- ドメインモデルで使用される用語がユビキタス言語として定義されている
-- ユーザーが内容を承認している
-
-## エスカレーション
-
-- **シナリオが不足**: 「`/a-003-create-scenarios` に戻ってシナリオを充実させましょう。」
-- **Bounded Context の境界が不明確**: 「暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」
-
-## 参考
-
-- [reference/event-storming-guide.md](reference/event-storming-guide.md) — Event Storming の観点、Context Map パターン、構造確認コマンド
+---
+name: a-004-define-domain-model
+description: Event Storming 形式でドメインモデル（イベント・コマンド・集約）を定義し、ユビキタス言語を整備する。シナリオ作成後、ドメイン設計を開始する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineDomainModel (a-004)
+
+## 目的
+
+- Event Storming 形式でドメインモデルを体系的に定義する。
+- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
+- Bounded Context を特定し、Actors / Commands / Events / Policies / Aggregates を明確化する。
+
+## 前提
+
+- `docs/project/02-behavior/01-scenarios.md` が作成されている（`/a-003-create-scenarios` 実行済み）
+- `docs/project/03-domain/` ディレクトリが存在（なければ `/a-001-setup-doc-structure`）
+- ドメインエキスパートと協力できる
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+```bash
+ls -la docs/project/03-domain/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+存在しなければ `/a-001-setup-doc-structure` を促す。`docs/project/02-behavior/01-scenarios.md` を読み込み内容確認。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-004-define-domain-model/`）を起点に、`docs/project/03-domain/` へ次の 2 ファイルを Read→Write する（FOR EACH）。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/03-domain/`）が無ければ作成する。
+
+- `../../templates/project/03-domain/01-domain-model.md` → `docs/project/03-domain/01-domain-model.md`
+- `../../templates/project/03-domain/02-ubiquitous-language.md` → `docs/project/03-domain/02-ubiquitous-language.md`
+
+### 3. Bounded Context の特定
+
+シナリオとユーザーストーリーから Bounded Context を提案し、戦略的分類（Core / Supporting / Generic）を確認。詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#bounded-context-の特定) を参照。
+
+### 4. 各 Bounded Context のドメインモデル定義
+
+各 Context について以下を定義し、`01-domain-model.md` を更新。新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記。
+
+- 概要とアクター
+- コマンド / イベント / ポリシー（Event Storming）
+- 集約 / Read Models / External Systems
+
+各要素の詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#各-context-の定義項目) を参照。
+
+### 5. ユビキタス言語の洗練
+
+`02-ubiquitous-language.md` を見直し、重複・曖昧さ・禁止用語を排除。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md#ユビキタス言語の洗練観点) を参照。
+
+### 6. Context Map の定義
+
+Context 間の関係性（Customer-Supplier, Shared Kernel 等）を Mermaid 図で定義。関係パターン: [reference/event-storming-guide.md](reference/event-storming-guide.md#context-map-の関係性)
+
+### 7. レビューと確認
+
+作成したドキュメントを提示し、ビジネス用語の正確性 / Aggregate 境界 / ユビキタス言語定義を確認。
+
+### 8. 完了条件と構造の確認
+
+構造確認コマンドは [reference/event-storming-guide.md](reference/event-storming-guide.md#構造確認コマンド) を参照。
+
+チェックリスト:
+
+- [ ] `01-domain-model.md` に主要な Event Storming 要素が含まれている
+- [ ] `02-ubiquitous-language.md` の用語が定義されている
+- [ ] ドメインモデルとユビキタス言語の整合性が取れている
+
+### 9. Git への追加（オプション）
+
+```bash
+git add docs/project/03-domain/
+git status
+```
+
+コミットメッセージ: [reference/event-storming-guide.md](reference/event-storming-guide.md#git-コミットメッセージ)
+
+## 完了条件
+
+- `docs/project/03-domain/01-domain-model.md` と `02-ubiquitous-language.md` が作成されている
+- 各 Bounded Context の主要ドメイン要素（Aggregates, Commands, Events）が定義されている
+- ドメインモデルで使用される用語がユビキタス言語として定義されている
+- ユーザーが内容を承認している
+
+## エスカレーション
+
+- **シナリオが不足**: 「`/a-003-create-scenarios` に戻ってシナリオを充実させましょう。」
+- **Bounded Context の境界が不明確**: 「暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」
+
+## 参考
+
+- [reference/event-storming-guide.md](reference/event-storming-guide.md) — Event Storming の観点、Context Map パターン、構造確認コマンド

package/skills/a-004-define-domain-model/reference/event-storming-guide.md

@@ -53,11 +53,11 @@ SKILL.md 手順3〜6で使うドメインモデル定義の観点集。
 ## 構造確認コマンド
 
 ```bash
-grep "Bounded Context:" docs/project/domain/01-domain-model.md \
+grep "Bounded Context:" docs/project/03-domain/01-domain-model.md \
   && echo "OK" || echo "MISSING: Bounded Context definition"
-grep "### Aggregates" docs/project/domain/01-domain-model.md \
+grep "### Aggregates" docs/project/03-domain/01-domain-model.md \
   && echo "OK" || echo "MISSING: Aggregates section"
-grep "| 用語 | 定義 |" docs/project/domain/02-ubiquitous-language.md \
+grep "| 用語 | 定義 |" docs/project/03-domain/02-ubiquitous-language.md \
   && echo "OK" || echo "MISSING: Terminology table"
 ```
 

package/skills/a-005-create-domain-diagram/SKILL.md

@@ -15,7 +15,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ## 前提
 
-- `docs/project/domain/01-domain-model.md` が作成されていること（`/a-004-define-domain-model` 実行済み）。
+- `docs/project/03-domain/01-domain-model.md` が作成されていること（`/a-004-define-domain-model` 実行済み）。
 - ドメインモデルドキュメントに Bounded Context の一覧と関係性が記述されていること。
 
 ## 手順
@@ -23,14 +23,14 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ### 1. ドキュメントの確認
 
 ```bash
-ls -la docs/project/domain/01-domain-model.md 2>/dev/null || echo "ファイルが存在しません"
+ls -la docs/project/03-domain/01-domain-model.md 2>/dev/null || echo "ファイルが存在しません"
 ```
 
 未作成の場合、`/a-004-define-domain-model` の実行を促す。
 
 ### 2. Context Map の情報収集と提案
 
-`docs/project/domain/01-domain-model.md` から以下を抽出し、構成案を提示する:
+`docs/project/03-domain/01-domain-model.md` から以下を抽出し、構成案を提示する:
 
 - Bounded Context のリスト
 - 戦略的分類（Core / Supporting / Generic）
@@ -59,8 +59,8 @@ ls -la docs/project/domain/01-domain-model.md 2>/dev/null || echo "ファイル
 ### 6. 構造チェック
 
 ```bash
-grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md \
-  && grep "## Context Map" docs/project/domain/01-domain-model.md \
+grep "\`\`\`mermaid" docs/project/03-domain/01-domain-model.md \
+  && grep "## Context Map" docs/project/03-domain/01-domain-model.md \
   && echo "OK" || echo "MISSING SECTION"
 ```
 
@@ -69,7 +69,7 @@ grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md \
 ### 7. Git への追加（任意）
 
 ```bash
-git add docs/project/domain/01-domain-model.md
+git add docs/project/03-domain/01-domain-model.md
 git commit -m "docs: ドメインモデル図（Context Map）の追加"
 ```
 
@@ -77,7 +77,7 @@ git commit -m "docs: ドメインモデル図（Context Map）の追加"
 
 ## 完了条件
 
-- `docs/project/domain/01-domain-model.md` に Context Map 図が追加されている。
+- `docs/project/03-domain/01-domain-model.md` に Context Map 図が追加されている。
 - Bounded Context 間の関係性が正しく表現されている。
 - 戦略的分類が視覚的に区別されている。
 - オプションの詳細図（Aggregate 図、シーケンス図）が必要に応じて追加されている。

package/skills/a-005-create-domain-diagram/reference/structure-check.md

@@ -6,14 +6,14 @@ SKILL.md 手順5〜7 で使用する確認コマンドとレビュー観点。
 
 ```bash
 # Mermaid ブロックの存在確認
-grep "\`\`\`mermaid" docs/project/domain/01-domain-model.md && echo "OK" || echo "MISSING: Mermaid diagram"
+grep "\`\`\`mermaid" docs/project/03-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"
+grep "## Context Map" docs/project/03-domain/01-domain-model.md && echo "OK" || echo "MISSING: Context Map section"
 ```
 
 ## チェックリスト
 
-- [ ] `docs/project/domain/01-domain-model.md` に Context Map 図が含まれている
+- [ ] `docs/project/03-domain/01-domain-model.md` に Context Map 図が含まれている
 - [ ] Mermaid 図が正しくレンダリングされる（構文エラーがない）
 - [ ] 戦略的分類に応じて色分けされている（Core / Supporting / Generic）
 - [ ] 関係パターン（Customer/Supplier など）と通信方法がエッジに記載されている
@@ -29,7 +29,7 @@ grep "## Context Map" docs/project/domain/01-domain-model.md && echo "OK" || ech
 ## Git への追加（任意）
 
 ```bash
-git add docs/project/domain/01-domain-model.md
+git add docs/project/03-domain/01-domain-model.md
 git status
 ```
 

package/skills/a-006-review-requirements-domain/SKILL.md

@@ -19,16 +19,16 @@ allowed-tools: Read, Grep, Glob, Write, Bash
 
 以下のドキュメントが作成されていること:
 
-- `docs/project/requirements/01-system-overview.md` 〜 `05-user-stories.md`
-- `docs/project/behavior/01-scenarios.md`
-- `docs/project/domain/01-domain-model.md`, `02-ubiquitous-language.md`
+- `docs/project/01-requirements/01-system-overview.md` 〜 `05-user-stories.md`
+- `docs/project/02-behavior/01-scenarios.md`
+- `docs/project/03-domain/01-domain-model.md`, `02-ubiquitous-language.md`
 
 ## 手順
 
 ### 1. ドキュメント存在確認
 
 ```bash
-ls -l docs/project/requirements/*.md docs/project/behavior/*.md docs/project/domain/*.md
+ls -l docs/project/01-requirements/*.md docs/project/02-behavior/*.md docs/project/03-domain/*.md
 ```
 
 不足があれば、対応する `/a-002`, `/a-003`, `/a-004` スキルの実行を促す。

package/skills/a-006-review-requirements-domain/reference/consistency-checks.md

@@ -9,9 +9,9 @@ SKILL.md 手順2 で実施する各チェック項目の詳細。自動検索（
 
 ```bash
 # 全ユーザーストーリーの ID 抽出
-grep -oE "US-[0-9]+" docs/project/requirements/05-user-stories.md | sort -u
+grep -oE "US-[0-9]+" docs/project/01-requirements/05-user-stories.md | sort -u
 # シナリオ側の参照
-grep -oE "US-[0-9]+" docs/project/behavior/01-scenarios.md | sort -u
+grep -oE "US-[0-9]+" docs/project/02-behavior/01-scenarios.md | sort -u
 ```
 
 ## 2.2 実装済み機能・予定機能 ↔ シナリオ
@@ -37,9 +37,9 @@ grep -oE "US-[0-9]+" docs/project/behavior/01-scenarios.md | sort -u
 
 ```bash
 # 禁止用語の簡易検索
-grep -rn "Data" docs/project/domain/ || echo "No 'Data' found"
-grep -rn "Process" docs/project/domain/ || echo "No 'Process' found"
-grep -rn "Manager" docs/project/domain/ || echo "No 'Manager' found"
+grep -rn "Data" docs/project/03-domain/ || echo "No 'Data' found"
+grep -rn "Process" docs/project/03-domain/ || echo "No 'Process' found"
+grep -rn "Manager" docs/project/03-domain/ || echo "No 'Manager' found"
 ```
 
 ## 2.6 目的との整合性