yodogawa 2.1.3 → 2.3.0

package/skills/a-008-define-repository-structure/SKILL.md

@@ -1,96 +1,96 @@
----
-name: a-008-define-repository-structure
-description: 技術スタックに基づきディレクトリ構造・アーキテクチャパターン・命名規則を定義する。技術選定後、コードの配置方針を決める際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineRepositoryStructure (a-008)
-
-## 目的
-
-- 決定された技術スタックに基づいて、最適なリポジトリ構造を定義する。
-- アーキテクチャパターン（レイヤード、機能ベース、クリーンアーキテクチャなど）を選定する。
-- ディレクトリの責務、命名規則、依存関係ルールを明確化する。
-
-## 前提
-
-- `docs/project/04-design/01-tech-stack.md` が作成されていること（`/a-007-define-tech-stack` 実行済み）。
-- `docs/project/03-domain/01-domain-model.md` が作成されていること（推奨）。
-- `docs/project/04-design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-```bash
-ls -la docs/project/04-design/01-tech-stack.md 2>/dev/null || echo "ファイルが存在しません"
-```
-
-`01-tech-stack.md` を読み込み、技術スタックを把握する。
-
-### 2. テンプレートの準備
-
-このスキルの配置ディレクトリ（`skills/a-008-define-repository-structure/`）を起点に、相対パス `../../templates/project/04-design/02-repository-structure.md` を Read で読み込み、その内容を `docs/project/04-design/02-repository-structure.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
-
-### 3. アーキテクチャパターンの提案
-
-技術スタックと要件に基づき、最適なパターンを提案する。選定ガイドは [reference/structure-check.md](reference/structure-check.md#アーキテクチャパターン選定ガイド) を参照。
-
-- レイヤード / 機能ベース / クリーンアーキテクチャ / Atomic Design / FSD
-- 「推奨: [パターン名]」「理由: [技術スタックとの適合性、保守性]」
-
-### 4. ディレクトリ構造の詳細定義
-
-フィードバックを受けて以下を確定する。具体的なツリー例は [examples/structure-templates.md](examples/structure-templates.md#アーキテクチャパターン別の構成例) を参照。
-
-- **ディレクトリ構成**: ソースルート（`src/` vs `app/`）、テスト配置、機能モジュール構成
-- **命名規則**: ファイル名（PascalCase / camelCase / kebab-case）、識別子規則
-- **依存関係ルール**: 上位層から下位層への依存のみ等
-- **コロケーション戦略**: 関連ファイルをまとめるか分離するか
-
-命名規則と依存ルールの具体例は [examples/structure-templates.md](examples/structure-templates.md#命名規則のサンプル) を参照。
-
-### 5. ドキュメント作成
-
-`docs/project/04-design/02-repository-structure.md` に以下を記入する:
-
-- ディレクトリツリー図（`tree` 形式）
-- 各ディレクトリの役割説明
-- 採用したアーキテクチャパターンと理由
-- 命名規則と依存ルール
-
-### 6. 構造チェック
-
-```bash
-grep "project-root/" docs/project/04-design/02-repository-structure.md \
-  && grep "## アーキテクチャパターン" docs/project/04-design/02-repository-structure.md \
-  && grep "## 命名規則" docs/project/04-design/02-repository-structure.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/project/04-design/02-repository-structure.md
-git commit -m "docs: リポジトリ構造とアーキテクチャ定義の作成"
-```
-
-## 完了条件
-
-- `docs/project/04-design/02-repository-structure.md` が作成されている。
-- プロジェクトのディレクトリ構造が明確に定義されている。
-- チーム開発に必要なルール（命名、配置、依存）が文書化されている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **技術スタックと構造の不一致**: 「選択されたフレームワーク（[名前]）の標準構成と異なります。標準に従うか、独自構造を採用するか確認しましょう。」
-- **構造が過度に複雑**: 「初期段階では複雑すぎる可能性があります。まずはフラットな構成から始め、必要に応じて分割することを推奨します。」
-
-## 参考
-
-- [examples/structure-templates.md](examples/structure-templates.md) — パターン別ディレクトリツリー例、命名規則、依存関係ルール、コロケーション戦略
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、パターン選定ガイド、レビュー質問
+---
+name: a-008-define-repository-structure
+description: 技術スタックに基づきディレクトリ構造・アーキテクチャパターン・命名規則を定義する。技術選定後、コードの配置方針を決める際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineRepositoryStructure (a-008)
+
+## 目的
+
+- 決定された技術スタックに基づいて、最適なリポジトリ構造を定義する。
+- アーキテクチャパターン（レイヤード、機能ベース、クリーンアーキテクチャなど）を選定する。
+- ディレクトリの責務、命名規則、依存関係ルールを明確化する。
+
+## 前提
+
+- `docs/project/04-design/01-tech-stack.md` が作成されていること（`/a-007-define-tech-stack` 実行済み）。
+- `docs/project/03-domain/01-domain-sketch.md` が作成されていること（推奨。Full DDD 採用時は `01-domain-model.md`）。
+- `docs/project/04-design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+```bash
+ls -la docs/project/04-design/01-tech-stack.md 2>/dev/null || echo "ファイルが存在しません"
+```
+
+`01-tech-stack.md` を読み込み、技術スタックを把握する。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-008-define-repository-structure/`）を起点に、相対パス `../../templates/project/04-design/02-repository-structure.md` を Read で読み込み、その内容を `docs/project/04-design/02-repository-structure.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. アーキテクチャパターンの提案
+
+技術スタックと要件に基づき、最適なパターンを提案する。選定ガイドは [reference/structure-check.md](reference/structure-check.md#アーキテクチャパターン選定ガイド) を参照。
+
+- レイヤード / 機能ベース / クリーンアーキテクチャ / Atomic Design / FSD
+- 「推奨: [パターン名]」「理由: [技術スタックとの適合性、保守性]」
+
+### 4. ディレクトリ構造の詳細定義
+
+フィードバックを受けて以下を確定する。具体的なツリー例は [examples/structure-templates.md](examples/structure-templates.md#アーキテクチャパターン別の構成例) を参照。
+
+- **ディレクトリ構成**: ソースルート（`src/` vs `app/`）、テスト配置、機能モジュール構成
+- **命名規則**: ファイル名（PascalCase / camelCase / kebab-case）、識別子規則
+- **依存関係ルール**: 上位層から下位層への依存のみ等
+- **コロケーション戦略**: 関連ファイルをまとめるか分離するか
+
+命名規則と依存ルールの具体例は [examples/structure-templates.md](examples/structure-templates.md#命名規則のサンプル) を参照。
+
+### 5. ドキュメント作成
+
+`docs/project/04-design/02-repository-structure.md` に以下を記入する:
+
+- ディレクトリツリー図（`tree` 形式）
+- 各ディレクトリの役割説明
+- 採用したアーキテクチャパターンと理由
+- 命名規則と依存ルール
+
+### 6. 構造チェック
+
+```bash
+grep "project-root/" docs/project/04-design/02-repository-structure.md \
+  && grep "## アーキテクチャパターン" docs/project/04-design/02-repository-structure.md \
+  && grep "## 命名規則" docs/project/04-design/02-repository-structure.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/02-repository-structure.md
+git commit -m "docs: リポジトリ構造とアーキテクチャ定義の作成"
+```
+
+## 完了条件
+
+- `docs/project/04-design/02-repository-structure.md` が作成されている。
+- プロジェクトのディレクトリ構造が明確に定義されている。
+- チーム開発に必要なルール（命名、配置、依存）が文書化されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **技術スタックと構造の不一致**: 「選択されたフレームワーク（[名前]）の標準構成と異なります。標準に従うか、独自構造を採用するか確認しましょう。」
+- **構造が過度に複雑**: 「初期段階では複雑すぎる可能性があります。まずはフラットな構成から始め、必要に応じて分割することを推奨します。」
+
+## 参考
+
+- [examples/structure-templates.md](examples/structure-templates.md) — パターン別ディレクトリツリー例、命名規則、依存関係ルール、コロケーション戦略
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、パターン選定ガイド、レビュー質問

package/skills/a-009-define-screen-design/SKILL.md

@@ -1,103 +1,103 @@
----
-name: a-009-define-screen-design
-description: ユーザーストーリーとシナリオから画面一覧・遷移フロー・レスポンシブポリシーを定義する。技術選定後、UI/UX 設計を開始する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineScreenDesign (a-009)
-
-## 目的
-
-- ユーザーストーリーとシナリオを基に、必要な画面を網羅的に抽出する。
-- 各画面の役割、アクセス権限、考慮すべき状態（Empty State 含む）を明確化する。
-- 画面遷移フローを Mermaid 図で可視化し、ユーザーの導線を明確にする。
-- レスポンシブデザインポリシー（ブレークポイント、デバイス対応方針）を定義する。
-
-## 前提
-
-- `docs/project/01-requirements/05-user-stories.md` が作成されていること。
-- `docs/project/02-behavior/01-scenarios.md` が作成されていること。
-- `docs/project/04-design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-以下を読み込む:
-
-- `docs/project/01-requirements/05-user-stories.md`
-- `docs/project/02-behavior/01-scenarios.md`
-- `docs/project/04-design/01-tech-stack.md`（存在する場合）
-
-不足があれば対応スキル（`/a-002`, `/a-003`, `/a-007`）の実行を促す。
-
-### 2. テンプレートの準備
-
-このスキルの配置ディレクトリ（`skills/a-009-define-screen-design/`）を起点に、相対パス `../../templates/project/04-design/03-screen-design.md` を Read で読み込み、その内容を `docs/project/04-design/03-screen-design.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
-
-### 3. 画面の抽出と提案
-
-- シナリオの Given/When/Then から必要な画面を抽出。
-- 標準画面（ログイン、404、設定等）を追加提案。
-- 「[画面名] (役割: [説明])」の形式で一覧化。
-
-画面一覧のテーブル例は [examples/screen-templates.md](examples/screen-templates.md#画面一覧テーブル) を参照。
-
-### 4. 詳細定義と遷移フロー
-
-#### 4.1 各画面の詳細
-
-画面 ID、名称、URL パス、アクセス権限、重要な状態（Empty / Loading / Error / Success）。状態観点は [examples/screen-templates.md](examples/screen-templates.md#重要な状態の観点) を参照。
-
-#### 4.2 画面遷移フロー
-
-主要なユーザーフロー（認証、メイン機能、エラー）を Mermaid 図で表現する。デッドエンドがないか確認する。記述例は [examples/screen-templates.md](examples/screen-templates.md#画面遷移図mermaid) を参照。
-
-### 5. レスポンシブデザインポリシー
-
-技術スタック（Tailwind 等）に合わせたブレークポイントと方針を定義する。ブレークポイント表と方針例は [examples/screen-templates.md](examples/screen-templates.md#レスポンシブデザインポリシー) を参照。
-
-### 6. ドキュメント作成
-
-`docs/project/04-design/03-screen-design.md` に以下を記入する:
-
-- 画面一覧テーブル
-- 画面遷移図（Mermaid）
-- レスポンシブデザインポリシー
-
-### 7. 構造チェック
-
-```bash
-grep "## 画面一覧" docs/project/04-design/03-screen-design.md \
-  && grep "\`\`\`mermaid" docs/project/04-design/03-screen-design.md \
-  && grep "## レスポンシブデザインポリシー" docs/project/04-design/03-screen-design.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 8. Git への追加（任意）
-
-```bash
-git add docs/project/04-design/03-screen-design.md
-git commit -m "docs: 画面設計ドキュメントの作成"
-```
-
-## 完了条件
-
-- `docs/project/04-design/03-screen-design.md` が作成されている。
-- 全画面のリストと役割が定義されている。
-- 画面遷移が可視化されている。
-- レスポンシブ対応方針が明確になっている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **シナリオ不足で画面が特定できない**: 「`/a-003-create-scenarios` に戻ってユーザーフローを明確にしましょう。」
-- **画面数が多すぎる**: 「初期リリースには多すぎる可能性があります。MVP に必要な画面に絞り込みませんか？」
-
-## 参考
-
-- [examples/screen-templates.md](examples/screen-templates.md) — 画面一覧テーブル、状態観点、Mermaid 遷移図、レスポンシブ方針
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例
+---
+name: a-009-define-screen-design
+description: ユーザーストーリーとシナリオから画面一覧・遷移フロー・レスポンシブポリシーを定義する。技術選定後、UI/UX 設計を開始する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineScreenDesign (a-009)
+
+## 目的
+
+- ユーザーストーリーとシナリオを基に、必要な画面を網羅的に抽出する。
+- 各画面の役割、アクセス権限、考慮すべき状態（Empty State 含む）を明確化する。
+- 画面遷移フローを Mermaid 図で可視化し、ユーザーの導線を明確にする。
+- レスポンシブデザインポリシー（ブレークポイント、デバイス対応方針）を定義する。
+
+## 前提
+
+- `docs/project/01-requirements/05-user-stories.md` が作成されていること。
+- `docs/project/02-behavior/01-core-scenarios.md` が作成されていること。
+- `docs/project/04-design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+以下を読み込む:
+
+- `docs/project/01-requirements/05-user-stories.md`
+- `docs/project/02-behavior/01-core-scenarios.md`
+- `docs/project/04-design/01-tech-stack.md`（存在する場合）
+
+不足があれば対応スキル（`/a-002`, `/a-003`, `/a-007`）の実行を促す。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-009-define-screen-design/`）を起点に、相対パス `../../templates/project/04-design/03-screen-design.md` を Read で読み込み、その内容を `docs/project/04-design/03-screen-design.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. 画面の抽出と提案
+
+- シナリオの Given/When/Then から必要な画面を抽出。
+- 標準画面（ログイン、404、設定等）を追加提案。
+- 「[画面名] (役割: [説明])」の形式で一覧化。
+
+画面一覧のテーブル例は [examples/screen-templates.md](examples/screen-templates.md#画面一覧テーブル) を参照。
+
+### 4. 詳細定義と遷移フロー
+
+#### 4.1 各画面の詳細
+
+画面 ID、名称、URL パス、アクセス権限、重要な状態（Empty / Loading / Error / Success）。状態観点は [examples/screen-templates.md](examples/screen-templates.md#重要な状態の観点) を参照。
+
+#### 4.2 画面遷移フロー
+
+主要なユーザーフロー（認証、メイン機能、エラー）を Mermaid 図で表現する。デッドエンドがないか確認する。記述例は [examples/screen-templates.md](examples/screen-templates.md#画面遷移図mermaid) を参照。
+
+### 5. レスポンシブデザインポリシー
+
+技術スタック（Tailwind 等）に合わせたブレークポイントと方針を定義する。ブレークポイント表と方針例は [examples/screen-templates.md](examples/screen-templates.md#レスポンシブデザインポリシー) を参照。
+
+### 6. ドキュメント作成
+
+`docs/project/04-design/03-screen-design.md` に以下を記入する:
+
+- 画面一覧テーブル
+- 画面遷移図（Mermaid）
+- レスポンシブデザインポリシー
+
+### 7. 構造チェック
+
+```bash
+grep "## 画面一覧" docs/project/04-design/03-screen-design.md \
+  && grep "\`\`\`mermaid" docs/project/04-design/03-screen-design.md \
+  && grep "## レスポンシブデザインポリシー" docs/project/04-design/03-screen-design.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 8. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/03-screen-design.md
+git commit -m "docs: 画面設計ドキュメントの作成"
+```
+
+## 完了条件
+
+- `docs/project/04-design/03-screen-design.md` が作成されている。
+- 全画面のリストと役割が定義されている。
+- 画面遷移が可視化されている。
+- レスポンシブ対応方針が明確になっている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **シナリオ不足で画面が特定できない**: 「`/a-003-create-scenarios` に戻ってユーザーフローを明確にしましょう。」
+- **画面数が多すぎる**: 「初期リリースには多すぎる可能性があります。MVP に必要な画面に絞り込みませんか？」
+
+## 参考
+
+- [examples/screen-templates.md](examples/screen-templates.md) — 画面一覧テーブル、状態観点、Mermaid 遷移図、レスポンシブ方針
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例