yodogawa 2.0.0 → 2.1.0

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

@@ -1,129 +1,99 @@
----
-name: a-008-define-repository-structure
-description: 技術スタックに基づいてプロジェクトのディレクトリ構造、アーキテクチャパターン、命名規則を定義するワークフロー
----
-
-# DefineRepositoryStructure (a-008)
-
-## 目的
-
-- 決定された技術スタックに基づいて、最適なリポジトリ構造を定義する。
-- アーキテクチャパターン（レイヤード、機能ベース、クリーンアーキテクチャなど）を選定する。
-- ディレクトリの責務、命名規則、依存関係ルールを明確化する。
-
-## 前提
-
-- `docs/project/design/01-tech-stack.md` が作成されていること（先に `DefineTechStack` (a-007) を実行）。
-- `docs/project/domain/01-domain-model.md` が作成されていること（推奨）。
-- `docs/project/design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-- `docs/project/design/01-tech-stack.md` を読み込み、技術スタックを確認する。
-
-  ```bash
-  ls -la docs/project/design/01-tech-stack.md 2>/dev/null || echo "ファイルが存在しません"
-  ```
-
-- 存在しない場合：ユーザーに通知し、`DefineTechStack` (a-007) を実行するよう促す。
-
-### 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/02-repository-structure.md" "docs/project/design/02-repository-structure.md"
-  ```
-
-### 3. アーキテクチャパターンの提案
-
-- 技術スタックと要件に基づき、最適なアーキテクチャパターンを提案する。
-  - **レイヤードアーキテクチャ**: 一般的なバックエンド（NestJS, Django等）
-  - **機能ベース (Feature-based)**: フロントエンド、モジュラーモノリス
-  - **クリーンアーキテクチャ**: 複雑なドメインロジックを持つ場合
-  - **Atomic Design / FSD**: フロントエンド特化
-
-- ユーザーに提示：
-  - 「以下のアーキテクチャパターンを推奨します：[パターン名]」
-  - 「理由：[技術スタックとの適合性、保守性など]」
-
-### 4. ディレクトリ構造の詳細定義
-
-ユーザーからのフィードバックを受け、詳細を決定する。
-
-#### 4.1 ディレクトリ構成
-
-- ソースコードのルート（`src/` vs `app/`）
-- テストコードの配置（`tests/` vs コロケーション）
-- 機能モジュールの構成（`features/`, `components/`, `lib/` 等）
-
-#### 4.2 命名規則とルール
-
-- ファイル名（PascalCase, camelCase, kebab-case）
-- 依存関係ルール（上位層から下位層への依存のみ許可など）
-- コロケーション戦略（関連ファイルをまとめるか分離するか）
-
-### 5. ドキュメント作成
-
-- `docs/project/design/02-repository-structure.md` に決定事項を記入する。
-- **必須項目**:
-  - ディレクトリツリー図（`tree`形式）
-  - 各ディレクトリの役割説明
-  - 採用したアーキテクチャパターンと理由
-  - 命名規則と依存ルール
-
-### 6. 完了条件と構造の確認
-
-- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
-
-  1. **構造確認**:
-
-     ```bash
-     # ディレクトリ構造図の確認
-     grep "project-root/" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Directory tree"
-     # アーキテクチャパターンセクションの確認
-     grep "## アーキテクチャパターン" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Architecture section"
-     # 命名規則セクションの確認
-     grep "## 命名規則" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Naming convention section"
-     ```
-
-  2. **チェックリスト**:
-     - [ ] `docs/project/design/02-repository-structure.md` が作成されている
-     - [ ] ディレクトリツリーが技術スタックと整合している
-     - [ ] 各ディレクトリの責務が定義されている
-
-### 7. Git への追加（オプション）
-
-- ユーザーに確認：「作成したリポジトリ構造ドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/design/02-repository-structure.md
-  git status
-  ```
-
-- 推奨コミットメッセージ：
-
-  ```
-  docs: リポジトリ構造とアーキテクチャ定義の作成
-
-  - ディレクトリ構成、命名規則、依存関係ルールを定義
-  - 採用アーキテクチャパターン: [パターン名]
-  ```
-
-## 完了条件
-
-- `docs/project/design/02-repository-structure.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/design/01-tech-stack.md` が作成されていること（`/a-007-define-tech-stack` 実行済み）。
+- `docs/project/domain/01-domain-model.md` が作成されていること（推奨）。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+```bash
+ls -la docs/project/design/01-tech-stack.md 2>/dev/null || echo "ファイルが存在しません"
+```
+
+`01-tech-stack.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/02-repository-structure.md" "docs/project/design/02-repository-structure.md"
+```
+
+### 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/design/02-repository-structure.md` に以下を記入する:
+
+- ディレクトリツリー図（`tree` 形式）
+- 各ディレクトリの役割説明
+- 採用したアーキテクチャパターンと理由
+- 命名規則と依存ルール
+
+### 6. 構造チェック
+
+```bash
+grep "project-root/" docs/project/design/02-repository-structure.md \
+  && grep "## アーキテクチャパターン" docs/project/design/02-repository-structure.md \
+  && grep "## 命名規則" docs/project/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/design/02-repository-structure.md
+git commit -m "docs: リポジトリ構造とアーキテクチャ定義の作成"
+```
+
+## 完了条件
+
+- `docs/project/design/02-repository-structure.md` が作成されている。
+- プロジェクトのディレクトリ構造が明確に定義されている。
+- チーム開発に必要なルール（命名、配置、依存）が文書化されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **技術スタックと構造の不一致**: 「選択されたフレームワーク（[名前]）の標準構成と異なります。標準に従うか、独自構造を採用するか確認しましょう。」
+- **構造が過度に複雑**: 「初期段階では複雑すぎる可能性があります。まずはフラットな構成から始め、必要に応じて分割することを推奨します。」
+
+## 参考
+
+- [examples/structure-templates.md](examples/structure-templates.md) — パターン別ディレクトリツリー例、命名規則、依存関係ルール、コロケーション戦略
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、パターン選定ガイド、レビュー質問

package/skills/a-008-define-repository-structure/examples/structure-templates.md

@@ -0,0 +1,108 @@
+# ディレクトリ構造と命名規則のテンプレート
+
+SKILL.md 手順3〜5 で使用する構造例と命名規則のサンプル。
+
+## アーキテクチャパターン別の構成例
+
+### レイヤードアーキテクチャ（NestJS 等）
+
+```text
+project-root/
+├── src/
+│   ├── controllers/      # プレゼンテーション層
+│   ├── services/         # アプリケーション層
+│   ├── repositories/     # インフラ層
+│   ├── domain/           # ドメイン層（Entity, VO）
+│   └── main.ts
+├── tests/
+│   ├── unit/
+│   └── e2e/
+└── package.json
+```
+
+### 機能ベース（Feature-based / Next.js App Router 等）
+
+```text
+project-root/
+├── app/
+│   ├── (auth)/
+│   ├── dashboard/
+│   └── layout.tsx
+├── features/
+│   ├── user/
+│   │   ├── components/
+│   │   ├── hooks/
+│   │   └── api.ts
+│   └── order/
+├── components/           # 共有 UI
+├── lib/                  # 汎用ユーティリティ
+└── package.json
+```
+
+### クリーンアーキテクチャ
+
+```text
+project-root/
+├── src/
+│   ├── domain/
+│   │   ├── entities/
+│   │   └── usecases/
+│   ├── application/      # Use Case interactors
+│   ├── interface/        # Controller, Presenter
+│   └── infrastructure/   # DB, 外部 API
+└── tests/
+```
+
+### Feature-Sliced Design（FSD）/ Atomic Design
+
+```text
+src/
+├── app/
+├── pages/
+├── widgets/
+├── features/
+├── entities/
+└── shared/
+```
+
+## 命名規則のサンプル
+
+### ファイル名
+
+| 対象 | 規則 | 例 |
+|:--|:--|:--|
+| React Component | PascalCase | `UserCard.tsx` |
+| Hook | camelCase (`use` prefix) | `useAuthSession.ts` |
+| Utility | camelCase | `formatDate.ts` |
+| 定数ファイル | SCREAMING_SNAKE or kebab | `API_ENDPOINTS.ts` / `api-endpoints.ts` |
+| Route (Next.js) | kebab-case | `user-settings/page.tsx` |
+| Test | `*.test.ts` / `*.spec.ts` | `UserCard.test.tsx` |
+
+### 識別子
+
+- 変数/関数: camelCase
+- 型/クラス/コンポーネント: PascalCase
+- 定数: SCREAMING_SNAKE_CASE
+- ディレクトリ: kebab-case
+
+## 依存関係ルールの例
+
+- 上位層から下位層への依存のみ許可（Presentation → Application → Domain → Infrastructure）
+- ドメイン層は他のいかなる層にも依存しない
+- features/ 間の直接参照は禁止。共有ロジックは shared/ または entities/ に配置
+- インフラ層は interface 経由でドメインに注入する（DIP）
+
+## コロケーション戦略
+
+- 関連ファイルを機能単位でまとめる（components + hooks + styles を同階層）
+- テストは対象ファイルと同階層（`Foo.ts` / `Foo.test.ts`）
+- 大規模化時は features/ への移行を検討
+
+## コミットメッセージ例
+
+```text
+docs: リポジトリ構造とアーキテクチャ定義の作成
+
+- ディレクトリ構成、命名規則、依存関係ルールを定義
+- 採用アーキテクチャパターン: [パターン名]
+```

package/skills/a-008-define-repository-structure/reference/structure-check.md

@@ -0,0 +1,55 @@
+# 構造チェックとレビュー観点
+
+SKILL.md 手順6〜7 で使う確認コマンドとレビュー観点。
+
+## セクション存在確認
+
+```bash
+# ディレクトリ構造図の確認
+grep "project-root/" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Directory tree"
+# アーキテクチャパターンセクションの確認
+grep "## アーキテクチャパターン" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Architecture section"
+# 命名規則セクションの確認
+grep "## 命名規則" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Naming convention section"
+```
+
+## チェックリスト
+
+- [ ] `docs/project/design/02-repository-structure.md` が作成されている
+- [ ] ディレクトリツリーが技術スタックと整合している
+- [ ] 各ディレクトリの責務が定義されている
+- [ ] 採用アーキテクチャパターンの理由が記載されている
+- [ ] 命名規則（ファイル名・識別子）が定義されている
+- [ ] 依存関係ルールが明示されている
+- [ ] テスト配置方針（コロケーション or 分離）が定まっている
+
+## アーキテクチャパターン選定ガイド
+
+| パターン | 適合するケース |
+|:--|:--|
+| レイヤード | 一般的なバックエンド（NestJS, Django 等） |
+| 機能ベース | フロントエンド、モジュラーモノリス |
+| クリーンアーキテクチャ | 複雑なドメインロジックを持つ場合 |
+| Atomic Design / FSD | フロントエンド特化、大規模 UI |
+
+## レビュー確認質問
+
+- 「フレームワーク標準の構成と整合していますか？」
+- 「チームが迷わず配置できるレベルの具体性がありますか？」
+- 「将来の機能追加で破綻しない柔軟性がありますか？」
+
+## Git への追加（任意）
+
+```bash
+git add docs/project/design/02-repository-structure.md
+git status
+```
+
+推奨コミットメッセージ:
+
+```text
+docs: リポジトリ構造とアーキテクチャ定義の作成
+
+- ディレクトリ構成、命名規則、依存関係ルールを定義
+- 採用アーキテクチャパターン: [パターン名]
+```

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

@@ -1,130 +1,106 @@
----
-name: a-009-define-screen-design
-description: ユーザーストーリーとシナリオから画面一覧を抽出し、画面遷移フローとレスポンシブデザインポリシーを定義するワークフロー
----
-
-# DefineScreenDesign (a-009)
-
-## 目的
-
-- ユーザーストーリーとシナリオを基に、必要な画面を網羅的に抽出する。
-- 各画面の役割、アクセス権限、考慮すべき状態（Empty State含む）を明確化する。
-- 画面遷移フローをMermaid図で可視化し、ユーザーの導線を明確にする。
-- レスポンシブデザインポリシー（ブレークポイント、デバイス対応方針）を定義する。
-
-## 前提
-
-- `docs/project/requirements/05-user-stories.md` が作成されていること。
-- `docs/project/behavior/01-scenarios.md` が作成されていること。
-- `docs/project/design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-- 必要なドキュメントを読み込む：
-  - `docs/project/requirements/05-user-stories.md`
-  - `docs/project/behavior/01-scenarios.md`
-  - `docs/project/design/01-tech-stack.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/03-screen-design.md" "docs/project/design/03-screen-design.md"
-  ```
-
-### 3. 画面の抽出と提案
-
-- シナリオのGiven/When/Thenステップから、必要な画面を抽出する。
-- 標準的な画面（ログイン、404エラー、設定など）を追加提案する。
-- **画面リスト案を提示**:
-  - 「以下の画面が必要と考えられます：」
-  - 「[画面名] (役割: [説明])」
-
-### 4. 詳細定義と遷移フロー
-
-ユーザーからのフィードバックを受け、以下を定義する。
-
-#### 4.1 各画面の詳細
-
-- 画面ID、名称、URLパス
-- アクセス権限（誰が見れるか）
-- **重要な状態**: 初回訪問(Empty State)、ロード中、エラー時など
-
-#### 4.2 画面遷移フロー
-
-- 主要なユーザーフロー（認証、メイン機能、エラー）をMermaid図で表現する。
-- デッドエンド（戻れない画面）がないか確認する。
-
-### 5. レスポンシブデザインポリシー
-
-- 技術スタック（Tailwind等）に合わせたブレークポイントを定義する。
-- モバイルファーストかデスクトップファーストか、方針を決定する。
-- デバイスごとのレイアウトパターン（ハンバーガーメニュー、ドロワー等）を定義する。
-
-### 6. ドキュメント作成
-
-- `docs/project/design/03-screen-design.md` に決定事項を記入する。
-- **必須項目**:
-  - 画面一覧テーブル
-  - 画面遷移図 (Mermaid)
-  - レスポンシブデザインポリシー
-
-### 7. 完了条件と構造の確認
-
-- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
-
-  1. **構造確認**:
-
-     ```bash
-     # 画面一覧セクションの確認
-     grep "## 画面一覧" docs/project/design/03-screen-design.md && echo "OK" || echo "MISSING: Screen list"
-     # 画面遷移図の確認
-     grep "\`\`\`mermaid" docs/project/design/03-screen-design.md && echo "OK" || echo "MISSING: Flowchart"
-     # レスポンシブポリシーの確認
-     grep "## レスポンシブデザインポリシー" docs/project/design/03-screen-design.md && echo "OK" || echo "MISSING: Responsive policy"
-     ```
-
-  2. **チェックリスト**:
-     - [ ] `docs/project/design/03-screen-design.md` が作成されている
-     - [ ] 主要な画面がすべて網羅されている
-     - [ ] Empty Stateについて考慮されている
-
-### 8. Git への追加（オプション）
-
-- ユーザーに確認：「作成した画面設計ドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/design/03-screen-design.md
-  git status
-  ```
-
-- 推奨コミットメッセージ：
-
-  ```
-  docs: 画面設計ドキュメントの作成
-
-  - 画面一覧と遷移フロー(Mermaid)を追加
-  - レスポンシブデザインポリシーを定義
-  ```
-
-## 完了条件
-
-- `docs/project/design/03-screen-design.md` が作成されている。
-- 全画面のリストと役割が定義されている。
-- 画面遷移が可視化されている。
-- レスポンシブ対応方針が明確になっている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- シナリオ不足で画面が特定できない場合：
-  - 「シナリオが不足しています。`CreateScenarios` (a-003) に戻ってユーザーフローを明確にしましょう。」と提案する。
-- 画面数が多すぎる場合：
-  - 「初期リリースには多すぎる可能性があります。MVPに必要な画面に絞り込みませんか？」と提案する。
+---
+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/requirements/05-user-stories.md` が作成されていること。
+- `docs/project/behavior/01-scenarios.md` が作成されていること。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+以下を読み込む:
+
+- `docs/project/requirements/05-user-stories.md`
+- `docs/project/behavior/01-scenarios.md`
+- `docs/project/design/01-tech-stack.md`（存在する場合）
+
+不足があれば対応スキル（`/a-002`, `/a-003`, `/a-007`）の実行を促す。
+
+### 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/03-screen-design.md" "docs/project/design/03-screen-design.md"
+```
+
+### 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/design/03-screen-design.md` に以下を記入する:
+
+- 画面一覧テーブル
+- 画面遷移図（Mermaid）
+- レスポンシブデザインポリシー
+
+### 7. 構造チェック
+
+```bash
+grep "## 画面一覧" docs/project/design/03-screen-design.md \
+  && grep "\`\`\`mermaid" docs/project/design/03-screen-design.md \
+  && grep "## レスポンシブデザインポリシー" docs/project/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/design/03-screen-design.md
+git commit -m "docs: 画面設計ドキュメントの作成"
+```
+
+## 完了条件
+
+- `docs/project/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 追加例