yodogawa 2.1.3 → 2.2.0

package/skills/a-006-review-requirements-domain/examples/review-report-template.md

@@ -1,6 +1,6 @@
 # レビュー結果レポートテンプレート
 
-SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォーマット例。
+SKILL.md 手順4 で作成する `docs/project/REVIEW-REPORT-*.md` のフォーマット例。
 
 ## レポートフォーマット
 
@@ -22,10 +22,10 @@ SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 - **Error**: US-005 に対応するシナリオが見つかりません。
 - OK: 優先度 High のストーリーはすべてカバーされています。
 
-### 2. 機能要件・非機能要件
+### 2. MVP スコープ・クリティカル制約
 
 - **Warning**: 実装済み機能「決済」のシナリオが不足しています。
-- OK: パフォーマンス要件に対応する Read Model が定義されています。
+- OK: Product Brief のクリティカル制約「社内 SSO 必須」が MVP スコープ・ドメインに反映されています。
 
 ### 3. シナリオ ↔ ドメインモデル
 
@@ -34,13 +34,25 @@ SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 ### 4. ユビキタス言語
 
 - **Error**: 用語「ShippingAddress」がユビキタス言語一覧にありません。
-- **Warning**: 禁止用語「User Data」が `01-domain-model.md` で使用されています。
+- **Warning**: 禁止用語「User Data」が `01-domain-sketch.md` で使用されています。
+
+### 5. MVP 正当化 / 過剰作り込み（YAGNI）
+
+- **過剰作り込み候補**: Must 機能「実績バッジ」が課題・ペルソナ・成功指標のいずれにも trace しません。Not Now / Won't への変更を検討してください。
+- OK: その他の Must はすべて検証仮説・成功指標に紐づいています。
+- OK: Out of Scope（Won't）と矛盾する実装記述はありません。
+
+## PM Gate 判定
+
+**判定**: Go with caveats
+
+**根拠**: 整合性は良好。ただし Must「実績バッジ」が正当化されていないため、スコープから外すことを条件に実装着手可。
 
 ## 推奨アクション
 
-1. `/a-003-create-scenarios` で US-005 のシナリオを追加する。
-2. `/a-004-define-domain-model` で「在庫を引き当てる」コマンドを定義する。
-3. `01-domain-model.md` の「User Data」を「User Profile」に修正する。
+1. `02-mvp-scope.md` の「実績バッジ」を Won't に変更する（過剰作り込み）。
+2. `/a-003-create-scenarios` で US-005 のシナリオを追加する。
+3. `01-domain-sketch.md` の「User Data」を「User Profile」に修正する。
 ```
 
 ## 重大度記号の使い方
@@ -51,6 +63,14 @@ SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 | Warning | 軽微な不整合 | 計画的に修正 |
 | Error | 重大な不整合 | 実装前に必ず修正 |
 
+## PM Gate 判定の使い方
+
+| 判定 | 意味 | 次のアクション |
+|:--|:--|:--|
+| Go | 実装着手してよい | `AI_CONTEXT.md` を実装エージェントへ渡す |
+| Go with caveats | 条件付きで着手可 | caveat を明記し、合意の上で着手 |
+| No-Go | 重大課題あり | 実装前に該当ドキュメントを修正し再レビュー |
+
 ## コミットメッセージ例
 
 ```text

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

@@ -2,37 +2,53 @@
 
 SKILL.md 手順2 で実施する各チェック項目の詳細。自動検索（grep 等）と手動確認を組み合わせる。
 
-## 2.1 ユーザーストーリー ↔ シナリオ
+## 2.1 ユーザーストーリー ↔ Core Scenario
 
-- **カバレッジ**: すべての US-XXX に対応する SC-XXX が存在するか。
-- **整合性**: ストーリーの「価値」とシナリオの「結果（Then）」が一致しているか。
+- **カバレッジ**: MVP Scope の Must 機能に対応する Core Scenario（Day 1 Happy Path）が存在するか。User Story は要約 AC、Core Scenario は実行時の主要行動という SSoT の住み分けを保つ（全 US を逐一シナリオ化しない）。
+- **整合性**: ストーリーの「価値」と Core Scenario の「結果（Then）」が一致しているか。
 
 ```bash
 # 全ユーザーストーリーの ID 抽出
 grep -oE "US-[0-9]+" docs/project/01-requirements/05-user-stories.md | sort -u
-# シナリオ側の参照
-grep -oE "US-[0-9]+" docs/project/02-behavior/01-scenarios.md | sort -u
+# Core Scenario 側の対応 Must / フロー参照
+grep -oE "FN-[0-9]+|CS-[0-9]+" docs/project/02-behavior/01-core-scenarios.md | sort -u
 ```
 
-## 2.2 実装済み機能・予定機能 ↔ シナリオ
+### ユーザーストーリーの役割 ↔ ペルソナ（trace）
 
-- **実装済み機能**: `02-features-implemented.md` の機能にリグレッション用シナリオが存在するか。
-- **予定機能**: `03-features-planned.md` の優先度 High 機能にシナリオが存在するか。
+- **役割が宙に浮かない**: `05-user-stories.md` の各ストーリーの「ペルソナ」列が、`01-product-brief.md` のペルソナ表で定義済みの ID（P-XXX）を参照しているか。**未定義のペルソナを参照する US はフラグ**する（役割の trace 切れ）。
+- **逆方向（任意）**: どの US からも参照されない主要ペルソナがあれば、スコープ漏れか過剰ペルソナのどちらかとして確認する。
 
-## 2.3 非機能要件 ↔ ドメインモデル
+```bash
+# US が参照するペルソナ ID のうち、Product Brief に未定義のもの（出力があれば trace 切れ）
+comm -23 \
+  <(grep -oE "P-[0-9]+" docs/project/01-requirements/05-user-stories.md | sort -u) \
+  <(grep -oE "P-[0-9]+" docs/project/01-requirements/01-product-brief.md | sort -u)
+```
+
+## 2.2 MVP スコープ・実装済み機能 ↔ シナリオ
+
+- **MVP スコープ**: `02-mvp-scope.md` の Must 機能にシナリオが存在するか。
+- **実装済み機能**: `06-features-implemented.md`（existing モード）の機能にリグレッション用シナリオが存在するか。
+- **Parking Lot**: `03-parking-lot.md` は backlog のためシナリオ必須ではない（MVP 昇格時に MVP スコープ側で扱う）。
 
-- **パフォーマンス**: `04-non-functional-requirements.md` の要件（読み込み速度、スループット等）に対し、Read Model や CQRS が検討されているか。
-- **セキュリティ**: 認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
+## 2.3 クリティカル制約 ↔ スコープ/ドメイン
 
-## 2.4 シナリオ ↔ ドメインモデル
+初期フェーズでは定量 NFR ではなく、Product Brief の「クリティカル制約」を確認する（詳細な定量 NFR は設計フェーズ `/a-014-define-infrastructure` の責務）。
 
-- **Command**: シナリオの When（アクション）がドメインモデルの Command として定義されているか。
-- **Event**: シナリオの Then（結果）が Domain Event として定義されているか。
-- **Actor**: シナリオの Actor がドメインモデルに存在するか。
+- **制約の反映**: `01-product-brief.md` のクリティカル制約（法務・セキュリティ・期限・予算・外部 API 等）が `02-mvp-scope.md` の Must 判断やドメインモデルに反映されているか。
+- **セキュリティ・権限**: 制約に挙げた認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
+
+## 2.4 Core Scenario ↔ Domain Sketch
+
+- **アクター**: Core Scenario のアクターが Domain Sketch の「アクター / 外部システム」に存在するか。
+- **中核エンティティ**: Core Scenario が扱う対象が Domain Sketch の「中核エンティティ」に定義されているか。
+- **重要ルール**: Critical Failure を防ぐルールが「重要なビジネスルール」に反映されているか。
+- **Full DDD 採用時**: `01-domain-model.md` がある場合は、When→Command / Then→Event / Actor の対応も確認する。
 
 ## 2.5 ユビキタス言語の遵守
 
-- **用語定義**: ドメインモデルの主要要素（Aggregate, Command, Event）がユビキタス言語一覧にあるか。
+- **用語定義**: Domain Sketch の主要用語・中核エンティティ（Full DDD 採用時は Aggregate / Command / Event）がユビキタス言語一覧にあるか。
 - **禁止用語**: 各ドキュメントに禁止用語（Data, Process, Manager 等）が使われていないか。
 
 ```bash
@@ -44,8 +60,27 @@ grep -rn "Manager" docs/project/03-domain/ || echo "No 'Manager' found"
 
 ## 2.6 目的との整合性
 
-- システム概要（`01-system-overview.md`）の「目的」とドメインモデルの「Core Domain」が一致しているか。
-- ビジネス価値の提供元が Core に寄っているか（Generic に偏っていないか）。
+- Product Brief（`01-product-brief.md`）の「価値提案 / 差別化」が Domain Sketch の「中核エンティティ」「重要なビジネスルール」に反映されているか。
+- **価値提案の充足**: 「価値提案 / 差別化」のバリュープロポジション（1文）と差別化ポイント（Why us）が埋まり、Why us が「現在の代替手段・競合スキャン」表の各「弱み」と対応づいているか（漠然と「使いやすい」で済ませていないか）。
+- **目的 ↔ 成功指標**: Product Brief の成功指標（North Star / KPI / Guardrail）が「価値提案 / 解く課題」と整合しているか（目的と無関係な指標を測っていないか）。
+- **計測可能性**: 各成功指標に計測方法（どこで・どう取得）が記載され、計測可能か。今すぐ取れない指標が代理指標に置き換えられているか（MVP 段階は仮説値で可）。
+- Full DDD（`01-domain-model.md`）採用時は、ビジネス価値の提供元が Core Domain に寄っているか（Generic に偏っていないか）も確認する。
+
+## 2.7 MVP 正当化 / 過剰作り込み（YAGNI / PM Gate）
+
+「要らないものを作らない」を守るためのスコープ妥当性検査。
+
+- **Must の trace**: `02-mvp-scope.md` の各 Must 機能が、Product Brief の 課題 / ターゲット（ペルソナ）/ 成功指標 / 検証仮説 のいずれかに紐づくか。**いずれにも trace しない Must は過剰作り込み候補としてフラグ**する。
+- **Out of Scope の矛盾**: `02-mvp-scope.md` の Won't / Out of Scope に挙げた機能が、他ドキュメント（シナリオ・ドメインモデル・`05-user-stories.md`）で実装対象として記述されていないか。
+- **安い代替手段**: 手作業・既存ツール・外部サービスで足りるものが Must になっていないか（`02-mvp-scope.md` の「より安い代替手段」列を確認）。
+- **仮説の数**: 検証する仮説が 1〜3 個に絞れているか（多すぎる＝MVP が過大）。
+
+> 成功指標と目的の整合（目的 ↔ 成功指標）・計測可能性は [2.6 目的との整合性](#26-目的との整合性)で検査する。
+
+```bash
+# Out of Scope（Won't）に挙げた機能名が他 doc に混入していないか（例）
+grep -rn "{Won't機能名}" docs/project/02-behavior/ docs/project/03-domain/
+```
 
 ## エスカレーションの判断材料
 

package/skills/a-007-define-tech-stack/SKILL.md

@@ -1,99 +1,99 @@
----
-name: a-007-define-tech-stack
-description: 要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineTechStack (a-007)
-
-## 目的
-
-- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
-- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
-- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
-
-## 前提
-
-- `docs/project/01-requirements/` 配下のドキュメントが作成されていること。
-- `docs/project/03-domain/` 配下のドキュメントが作成されていること。
-- `docs/project/04-design/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-```bash
-ls -la docs/project/04-design/ 2>/dev/null || echo "ディレクトリが存在しません"
-```
-
-要件ドキュメント（`01-system-overview.md`, `03-features-planned.md`, `04-non-functional-requirements.md`）とドメインモデル（`01-domain-model.md`）を読み込む。
-
-### 2. テンプレートの準備
-
-このスキルの配置ディレクトリ（`skills/a-007-define-tech-stack/`）を起点に、相対パス `../../templates/project/04-design/01-tech-stack.md` を Read で読み込み、その内容を `docs/project/04-design/01-tech-stack.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
-
-### 3. 要件分析と推奨技術スタックの生成
-
-- **システム特性の分析**: アプリケーションタイプ（SPA/SSR 等）、非機能要件、ドメイン複雑度
-- **レイヤー別推奨**: フロントエンド / バックエンド / データベース / インフラ・CI/CD / 監視・テスト
-- **提示形式**: 各技術に「推奨理由」と「代替案」を付ける
-
-提案フォーマットと各層の候補一覧は [examples/stack-interview.md](examples/stack-interview.md#推奨案提示フォーマット) を参照。
-
-### 4. 詳細インタビューと選定
-
-フィードバックを受けてレイヤーごとに詳細確認する。各レイヤーの具体的な質問項目は [examples/stack-interview.md](examples/stack-interview.md#レイヤー別インタビュー項目) を参照。
-
-- フロントエンド: フレームワーク、TypeScript、状態管理、スタイリング
-- バックエンド: 言語、フレームワーク、API スタイル
-- データベース: RDBMS/NoSQL、ORM、マイグレーション
-- インフラ: クラウド、コンテナ、IaC
-- 開発ツール: リンター、テスト、CI/CD
-
-### 5. ドキュメント作成
-
-ヒアリング結果を `docs/project/04-design/01-tech-stack.md` に記入する。必須項目:
-
-- 技術名、バージョン
-- 選定理由（要件とのマッピング）
-- 選定タイミング（初期/中期/後期/随時）
-
-記入例は [examples/stack-interview.md](examples/stack-interview.md#記入例表形式) を参照。
-
-### 6. 構造チェック
-
-```bash
-grep "### フロントエンド" docs/project/04-design/01-tech-stack.md \
-  && grep "### バックエンド" docs/project/04-design/01-tech-stack.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/project/04-design/01-tech-stack.md
-git commit -m "docs: 技術スタック選定ドキュメントの作成"
-```
-
-詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
-
-## 完了条件
-
-- `docs/project/04-design/01-tech-stack.md` が作成されている。
-- すべてのレイヤーについて技術選定が完了している（または「保留」として記録されている）。
-- 選定理由とバージョンが明確になっている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **ユーザーが決められない**: 「要件に基づき、最も標準的でリスクの少ない [技術名] を仮採用とし、実装フェーズで再評価しませんか？」
-- **コスト・学習コストの懸念**: 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑要件が出てから移行検討しましょう。」
-- 詳細応答例は [reference/structure-check.md](reference/structure-check.md#エスカレーション時の推奨応答) を参照。
-
-## 参考
-
-- [examples/stack-interview.md](examples/stack-interview.md) — 推奨案フォーマット、レイヤー別インタビュー項目、選定タイミング区分、記入例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例
+---
+name: a-007-define-tech-stack
+description: 要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineTechStack (a-007)
+
+## 目的
+
+- 既存の要件ドキュメント（Product Brief（クリティカル制約含む）、ドメインモデル）を分析し、適合する技術スタックを推奨する。
+- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
+- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
+
+## 前提
+
+- `docs/project/01-requirements/` 配下のドキュメントが作成されていること。
+- `docs/project/03-domain/` 配下のドキュメントが作成されていること。
+- `docs/project/04-design/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+```bash
+ls -la docs/project/04-design/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+要件ドキュメント（`01-product-brief.md`（クリティカル制約含む）, `02-mvp-scope.md`）とドメイン（`01-domain-sketch.md`、Full DDD 採用時は `01-domain-model.md`）を読み込む。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-007-define-tech-stack/`）を起点に、相対パス `../../templates/project/04-design/01-tech-stack.md` を Read で読み込み、その内容を `docs/project/04-design/01-tech-stack.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. 要件分析と推奨技術スタックの生成
+
+- **システム特性の分析**: アプリケーションタイプ（SPA/SSR 等）、クリティカル制約（NFR の要点）、ドメイン複雑度
+- **レイヤー別推奨**: フロントエンド / バックエンド / データベース / インフラ・CI/CD / 監視・テスト
+- **提示形式**: 各技術に「推奨理由」と「代替案」を付ける
+
+提案フォーマットと各層の候補一覧は [examples/stack-interview.md](examples/stack-interview.md#推奨案提示フォーマット) を参照。
+
+### 4. 詳細インタビューと選定
+
+フィードバックを受けてレイヤーごとに詳細確認する。各レイヤーの具体的な質問項目は [examples/stack-interview.md](examples/stack-interview.md#レイヤー別インタビュー項目) を参照。
+
+- フロントエンド: フレームワーク、TypeScript、状態管理、スタイリング
+- バックエンド: 言語、フレームワーク、API スタイル
+- データベース: RDBMS/NoSQL、ORM、マイグレーション
+- インフラ: クラウド、コンテナ、IaC
+- 開発ツール: リンター、テスト、CI/CD
+
+### 5. ドキュメント作成
+
+ヒアリング結果を `docs/project/04-design/01-tech-stack.md` に記入する。必須項目:
+
+- 技術名、バージョン
+- 選定理由（要件とのマッピング）
+- 選定タイミング（初期/中期/後期/随時）
+
+記入例は [examples/stack-interview.md](examples/stack-interview.md#記入例表形式) を参照。
+
+### 6. 構造チェック
+
+```bash
+grep "### フロントエンド" docs/project/04-design/01-tech-stack.md \
+  && grep "### バックエンド" docs/project/04-design/01-tech-stack.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/01-tech-stack.md
+git commit -m "docs: 技術スタック選定ドキュメントの作成"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/04-design/01-tech-stack.md` が作成されている。
+- すべてのレイヤーについて技術選定が完了している（または「保留」として記録されている）。
+- 選定理由とバージョンが明確になっている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **ユーザーが決められない**: 「要件に基づき、最も標準的でリスクの少ない [技術名] を仮採用とし、実装フェーズで再評価しませんか？」
+- **コスト・学習コストの懸念**: 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑要件が出てから移行検討しましょう。」
+- 詳細応答例は [reference/structure-check.md](reference/structure-check.md#エスカレーション時の推奨応答) を参照。
+
+## 参考
+
+- [examples/stack-interview.md](examples/stack-interview.md) — 推奨案フォーマット、レイヤー別インタビュー項目、選定タイミング区分、記入例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例

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) — 構造確認コマンド、チェックリスト、パターン選定ガイド、レビュー質問