@k2works/claude-code-booster 1.13.0 → 2.0.1

package/lib/assets/.claude/skills/analyzing-architecture/SKILL.md

@@ -1,87 +1,83 @@
 ---
 name: analyzing-architecture
-description: アーキテクチャ設計を支援。バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成。アーキテクチャ設計やシステム構成の検討時に使用。
+description: バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成を支援。「アーキテクチャを設計したい」「システム構成を検討したい」「レイヤード/ヘキサゴナル/クリーンどれが適切か」「CQRS を導入すべきか」「フロントエンドのアーキテクチャを決めたい」といった場面で発動する。アーキテクチャを早期に設計することで、開発フェーズでの技術的負債の蓄積を防ぐ。
 ---
 
-# アーキテクチャ設計支援
+# アーキテクチャ設計
 
-業務領域とデータ構造の複雑さに基づくアーキテクチャパターンの選択を支援します。
+業務領域とデータ構造の複雑さに基づき、バックエンド・フロントエンド・インフラの各アーキテクチャパターンを選択し設計ドキュメントを作成する。
 
-## Instructions
+アーキテクチャは後から変えるコストが最も高い設計判断。要件定義の段階で適切なパターンを選定することで、開発全体の方向性を確定し、手戻りを最小化する。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/アーキテクチャ設計ガイド.md - アーキテクチャ設計の進め方
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/アーキテクチャ設計ガイド.md | アーキテクチャ設計の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 成果物 | `docs/design/architecture_backend.md` | バックエンドアーキテクチャ |
+| 成果物 | `docs/design/architecture_frontend.md` | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/architecture_infrastructure.md` | インフラストラクチャアーキテクチャ |
 
-### 2. 入力
+## バックエンドアーキテクチャ設計
 
-- @docs/requirements/requirements_definition.md - 要件定義
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
+業務ロジックの複雑さに応じてパターンを選択する。単純な CRUD ならレイヤードで十分だが、ドメインが複雑な場合はヘキサゴナルやクリーンアーキテクチャを採用せよ。
 
-### 3. 成果物
+- **アーキテクチャパターンの選択**: レイヤード、ヘキサゴナル、クリーン等から要件に最適なものを選定する
+- **CQRS/イベントソーシングの適用判断**: 読み書きの特性が大きく異なる場合に検討する。過剰適用は複雑さを増すだけなので慎重に判断せよ
+- **API 設計方針**: REST/GraphQL/gRPC の選択基準を明確にする
 
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
-- @docs/design/architecture_infrastructure.md - インフラストラクチャアーキテクチャ
+## フロントエンドアーキテクチャ設計
 
-### 4. 作業内容
+ユーザー体験とチームのスキルセットを考慮して設計する。フレームワーク選定はプロジェクト全体に影響するため、ADR で判断根拠を残せ。
 
-#### バックエンドアーキテクチャ設計
+- **フレームワーク選定**: プロジェクト要件に合ったフレームワークを選択する
+- **状態管理パターン**: アプリケーションの状態の複雑さに応じて適切なパターンを選定する
+- **コンポーネント設計方針**: 再利用性と保守性を両立する設計指針を定める
 
-- アーキテクチャパターンの選択（レイヤード、ヘキサゴナル、クリーン等）
-- CQRS/イベントソーシングの適用判断
-- API 設計方針
+## インフラストラクチャアーキテクチャ設計
 
-#### フロントエンドアーキテクチャ設計
+非機能要件（可用性・スケーラビリティ）を実現するインフラ構成を設計する。運用コストとの兼ね合いも考慮せよ。
 
-- フレームワーク選定
-- 状態管理パターン
-- コンポーネント設計方針
+- **クラウド/オンプレミス選定**: コスト・セキュリティ・運用負荷を総合的に判断する
+- **コンテナ化戦略**: コンテナ化の適用範囲とオーケストレーション方式を決定する
+- **CI/CD パイプライン設計**: ビルド・テスト・デプロイの自動化方針を定める
 
-#### インフラストラクチャアーキテクチャ設計
+## 作成の進め方
 
-- クラウド/オンプレミス選定
-- コンテナ化戦略
-- CI/CD パイプライン設計
+1. 入力ドキュメント（要件定義、ユースケース、ユーザーストーリー）を確認する。なければ基本情報をヒアリングする
+2. @docs/reference/アーキテクチャ設計ガイド.md を読み込む
+3. バックエンド→フロントエンド→インフラの順に設計する。各アーキテクチャの選定理由を明記せよ
+4. 重要な設計判断は ADR（Architecture Decision Record）で記録する
 
-### 5. 注意事項
+## 途中から再開する場合
 
-- **前提条件**: 要件定義とユースケースが完了していること
-- **制限事項**: アーキテクチャ決定は ADR（Architecture Decision Record）で記録すること
-- **推奨事項**: 業務の複雑さとチームのスキルセットを考慮して選択する
+既存の `docs/design/architecture_*.md` がある場合は、まずその内容を確認する。不足している領域や更新が必要な部分のみを修正する。
 
-### 6. 記述ルール
+**Example:**
 
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
+ユーザー: 「バックエンドはクリーンアーキテクチャで決めた。フロントエンドを設計したい」
+回答: 既存の architecture_backend.md を確認し、
+      バックエンドの API 設計方針を踏まえてフロントエンドアーキテクチャ設計に進む。
+      フレームワーク選定→状態管理→コンポーネント設計の順で作成する。
 ```
 
-## Examples
-
-### 要件に基づくアーキテクチャ設計
+## 注意事項
 
-1. 要件定義とユーザーストーリーを読み込む
-2. @docs/reference/アーキテクチャ設計ガイド.md に基づいて設計
-3. バックエンド・フロントエンド・インフラの各アーキテクチャドキュメントを作成
+- 要件定義とユースケースが完了していることが前提。未完了でもプロジェクト情報から進めて構わない
+- アーキテクチャ決定は必ず ADR で記録する。「なぜその選択をしたか」が後で最も重要になる
+- 業務の複雑さとチームのスキルセットを考慮して選択する。技術的に「正しい」選択よりチームが運用できる選択を優先せよ
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### 技術的制約がある場合
+## 関連スキル
 
-1. 既存の `package.json` や `pom.xml` を確認
-2. 既存技術スタックを考慮したアーキテクチャ選択を提案
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-requirements` — 前段の要件定義
+- `analyzing-domain-model` — 後続のドメインモデル設計
+- `analyzing-data-model` — 後続のデータモデル設計
+- `analyzing-tech-stack` — 後続の技術スタック選定

package/lib/assets/.claude/skills/analyzing-business/SKILL.md

@@ -1,117 +1,95 @@
 ---
 name: analyzing-business
-description: ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオの作成。ビジネスアーキテクチャやビジネス構造の検討時に使用。
+description: ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
 ---
 
-# ビジネスアーキテクチャ分析支援
+# ビジネスアーキテクチャ分析
 
-要件定義の前段階として、エンタープライズがどのように価値を生み出し、顧客に提供するかの構造を体系的に整理・設計します。本スキルの成果物は後続の要件定義（`analyzing-requirements`）やユースケース分析（`analyzing-usecases`）の入力となります。
+エンタープライズがどのように価値を生み出し、顧客に提供するかの構造を体系的に整理する。この分析は要件定義の前段階として行い、成果物は後続の `analyzing-requirements`（要件定義）や `analyzing-usecases`（ユースケース分析）の入力になる。
 
-## Instructions
+ビジネスの構造を先に理解することで、「何を作るか」ではなく「なぜ作るか」からシステムを設計でき、本当に価値のある機能に集中できる。
 
-### 1. 参照ドキュメント
+## 参照ドキュメント
 
-- @docs/reference/ビジネスアーキテクチャ分析ガイド.md - ビジネスアーキテクチャ分析の進め方
+- @docs/reference/ビジネスアーキテクチャ分析ガイド.md — 分析手法とフレームワークの詳細。各成果物の作成方法はこのガイドに従う。
 
-### 2. テンプレート
+## テンプレートと成果物
 
-- @docs/template/ビジネスアーキテクチャ.md - ビジネスアーキテクチャテンプレート（**編集禁止**）
+| 種類 | パス | 備考 |
+|------|------|------|
+| テンプレート | @docs/template/ビジネスアーキテクチャ.md | 編集禁止。コピーして使用する |
+| 成果物 | `docs/analysis/business_architecture.md` | テンプレートを基に作成 |
 
-### 3. 入力
+## 分析の進め方
 
-- プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）
-- ステークホルダーからのヒアリング情報
+以下の順序で進める。各ステップの出力が次のステップの入力になるため、この順序を守ることで整合性の高い分析ができる。
 
-### 4. 成果物
+### 1. プリンシプルの定義
 
-- @docs/analysis/business_architecture.md - ビジネスアーキテクチャ分析書
+ビジョン・ミッション・価値観に基づく方針を最初に固める。プリンシプルが曖昧だと、後続の分析で判断軸がブレる。
 
-### 5. 作業内容
+- **ガイディングプリンシプル**: ビジネス・アプリケーション・データ・テクノロジーの各アーキテクチャに対する方針
+- **ビジネスプリンシプル**: ビジネスにおける原則原理
 
-#### プリンシプルの定義
+### 2. ビジネスモデルの整理
 
-- ガイディングプリンシプル（ビジョン、ミッション、価値観に基づく方針）の策定
-- ビジネスプリンシプル（ビジネスにおける原則原理）の定義
+ビジネスモデルキャンバスを作成し、ビジネスの全体構造を 9 つの要素で可視化する。
 
-#### ビジネスモデルの整理
+- 顧客セグメント、価値提案、チャネル、顧客関係
+- 主要活動、主要リソース、主要パートナー
+- 収益源、コスト構造
 
-- ビジネスモデルキャンバスの作成
-  - 顧客セグメント、価値提案、チャネル、顧客関係の整理
-  - 主要活動、主要リソース、主要パートナーの特定
-  - 収益源、コスト構造の明確化
+### 3. バリューストリームの設計
 
-#### バリューストリームの設計
+価値がどのように流れるかを可視化する。バリューストリームはケイパビリティモデルの土台になるため、ケイパビリティより先に作成する。
 
 - バリュー（価値）の分析
 - バリューストリームマップの作成
 - 各ステージでの価値増加の可視化
 
-#### ビジネスケイパビリティモデルの構築
+### 4. ケイパビリティモデルの構築
 
-- ビジネスケイパビリティの特定（戦略・コア・サポート）
-- ケイパビリティの階層化とレベリング
-- ヒートマッピングによる成熟度評価
-- ケイパビリティとバリューストリームのマッピング
-
-#### 組織マップの作成
-
-- 部門・組織構造の整理
-- 組織とケイパビリティの対応付け
+組織が持つ能力を体系的に整理する。バリューストリームの各ステージに必要なケイパビリティを紐付けることで、どの能力に投資すべきかが見える。
 
-#### 情報マップの作成
+- ケイパビリティの特定（戦略・コア・サポート）
+- 階層化とレベリング
+- ヒートマッピングによる成熟度評価
+- バリューストリームとのマッピング
 
-- ビジネスエンティティの特定
-- エンティティ間のリレーション整理
+### 5. 組織マップの作成
 
-#### ビジネスシナリオの策定
+部門・組織構造を整理し、ケイパビリティとの対応付けを行う。
 
-- 問題の特定と文書化
-- ビジネス・技術環境のモデル化
-- ゴールと期待する結果の定義
-- ヒューマンアクター・コンピュータアクターの特定
+### 6. 情報マップの作成
 
-### 6. 注意事項
+ビジネスエンティティを特定し、エンティティ間のリレーションを整理する。後続のデータモデル設計の基礎になる。
 
-- **前提条件**: プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）が提供されていること
-- **制限事項**: ビジネスアーキテクチャの決定は ADR で記録すること
-- **推奨事項**: バリューストリームを先に作成し、その後ケイパビリティモデルを構築する
+### 7. ビジネスシナリオの策定
 
-### 7. 記述ルール
+問題を特定・文書化し、ゴールと期待する結果を定義する。ヒューマンアクター・コンピュータアクターを特定し、後続のユースケース分析の入力とする。
 
-タスク項目などは一行開けて記述する。
+## 途中から再開する場合
 
-OK:
+既存の `docs/analysis/business_architecture.md` がある場合は、まずその内容を確認する。完了済みのセクションはスキップし、未着手または更新が必要なセクションから再開する。
 
-```markdown
-**受入条件**:
+**Example:**
 
-- [ ] ビジネスモデルキャンバスが作成されている
-- [ ] バリューストリームマップが作成されている
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] ビジネスモデルキャンバスが作成されている
-- [ ] バリューストリームマップが作成されている
+ユーザー: 「ビジネスモデルキャンバスは作った。次は？」
+回答: バリューストリームの設計に進む。ビジネスモデルキャンバスで特定した
+      主要活動を基に、価値の流れを可視化する。
 ```
 
-## Examples
-
-### 新規プロジェクトでビジネスアーキテクチャを設計
-
-1. プロジェクトの基本情報とビジネス概要を確認
-2. @docs/reference/ビジネスアーキテクチャ分析ガイド.md に基づいて分析
-3. ビジネスモデルキャンバス → バリューストリーム → ケイパビリティモデルの順に作成
-
-### 既存ビジネスの分析・改善
+## 注意事項
 
-1. 既存の @docs/design/business_architecture.md を読み込む
-2. ヒートマッピングで成熟度を評価し改善提案を作成
+- プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）が提供されていることを確認してから分析を開始する
+- ビジネスアーキテクチャの重要な決定は ADR（`creating-adr`）で記録する
+- 成果物は PlantUML を活用して視覚的に文書化する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### 関連スキル
+## 関連スキル
 
-- `analyzing-requirements` : 後続の要件定義（本スキルの成果物が入力となる）
-- `analyzing-usecases` : 後続のビジネスユースケース詳細化
-- `analyzing-architecture` : 後続のシステムアーキテクチャ設計への橋渡し
+- `analyzing-requirements` — 後続の要件定義（本スキルの成果物が入力）
+- `analyzing-usecases` — 後続のビジネスユースケース詳細化
+- `analyzing-architecture` — 後続のシステムアーキテクチャ設計への橋渡し
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内

package/lib/assets/.claude/skills/analyzing-data-model/SKILL.md

@@ -1,80 +1,77 @@
 ---
 name: analyzing-data-model
-description: データモデル設計を支援。ER 図作成、テーブル定義、リレーション設計。データベース設計やテーブル構造の検討時に使用。
+description: PlantUML の ER 図を使用したデータモデル設計を支援。概念→論理データモデルの段階的設計とテーブル定義。「データモデルを設計したい」「ER 図を作りたい」「テーブル定義を作成したい」「データベース設計を始めたい」「正規化を検討したい」といった場面で発動する。データモデルを先に設計することで、実装時のテーブル設計の手戻りを防ぐ。
 ---
 
-# データモデル設計支援
+# データモデル設計
 
-PlantUML の ER 図を使用してデータモデルを設計します。
+PlantUML の ER 図を使用して、概念データモデル→論理データモデルの順でデータモデルを設計する。
 
-## Instructions
+データモデルはシステムの「記憶」を定義する設計。ドメインモデルが業務ロジックの構造を表すのに対し、データモデルはデータの永続化構造を定義する。両者の整合性がシステム全体の一貫性を保証する。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/データモデル設計ガイド.md - データモデル設計の進め方
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/データモデル設計ガイド.md | データモデル設計の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/data-model.md` | データモデル設計 |
 
-### 2. 入力
+## 概念データモデル作成
 
-- @docs/requirements/requirements_definition.md - 要件定義
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
+業務の言葉でエンティティとリレーションシップを識別する。この段階では物理的な実装を考えない。ユースケースの「名詞」がエンティティ候補になる。
 
-### 3. 成果物
+- **エンティティの識別**: ユースケースとユーザーストーリーから管理対象を抽出する
+- **リレーションシップの定義**: エンティティ間の関係（1:1、1:N、N:N）を明確にする
 
-- @docs/design/data-model.md - データモデル設計
+## 論理データモデル作成
 
-### 4. 作業内容
+概念モデルを具体的なテーブル構造に落とし込む。正規化は第 3 正規形を基本とし、パフォーマンス要件に応じて非正規化を検討せよ。
 
-#### 概念データモデル作成
+- **テーブル定義**: カラム名、データ型、制約を定義する
+- **主キー・外部キーの設計**: 識別子の戦略（自然キー/サロゲートキー）を決定する
+- **正規化の適用**: 第 3 正規形まで正規化し、必要に応じて非正規化の判断を記録する
 
-- エンティティの識別
-- リレーションシップの定義
+## ER 図作成
 
-#### 論理データモデル作成
+PlantUML を使用して ER 図を作成する。テーブル間の関係を可視化することで、設計レビューの効率が上がる。
 
-- テーブル定義
-- 主キー・外部キーの設計
-- 正規化の適用
+## 作成の進め方
 
-#### ER 図作成
+1. 入力ドキュメント（要件定義、アーキテクチャ設計）を確認する
+2. @docs/reference/データモデル設計ガイド.md を読み込む
+3. 概念データモデル→論理データモデルの順に作成する
+4. ドメインモデルとの整合性を確認しながら `docs/design/data-model.md` として出力する
 
-- PlantUML を使用した ER 図の作成
-- テーブル間の関係の可視化
+## 途中から再開する場合
 
-### 5. 注意事項
+既存の `docs/design/data-model.md` がある場合は、まずその内容を確認する。不足しているエンティティや更新が必要なリレーションシップのみを修正する。
 
-- **前提条件**: 要件定義とアーキテクチャ設計が完了していること
-- **制限事項**: PlantUML の ER 図を使用すること
-- **推奨事項**: ドメインモデルとの整合性を確認しながら設計する
+**Example:**
 
-### 6. 記述ルール
-
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] テーブル定義が完了している
-- [ ] ER 図が作成されている
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] テーブル定義が完了している
-- [ ] ER 図が作成されている
+ユーザー: 「概念モデルはできた。論理モデルを作りたい」
+回答: 既存の data-model.md の概念データモデルを確認し、
+      各エンティティのテーブル定義（カラム・データ型・制約）を作成する。
+      主キー・外部キーの設計を行い、ER 図を PlantUML で更新する。
 ```
 
-## Examples
+## 注意事項
+
+- 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- ER 図は必ず PlantUML で作成する。テキストベースの図はバージョン管理と差分レビューに適している
+- ドメインモデルとの整合性を常に確認する。データモデルとドメインモデルの乖離は実装時の混乱を招く
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### 要件に基づくデータモデル設計
+## 関連スキル
 
-1. 要件定義とバックエンドアーキテクチャを読み込む
-2. @docs/reference/データモデル設計ガイド.md に基づいて設計
-3. ドメインモデルとの整合性を確認しながらデータモデルを作成
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — 前段のアーキテクチャ設計
+- `analyzing-domain-model` — 並行して進めるドメインモデル設計
+- `analyzing-tech-stack` — 後続の技術スタック選定（DB 選定に影響）

package/lib/assets/.claude/skills/analyzing-domain-model/SKILL.md

@@ -1,88 +1,88 @@
 ---
 name: analyzing-domain-model
-description: ドメインモデル設計を支援。エンティティ、値オブジェクト、集約の設計。DDD やドメインモデリングの検討時に使用。
+description: DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。
 ---
 
-# ドメインモデル設計支援
+# ドメインモデル設計
 
-DDD の戦術的設計パターンに基づくドメインモデルを設計します。
+DDD（ドメイン駆動設計）の戦術的設計パターンに基づき、エンティティ・値オブジェクト・集約・ドメインサービスを設計する。
 
-## Instructions
+ドメインモデルの価値は、業務の専門家と開発者が同じ言葉（ユビキタス言語）で会話できるようになること。モデルとコードが一致することで、「仕様と実装の乖離」という根本的な問題を解消する。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/ドメインモデル設計ガイド.md - ドメインモデル設計の進め方
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/ドメインモデル設計ガイド.md | ドメインモデル設計の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/domain-model.md` | ドメインモデル設計 |
 
-### 2. 入力
+## エンティティ定義
 
-- @docs/requirements/requirements_definition.md - 要件定義
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
+ライフサイクルを持ち、識別子で区別されるドメインオブジェクトを識別する。「同じ属性値でも別のものとして扱う必要がある」ものがエンティティ。
 
-### 3. 成果物
+- **ライフサイクルを持つドメインオブジェクトの識別**: ユースケースの動詞（作成・更新・削除）の対象がエンティティ候補
+- **識別子の設計**: 自然キーかサロゲートキーかを決定する。ドメイン的に意味のある識別子があれば自然キーを優先せよ
 
-- @docs/design/domain-model.md - ドメインモデル設計
+## 値オブジェクト定義
 
-### 4. 作業内容
+不変で識別子を持たないドメインオブジェクトを識別する。「属性値が同じなら同じもの」として扱えるものが値オブジェクト。プリミティブ型の代わりに値オブジェクトを使うことで、バリデーションとドメイン知識をカプセル化する。
 
-#### エンティティ定義
+- **不変オブジェクトの識別**: 金額、メールアドレス、住所などの業務概念を値オブジェクト化する
+- **バリデーションルールの定義**: 生成時にバリデーションを行い、不正な状態の値オブジェクトが存在できないようにする
 
-- ライフサイクルを持つドメインオブジェクトの識別
-- 識別子の設計
+## 集約の設計
 
-#### 値オブジェクト定義
+トランザクション整合性の境界を定義する。集約が大きすぎると競合が発生し、小さすぎると整合性が保てない。適切な境界の見極めが最も重要。
 
-- 不変で識別子を持たないドメインオブジェクトの識別
-- バリデーションルールの定義
+- **集約ルートの識別**: 外部からのアクセスポイントとなるエンティティを決定する
+- **集約境界の定義**: トランザクション整合性が必要な範囲を最小限にせよ
+- **不変条件の設計**: 集約内で常に満たすべきビジネスルールを明確にする
 
-#### 集約の設計
+## ドメインサービス定義
 
-- 集約ルートの識別
-- 集約境界の定義
-- 不変条件の設計
+エンティティにも値オブジェクトにも属さないビジネスロジックを識別する。ドメインサービスは動詞で命名し、ステートレスに保て。
 
-#### ドメインサービス定義
+## ダイアグラム作成
 
-- エンティティに属さないビジネスロジックの識別
+PlantUML を使用してクラス図・オブジェクト図を作成する。図はコードと同様にバージョン管理し、設計の変更を追跡可能にせよ。
 
-#### ダイアグラム作成
+## 作成の進め方
 
-- PlantUML を使用したクラス図・オブジェクト図の作成
+1. 入力ドキュメント（要件定義、ユースケース、アーキテクチャ設計）を確認する
+2. @docs/reference/ドメインモデル設計ガイド.md を読み込む
+3. ユビキタス言語の用語集を作成し、エンティティ→値オブジェクト→集約→ドメインサービスの順に設計する
+4. `docs/design/domain-model.md` として出力する
 
-### 5. 注意事項
+## 途中から再開する場合
 
-- **前提条件**: 要件定義とアーキテクチャ設計が完了していること
-- **制限事項**: PlantUML を使用してダイアグラムを作成すること
-- **推奨事項**: ユビキタス言語を使用してドメインエキスパートと共通認識を持つ
+既存の `docs/design/domain-model.md` がある場合は、まずその内容を確認する。不足しているドメインオブジェクトや集約境界の見直しが必要な部分のみを修正する。
 
-### 6. 記述ルール
+**Example:**
 
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] エンティティが定義されている
-- [ ] 集約境界が明確である
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] エンティティが定義されている
-- [ ] 集約境界が明確である
+ユーザー: 「エンティティは識別した。集約の境界を決めたい」
+回答: 既存の domain-model.md のエンティティ一覧を確認し、
+      トランザクション整合性が必要な範囲を分析して集約境界を定義する。
+      集約ルートを決定し、不変条件を明記する。
 ```
 
-## Examples
+## 注意事項
+
+- 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- ダイアグラムは必ず PlantUML で作成する
+- ユビキタス言語を使用してドメインエキスパートと共通認識を持つ。コード上のクラス名・メソッド名もユビキタス言語に合わせよ
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### ユースケースに基づくドメインモデル設計
+## 関連スキル
 
-1. システムユースケースとユーザーストーリーを読み込む
-2. @docs/reference/ドメインモデル設計ガイド.md に基づいて設計
-3. エンティティ、値オブジェクト、集約を識別してドメインモデルを作成
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — 前段のアーキテクチャ設計
+- `analyzing-data-model` — 並行して進めるデータモデル設計
+- `analyzing-usecases` — 入力となるユースケース・ユーザーストーリー