yodogawa 2.1.0 → 2.1.3

package/skills/a-011-define-data-model/SKILL.md

@@ -1,121 +1,118 @@
----
-name: a-011-define-data-model
-description: ドメインモデルと画面設計からデータベース構造（ERD・エンティティ・属性・リレーションシップ・制約）を定義する。画面設計後、永続化層を設計する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineDataModel (a-011)
-
-## 目的
-
-- ドメインモデル（Aggregates）と画面設計を基に、データベース構造を定義する。
-- エンティティ（テーブル）、属性（カラム）、リレーションシップを明確化する。
-- データ型、制約（NOT NULL、UNIQUE、CHECK）、インデックス戦略を決定する。
-- Mermaid ERD（Entity Relationship Diagram）で視覚化し、開発者間の認識を統一する。
-
-## 前提
-
-- `docs/project/domain/01-domain-model.md` が作成されていること。
-- `docs/project/design/01-tech-stack.md` が作成されていること（DB 選定済み）。
-- `docs/project/design/03-screen-design.md` が作成されていること。
-- `docs/project/design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-以下を読み込む:
-
-- `docs/project/domain/01-domain-model.md`
-- `docs/project/design/01-tech-stack.md`
-- `docs/project/design/03-screen-design.md`
-
-不足があれば対応スキルの実行を促す。
-
-### 2. テンプレートの準備
-
-```bash
-SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/05-data-model.md" "docs/project/design/05-data-model.md"
-```
-
-### 3. エンティティの抽出と提案
-
-- **ドメインモデルから**: Aggregate Root および内部エンティティを抽出
-- **画面設計から**: 表示・入力項目から必要なデータ構造（履歴、設定、ログ等）を抽出
-- 「[エンティティ名] (対応 Aggregate: [名前])」形式で一覧化
-
-エンティティ一覧の記述例は [examples/erd-templates.md](examples/erd-templates.md#エンティティ一覧テーブル) を参照。
-
-### 4. 詳細定義（インタビュー）
-
-#### 4.1 基本定義
-
-- テーブル名（物理名）、論理名、説明
-- 主キー戦略（Auto Increment / UUID / CUID）— 選択ガイドは [examples/erd-templates.md](examples/erd-templates.md#主キー戦略) を参照
-
-#### 4.2 属性（カラム）
-
-- カラム名、データ型（DB 製品に合わせて具体化）
-- 制約（NOT NULL, UNIQUE, DEFAULT, CHECK）
-- 監査カラム（created_at, updated_at）の有無
-
-カラム定義の例は [examples/erd-templates.md](examples/erd-templates.md#カラム定義テンプレート) を参照。
-
-#### 4.3 リレーションシップ
-
-- 関連（1:1 / 1:N / N:M）
-- 外部キー制約（ON DELETE CASCADE / SET NULL / RESTRICT）— 選択基準は [examples/erd-templates.md](examples/erd-templates.md#外部キー削除動作の選択) を参照
-
-### 5. ERD の作成と正規化
-
-- Mermaid ERD 形式で記述（テンプレートは [examples/erd-templates.md](examples/erd-templates.md#mermaid-erd-記述例) を参照）
-- 正規化（1NF-3NF）を確認。意図的な非正規化があれば理由を記録
-- インデックス戦略（検索頻度、UNIQUE、複合インデックス）を定義
-
-正規化の目安は [reference/structure-check.md](reference/structure-check.md#正規化レベルの目安) を参照。
-
-### 6. ドキュメント作成
-
-`docs/project/design/05-data-model.md` に以下を記入する:
-
-- エンティティ一覧
-- リレーションシップ定義
-- ERD（Mermaid）
-- インデックス戦略・非正規化の記録
-
-### 7. 構造チェック
-
-```bash
-grep "## エンティティ一覧" docs/project/design/05-data-model.md \
-  && grep "\`\`\`mermaid" docs/project/design/05-data-model.md \
-  && grep "## リレーションシップ" docs/project/design/05-data-model.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 8. Git への追加（任意）
-
-```bash
-git add docs/project/design/05-data-model.md
-git commit -m "docs: データモデル（ERD）の定義"
-```
-
-## 完了条件
-
-- `docs/project/design/05-data-model.md` が作成されている。
-- データベーススキーマ（テーブル、カラム、型、制約）が定義されている。
-- エンティティ間の関係性が可視化（ERD）されている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **ドメインモデルとの不整合**: 「Aggregate 構造とデータモデルが乖離しています。ORM のマッピング戦略を確認するか、ドメインモデルを見直してください。」
-- **パフォーマンス懸念**: 「正規化により JOIN が多発する可能性があります。Read Model や意図的な非正規化を検討しませんか？」
-
-## 参考
-
-- [examples/erd-templates.md](examples/erd-templates.md) — エンティティ一覧、カラム定義、主キー戦略、外部キー動作、Mermaid ERD、インデックス・非正規化の例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、正規化レベル、レビュー質問
+---
+name: a-011-define-data-model
+description: ドメインモデルと画面設計からデータベース構造（ERD・エンティティ・属性・リレーションシップ・制約）を定義する。画面設計後、永続化層を設計する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineDataModel (a-011)
+
+## 目的
+
+- ドメインモデル（Aggregates）と画面設計を基に、データベース構造を定義する。
+- エンティティ（テーブル）、属性（カラム）、リレーションシップを明確化する。
+- データ型、制約（NOT NULL、UNIQUE、CHECK）、インデックス戦略を決定する。
+- Mermaid ERD（Entity Relationship Diagram）で視覚化し、開発者間の認識を統一する。
+
+## 前提
+
+- `docs/project/03-domain/01-domain-model.md` が作成されていること。
+- `docs/project/04-design/01-tech-stack.md` が作成されていること（DB 選定済み）。
+- `docs/project/04-design/03-screen-design.md` が作成されていること。
+- `docs/project/04-design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+以下を読み込む:
+
+- `docs/project/03-domain/01-domain-model.md`
+- `docs/project/04-design/01-tech-stack.md`
+- `docs/project/04-design/03-screen-design.md`
+
+不足があれば対応スキルの実行を促す。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-011-define-data-model/`）を起点に、相対パス `../../templates/project/04-design/05-data-model.md` を Read で読み込み、その内容を `docs/project/04-design/05-data-model.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. エンティティの抽出と提案
+
+- **ドメインモデルから**: Aggregate Root および内部エンティティを抽出
+- **画面設計から**: 表示・入力項目から必要なデータ構造（履歴、設定、ログ等）を抽出
+- 「[エンティティ名] (対応 Aggregate: [名前])」形式で一覧化
+
+エンティティ一覧の記述例は [examples/erd-templates.md](examples/erd-templates.md#エンティティ一覧テーブル) を参照。
+
+### 4. 詳細定義（インタビュー）
+
+#### 4.1 基本定義
+
+- テーブル名（物理名）、論理名、説明
+- 主キー戦略（Auto Increment / UUID / CUID）— 選択ガイドは [examples/erd-templates.md](examples/erd-templates.md#主キー戦略) を参照
+
+#### 4.2 属性（カラム）
+
+- カラム名、データ型（DB 製品に合わせて具体化）
+- 制約（NOT NULL, UNIQUE, DEFAULT, CHECK）
+- 監査カラム（created_at, updated_at）の有無
+
+カラム定義の例は [examples/erd-templates.md](examples/erd-templates.md#カラム定義テンプレート) を参照。
+
+#### 4.3 リレーションシップ
+
+- 関連（1:1 / 1:N / N:M）
+- 外部キー制約（ON DELETE CASCADE / SET NULL / RESTRICT）— 選択基準は [examples/erd-templates.md](examples/erd-templates.md#外部キー削除動作の選択) を参照
+
+### 5. ERD の作成と正規化
+
+- Mermaid ERD 形式で記述（テンプレートは [examples/erd-templates.md](examples/erd-templates.md#mermaid-erd-記述例) を参照）
+- 正規化（1NF-3NF）を確認。意図的な非正規化があれば理由を記録
+- インデックス戦略（検索頻度、UNIQUE、複合インデックス）を定義
+
+正規化の目安は [reference/structure-check.md](reference/structure-check.md#正規化レベルの目安) を参照。
+
+### 6. ドキュメント作成
+
+`docs/project/04-design/05-data-model.md` に以下を記入する:
+
+- エンティティ一覧
+- リレーションシップ定義
+- ERD（Mermaid）
+- インデックス戦略・非正規化の記録
+
+### 7. 構造チェック
+
+```bash
+grep "## エンティティ一覧" docs/project/04-design/05-data-model.md \
+  && grep "\`\`\`mermaid" docs/project/04-design/05-data-model.md \
+  && grep "## リレーションシップ" docs/project/04-design/05-data-model.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 8. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/05-data-model.md
+git commit -m "docs: データモデル（ERD）の定義"
+```
+
+## 完了条件
+
+- `docs/project/04-design/05-data-model.md` が作成されている。
+- データベーススキーマ（テーブル、カラム、型、制約）が定義されている。
+- エンティティ間の関係性が可視化（ERD）されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **ドメインモデルとの不整合**: 「Aggregate 構造とデータモデルが乖離しています。ORM のマッピング戦略を確認するか、ドメインモデルを見直してください。」
+- **パフォーマンス懸念**: 「正規化により JOIN が多発する可能性があります。Read Model や意図的な非正規化を検討しませんか？」
+
+## 参考
+
+- [examples/erd-templates.md](examples/erd-templates.md) — エンティティ一覧、カラム定義、主キー戦略、外部キー動作、Mermaid ERD、インデックス・非正規化の例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、正規化レベル、レビュー質問

package/skills/a-011-define-data-model/reference/structure-check.md

@@ -6,16 +6,16 @@ SKILL.md 手順7〜8 で使う確認コマンドとレビュー観点。
 
 ```bash
 # エンティティ一覧の確認
-grep "## エンティティ一覧" docs/project/design/05-data-model.md && echo "OK" || echo "MISSING: Entities"
+grep "## エンティティ一覧" docs/project/04-design/05-data-model.md && echo "OK" || echo "MISSING: Entities"
 # ERD の確認
-grep "\`\`\`mermaid" docs/project/design/05-data-model.md && echo "OK" || echo "MISSING: ERD"
+grep "\`\`\`mermaid" docs/project/04-design/05-data-model.md && echo "OK" || echo "MISSING: ERD"
 # リレーションシップ定義の確認
-grep "## リレーションシップ" docs/project/design/05-data-model.md && echo "OK" || echo "MISSING: Relationships"
+grep "## リレーションシップ" docs/project/04-design/05-data-model.md && echo "OK" || echo "MISSING: Relationships"
 ```
 
 ## チェックリスト
 
-- [ ] `docs/project/design/05-data-model.md` が作成されている
+- [ ] `docs/project/04-design/05-data-model.md` が作成されている
 - [ ] 全エンティティの物理名・論理名が定義されている
 - [ ] 各カラムの型・制約・デフォルト値が定義されている
 - [ ] 主キー戦略（Auto Increment / UUID / CUID）が明記されている
@@ -42,7 +42,7 @@ grep "## リレーションシップ" docs/project/design/05-data-model.md && ec
 ## Git への追加（任意）
 
 ```bash
-git add docs/project/design/05-data-model.md
+git add docs/project/04-design/05-data-model.md
 git status
 ```
 

package/skills/a-012-define-api-spec/SKILL.md

@@ -1,108 +1,105 @@
----
-name: a-012-define-api-spec
-description: データモデルと画面設計から API 仕様（認証方式・エンドポイント一覧・共通レスポンス形式）を定義する。データモデル確定後、フロント/バック間のインターフェースを固める際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineAPISpec (a-012)
-
-## 目的
-
-- データモデルと画面設計を基に、API 仕様の基本設計を定義する。
-- API 設計スタイル（REST、GraphQL、gRPC、tRPC）を決定する。
-- 認証・認可方式を明確化する。
-- エンドポイント一覧（メソッド、パス、説明、認証要否）を定義する。
-- 共通レスポンス形式（成功/エラー）を定義する。
-
-## 前提
-
-- `docs/project/design/01-tech-stack.md` が作成されていること（API スタイル選定済み）。
-- `docs/project/design/05-data-model.md` が作成されていること。
-- `docs/project/design/03-screen-design.md` が作成されていること。
-- `docs/project/design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-以下を読み込む:
-
-- `docs/project/design/01-tech-stack.md`
-- `docs/project/design/05-data-model.md`
-- `docs/project/design/03-screen-design.md`
-
-不足があれば対応スキルの実行を促す。
-
-### 2. テンプレートの準備
-
-```bash
-SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/06-api-spec.md" "docs/project/design/06-api-spec.md"
-```
-
-### 3. API スタイルの確認と提案
-
-技術スタックで選定された API スタイル（REST, GraphQL 等）を確認し、データモデルと画面設計から必要なリソースと操作を抽出する。スタイル別の特徴は [examples/api-templates.md](examples/api-templates.md#api-スタイル別の特徴) を参照。
-
-- 「Users: 一覧, 詳細, 作成, 更新, 削除」
-- 「Auth: ログイン, 登録, リフレッシュ」
-
-### 4. 詳細定義（インタビュー）
-
-#### 4.1 認証・認可
-
-認証方式（JWT / OAuth 等）、トークンの保存先（Cookie vs Header）、ロール・スコープ定義。テンプレートは [examples/api-templates.md](examples/api-templates.md#認証認可仕様のテンプレート) を参照。
-
-#### 4.2 エンドポイント詳細
-
-各リソースのパス設計（RESTful 原則）、認証の要否、特殊アクション（`/cancel`, `/publish` 等）。一覧テーブルとパス設計原則は [examples/api-templates.md](examples/api-templates.md#エンドポイント一覧テーブル) を参照。
-
-#### 4.3 共通レスポンス形式
-
-成功・エラー構造、ページネーション、エラーコード体系。JSON サンプルは [examples/api-templates.md](examples/api-templates.md#共通レスポンス形式) を参照。
-
-### 5. ドキュメント作成
-
-`docs/project/design/06-api-spec.md` に以下を記入する:
-
-- 認証・認可仕様
-- エンドポイント一覧（リソース別）
-- 共通レスポンス形式
-- エラーコード体系
-
-### 6. 構造チェック
-
-```bash
-grep "## 認証・認可" docs/project/design/06-api-spec.md \
-  && grep "## エンドポイント一覧" docs/project/design/06-api-spec.md \
-  && grep "## 共通レスポンス形式" docs/project/design/06-api-spec.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/project/design/06-api-spec.md
-git commit -m "docs: API 仕様（基本設計）の作成"
-```
-
-## 完了条件
-
-- `docs/project/design/06-api-spec.md` が作成されている。
-- 認証・認可の仕組みが定義されている。
-- エンドポイント一覧（メソッド、パス、認証要否）が定義されている。
-- 共通レスポンス形式（成功/エラー）が定義されている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **API スタイルが未定**: 「`/a-007-define-tech-stack` に戻って選定してください。」
-- **データモデルとの不整合**: 「データモデルに存在しないリソースのエンドポイントが要求されています。データモデルを見直すか、API だけの概念として定義するか確認してください。」
-
-## 参考
-
-- [examples/api-templates.md](examples/api-templates.md) — API スタイル比較、認証・認可テンプレート、エンドポイント一覧、共通レスポンス、エラーコード体系
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例
+---
+name: a-012-define-api-spec
+description: データモデルと画面設計から API 仕様（認証方式・エンドポイント一覧・共通レスポンス形式）を定義する。データモデル確定後、フロント/バック間のインターフェースを固める際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineAPISpec (a-012)
+
+## 目的
+
+- データモデルと画面設計を基に、API 仕様の基本設計を定義する。
+- API 設計スタイル（REST、GraphQL、gRPC、tRPC）を決定する。
+- 認証・認可方式を明確化する。
+- エンドポイント一覧（メソッド、パス、説明、認証要否）を定義する。
+- 共通レスポンス形式（成功/エラー）を定義する。
+
+## 前提
+
+- `docs/project/04-design/01-tech-stack.md` が作成されていること（API スタイル選定済み）。
+- `docs/project/04-design/05-data-model.md` が作成されていること。
+- `docs/project/04-design/03-screen-design.md` が作成されていること。
+- `docs/project/04-design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+以下を読み込む:
+
+- `docs/project/04-design/01-tech-stack.md`
+- `docs/project/04-design/05-data-model.md`
+- `docs/project/04-design/03-screen-design.md`
+
+不足があれば対応スキルの実行を促す。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-012-define-api-spec/`）を起点に、相対パス `../../templates/project/04-design/06-api-spec.md` を Read で読み込み、その内容を `docs/project/04-design/06-api-spec.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. API スタイルの確認と提案
+
+技術スタックで選定された API スタイル（REST, GraphQL 等）を確認し、データモデルと画面設計から必要なリソースと操作を抽出する。スタイル別の特徴は [examples/api-templates.md](examples/api-templates.md#api-スタイル別の特徴) を参照。
+
+- 「Users: 一覧, 詳細, 作成, 更新, 削除」
+- 「Auth: ログイン, 登録, リフレッシュ」
+
+### 4. 詳細定義（インタビュー）
+
+#### 4.1 認証・認可
+
+認証方式（JWT / OAuth 等）、トークンの保存先（Cookie vs Header）、ロール・スコープ定義。テンプレートは [examples/api-templates.md](examples/api-templates.md#認証認可仕様のテンプレート) を参照。
+
+#### 4.2 エンドポイント詳細
+
+各リソースのパス設計（RESTful 原則）、認証の要否、特殊アクション（`/cancel`, `/publish` 等）。一覧テーブルとパス設計原則は [examples/api-templates.md](examples/api-templates.md#エンドポイント一覧テーブル) を参照。
+
+#### 4.3 共通レスポンス形式
+
+成功・エラー構造、ページネーション、エラーコード体系。JSON サンプルは [examples/api-templates.md](examples/api-templates.md#共通レスポンス形式) を参照。
+
+### 5. ドキュメント作成
+
+`docs/project/04-design/06-api-spec.md` に以下を記入する:
+
+- 認証・認可仕様
+- エンドポイント一覧（リソース別）
+- 共通レスポンス形式
+- エラーコード体系
+
+### 6. 構造チェック
+
+```bash
+grep "## 認証・認可" docs/project/04-design/06-api-spec.md \
+  && grep "## エンドポイント一覧" docs/project/04-design/06-api-spec.md \
+  && grep "## 共通レスポンス形式" docs/project/04-design/06-api-spec.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/06-api-spec.md
+git commit -m "docs: API 仕様（基本設計）の作成"
+```
+
+## 完了条件
+
+- `docs/project/04-design/06-api-spec.md` が作成されている。
+- 認証・認可の仕組みが定義されている。
+- エンドポイント一覧（メソッド、パス、認証要否）が定義されている。
+- 共通レスポンス形式（成功/エラー）が定義されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **API スタイルが未定**: 「`/a-007-define-tech-stack` に戻って選定してください。」
+- **データモデルとの不整合**: 「データモデルに存在しないリソースのエンドポイントが要求されています。データモデルを見直すか、API だけの概念として定義するか確認してください。」
+
+## 参考
+
+- [examples/api-templates.md](examples/api-templates.md) — API スタイル比較、認証・認可テンプレート、エンドポイント一覧、共通レスポンス、エラーコード体系
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例

package/skills/a-012-define-api-spec/reference/structure-check.md

@@ -6,16 +6,16 @@ SKILL.md 手順6〜7 で使う確認コマンドとレビュー観点。
 
 ```bash
 # 認証セクションの確認
-grep "## 認証・認可" docs/project/design/06-api-spec.md && echo "OK" || echo "MISSING: Auth section"
+grep "## 認証・認可" docs/project/04-design/06-api-spec.md && echo "OK" || echo "MISSING: Auth section"
 # エンドポイント一覧の確認
-grep "## エンドポイント一覧" docs/project/design/06-api-spec.md && echo "OK" || echo "MISSING: Endpoints"
+grep "## エンドポイント一覧" docs/project/04-design/06-api-spec.md && echo "OK" || echo "MISSING: Endpoints"
 # レスポンス形式の確認
-grep "## 共通レスポンス形式" docs/project/design/06-api-spec.md && echo "OK" || echo "MISSING: Response format"
+grep "## 共通レスポンス形式" docs/project/04-design/06-api-spec.md && echo "OK" || echo "MISSING: Response format"
 ```
 
 ## チェックリスト
 
-- [ ] `docs/project/design/06-api-spec.md` が作成されている
+- [ ] `docs/project/04-design/06-api-spec.md` が作成されている
 - [ ] 認証方式（JWT / OAuth 等）が明確に定義されている
 - [ ] トークンの保存先（Cookie / Header）が決まっている
 - [ ] ロール・スコープが定義されている
@@ -35,7 +35,7 @@ grep "## 共通レスポンス形式" docs/project/design/06-api-spec.md && echo
 ## Git への追加（任意）
 
 ```bash
-git add docs/project/design/06-api-spec.md
+git add docs/project/04-design/06-api-spec.md
 git status
 ```