yodogawa 2.1.3 → 2.3.0

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

@@ -1,105 +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/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 追加例
+---
+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-013-define-architecture/SKILL.md

@@ -1,98 +1,98 @@
----
-name: a-013-define-architecture
-description: 技術スタック・リポジトリ構造・データモデル・API 仕様を統合し、システムアーキテクチャと ADR を定義する。各設計ドキュメント確定後、全体像と意思決定を文書化する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineArchitecture (a-013)
-
-## 目的
-
-- これまでに定義された設計（技術スタック、リポジトリ構造、データモデル、API 仕様）を統合する。
-- システム全体の構造を Mermaid 図で視覚化する。
-- 採用したアーキテクチャパターン（レイヤード、クリーンアーキテクチャなど）を明確化する。
-- 重要なアーキテクチャ決定（ADR: Architecture Decision Record）を記録する。
-
-## 前提
-
-- 以下が作成されていること:
-  - `docs/project/04-design/01-tech-stack.md`
-  - `docs/project/04-design/02-repository-structure.md`
-  - `docs/project/04-design/05-data-model.md`
-  - `docs/project/04-design/06-api-spec.md`
-- `docs/project/04-design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-上記 4 ドキュメントを読み込む。不足があれば対応スキル（`/a-007`, `/a-008`, `/a-011`, `/a-012`）の実行を促す。
-
-### 2. テンプレートの準備
-
-このスキルの配置ディレクトリ（`skills/a-013-define-architecture/`）を起点に、相対パス `../../templates/project/04-design/07-architecture.md` を Read で読み込み、その内容を `docs/project/04-design/07-architecture.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
-
-### 3. アーキテクチャの提案
-
-技術スタックとリポジトリ構造からシステムの主要コンポーネント（クライアント、API、DB、外部サービス）を抽出し、全体図の構成案を提示する。
-
-- 「[Web] -> [API Server] -> [DB]」
-- 「[API Server] -> [External Service]」
-
-### 4. 詳細定義（インタビュー）
-
-#### 4.1 システムアーキテクチャ図
-
-コンポーネント間の接続、プロトコル（HTTP/gRPC）、データフロー、スケーラビリティ構成（LB、Replica）を Mermaid 図で表現する。記述例は [examples/architecture-templates.md](examples/architecture-templates.md#システムアーキテクチャ図mermaid) を参照。
-
-#### 4.2 アーキテクチャパターン
-
-採用パターン（レイヤード、クリーン、マイクロサービス等）と選定理由を明確にする。選定ガイドは [examples/architecture-templates.md](examples/architecture-templates.md#アーキテクチャパターン選定ガイド) を参照。
-
-#### 4.3 ADR (Architecture Decision Records)
-
-重要な技術的決定（DB 選定、認証方式、フレームワーク選定など）を背景・代替案・決定理由・影響の形で記録する。テンプレートは [examples/architecture-templates.md](examples/architecture-templates.md#adrarchitecture-decision-recordテンプレート) を参照。ADR 記録の基準は [reference/structure-check.md](reference/structure-check.md#adr-記録の基準) を参照。
-
-### 5. ドキュメント作成
-
-`docs/project/04-design/07-architecture.md` に以下を記入する:
-
-- システムアーキテクチャ図（Mermaid）
-- 採用アーキテクチャパターンの説明
-- ADR 一覧
-
-### 6. 構造チェック
-
-```bash
-grep "\`\`\`mermaid" docs/project/04-design/07-architecture.md \
-  && grep "## 採用アーキテクチャパターン" docs/project/04-design/07-architecture.md \
-  && grep "## ADR" docs/project/04-design/07-architecture.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/project/04-design/07-architecture.md
-git commit -m "docs: アーキテクチャ設計の定義"
-```
-
-## 完了条件
-
-- `docs/project/04-design/07-architecture.md` が作成されている。
-- システム全体の構成要素と関係性が可視化されている。
-- 技術選定の背景（ADR）が文書化され、将来の参照用に残されている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **アーキテクチャが複雑すぎる**: 「コンポーネント数が多すぎます。概要図と詳細図に分割するか、主要フローに絞って図示することを検討しましょう。」
-- **決定理由が不明確**: 「[技術名] の選定理由が曖昧です。後で振り返れるよう、比較検討した代替案も含めて ADR に記録しましょう。」
-
-## 参考
-
-- [examples/architecture-templates.md](examples/architecture-templates.md) — システム全体図、冗長化構成、パターン選定ガイド、ADR テンプレート、ADR の典型例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、ADR 記録基準
+---
+name: a-013-define-architecture
+description: 技術スタック・リポジトリ構造・データモデル・API 仕様を統合し、システムアーキテクチャと ADR を定義する。各設計ドキュメント確定後、全体像と意思決定を文書化する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineArchitecture (a-013)
+
+## 目的
+
+- これまでに定義された設計（技術スタック、リポジトリ構造、データモデル、API 仕様）を統合する。
+- システム全体の構造を Mermaid 図で視覚化する。
+- 採用したアーキテクチャパターン（レイヤード、クリーンアーキテクチャなど）を明確化する。
+- 重要なアーキテクチャ決定（ADR: Architecture Decision Record）を記録する。
+
+## 前提
+
+- 以下が作成されていること:
+  - `docs/project/04-design/01-tech-stack.md`
+  - `docs/project/04-design/02-repository-structure.md`
+  - `docs/project/04-design/05-data-model.md`
+  - `docs/project/04-design/06-api-spec.md`
+- `docs/project/04-design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+上記 4 ドキュメントを読み込む。不足があれば対応スキル（`/a-007`, `/a-008`, `/a-011`, `/a-012`）の実行を促す。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-013-define-architecture/`）を起点に、相対パス `../../templates/project/04-design/07-architecture.md` を Read で読み込み、その内容を `docs/project/04-design/07-architecture.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. アーキテクチャの提案
+
+技術スタックとリポジトリ構造からシステムの主要コンポーネント（クライアント、API、DB、外部サービス）を抽出し、全体図の構成案を提示する。
+
+- 「[Web] -> [API Server] -> [DB]」
+- 「[API Server] -> [External Service]」
+
+### 4. 詳細定義（インタビュー）
+
+#### 4.1 システムアーキテクチャ図
+
+コンポーネント間の接続、プロトコル（HTTP/gRPC）、データフロー、スケーラビリティ構成（LB、Replica）を Mermaid 図で表現する。記述例は [examples/architecture-templates.md](examples/architecture-templates.md#システムアーキテクチャ図mermaid) を参照。
+
+#### 4.2 アーキテクチャパターン
+
+採用パターン（レイヤード、クリーン、マイクロサービス等）と選定理由を明確にする。選定ガイドは [examples/architecture-templates.md](examples/architecture-templates.md#アーキテクチャパターン選定ガイド) を参照。
+
+#### 4.3 ADR (Architecture Decision Records)
+
+重要な技術的決定（DB 選定、認証方式、フレームワーク選定など）を背景・代替案・決定理由・影響の形で記録する。テンプレートは [examples/architecture-templates.md](examples/architecture-templates.md#adrarchitecture-decision-recordテンプレート) を参照。ADR 記録の基準は [reference/structure-check.md](reference/structure-check.md#adr-記録の基準) を参照。
+
+### 5. ドキュメント作成
+
+`docs/project/04-design/07-architecture.md` に以下を記入する:
+
+- システムアーキテクチャ図（Mermaid）
+- 採用アーキテクチャパターンの説明
+- ADR 一覧
+
+### 6. 構造チェック
+
+```bash
+grep "\`\`\`mermaid" docs/project/04-design/07-architecture.md \
+  && grep "## 採用アーキテクチャパターン" docs/project/04-design/07-architecture.md \
+  && grep "## ADR" docs/project/04-design/07-architecture.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/07-architecture.md
+git commit -m "docs: アーキテクチャ設計の定義"
+```
+
+## 完了条件
+
+- `docs/project/04-design/07-architecture.md` が作成されている。
+- システム全体の構成要素と関係性が可視化されている。
+- 技術選定の背景（ADR）が文書化され、将来の参照用に残されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **アーキテクチャが複雑すぎる**: 「コンポーネント数が多すぎます。概要図と詳細図に分割するか、主要フローに絞って図示することを検討しましょう。」
+- **決定理由が不明確**: 「[技術名] の選定理由が曖昧です。後で振り返れるよう、比較検討した代替案も含めて ADR に記録しましょう。」
+
+## 参考
+
+- [examples/architecture-templates.md](examples/architecture-templates.md) — システム全体図、冗長化構成、パターン選定ガイド、ADR テンプレート、ADR の典型例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、ADR 記録基準