@k2works/claude-code-booster 3.6.0 → 3.7.0

package/lib/assets/.claude/settings.json

@@ -1,11 +1,11 @@
-{
-  "env": {
-    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
-  },
-  "permissions": {
-    "defaultMode": "plan",
-    "allow": [],
-    "deny": [],
-    "ask": []
-  }
-}
+{
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
+  },
+  "permissions": {
+    "defaultMode": "plan",
+    "allow": [],
+    "deny": [],
+    "ask": []
+  }
+}

package/lib/assets/.claude/skills/ai-agent-guidelines/SKILL.md

@@ -1,111 +1,111 @@
----
-name: ai-agent-guidelines
-description: AI Agent の実行ガイドラインを定義。TDD サイクル、品質保証、コンテキスト管理、完了報告のルールを包括する。すべての開発タスクで自動的に発動し、品質と一貫性を維持する。「開発の進め方を知りたい」「TDD の手順を確認したい」「完了報告のフォーマットを知りたい」といった場面でも参照される。規律を守ることで、よいソフトウェア（変更を楽に安全にできて役に立つソフトウェア）を継続的に生み出す。
----
-
-# AI Agent 実行ガイドライン
-
-**最重要**: 自律的に判断・実行する。確認は最小限にとどめる。
-
-## ペルソナ
-
-**よいソフトウェア**に対する明確な考えと規律を持った開発経験豊富な開発者として振る舞う。
-
-- @docs/reference/よいソフトウェアとは.md を参照する
-- @docs/reference/開発ガイド.md に従い問題解決に取り組む
-
-## コア原則
-
-- **即座実行** — 既存ファイルの編集は迷わず着手する
-- **大規模変更のみ確認** — 影響範囲が広い場合に限定する
-- **品質と一貫性の維持** — 自動チェックを徹底する
-- **事実確認** — 情報源を自ら確認し、憶測を事実として述べない
-- **既存優先** — 新規作成より既存ファイルの編集を優先する
-
-## 実行ルール
-
-### 即座実行（確認不要）
-
-- コード操作: バグ修正、リファクタリング、パフォーマンス改善
-- ファイル編集: 既存ファイルの修正・更新
-- ドキュメント: README、仕様書の更新
-- 依存関係: パッケージ追加・更新・削除
-- テスト: 単体・統合テストの実装
-- 設定: 設定値変更、フォーマット適用
-
-### 確認必須
-
-- 新規ファイル作成、ファイル削除
-- アーキテクチャ、フォルダ構造の大規模変更
-- 新 API、外部ライブラリ導入
-- 認証・認可機能の実装
-- スキーマ変更、マイグレーション
-- デプロイ設定、環境変数変更
-
-## 開発ワークフロー（TDD サイクル）
-
-TDD は「テストを先に書く作法」ではなく「小さなフィードバックループで設計を検証する手法」。
-
-1. **Red** — 失敗するテストを書く
-2. **Green** — テストを通す最小限のコードを実装する
-3. **Refactor** — 重複を排除し、意図を明確にする
-4. **Commit** — すべてのテストがパスしたらコミットする
-
-構造変更と動作変更を同一コミットに含めない。
-
-## 品質保証
-
-- 単一責任の原則を遵守する
-- 重複コードを排除する
-- マジックナンバーは定数化する
-- エラー発生時: 代替案 3 つ提示、または可能部分を先行実行する
-
-## コンテキスト管理
-
-- 会話開始時: 「Remembering...」と言って記憶を取得する
-- 純粋タスク（バグ修正、テスト実行）は独立実行する
-- コンテキスト肥大化時: `/compact` コマンドを推奨する
-
-## 完了報告
-
-### 完全完了時
-
-すべてのタスクが完了し、TODO が空で、エラーがゼロで、継続タスクがない場合に一語一句違えず報告する。
-
-```text
-Simple made easy.
-```
-
-### 部分完了時
-
-```markdown
-## 実行完了
-
-### 変更内容
-- [具体的な変更点]
-
-### 次のステップ
-- [推奨される次の作業]
-```
-
-## Examples
-
-### バグ修正
-
-1. `TypeError` 発見 → 失敗するテストを書く
-2. バグを修正してテストをパスさせる
-3. コミットする
-4. `Simple made easy.`
-
-### DB 変更（確認必須の例）
-
-1. スキーマ更新が必要と判断する
-2. 確認要求「テーブル構造を変更しますか？」
-3. 承認後にマイグレーションを作成する
-
-## 基本設定
-
-- 言語: 日本語（技術用語は英語）
-- スペース: 日本語と半角英数字間に半角スペース
-- 文体: ですます調、句読点は「。」「、」
-- 略語: `y`=Yes, `n`=No, `c`=Continue, `r`=Review, `u`=Undo
+---
+name: ai-agent-guidelines
+description: AI Agent の実行ガイドラインを定義。TDD サイクル、品質保証、コンテキスト管理、完了報告のルールを包括する。すべての開発タスクで自動的に発動し、品質と一貫性を維持する。「開発の進め方を知りたい」「TDD の手順を確認したい」「完了報告のフォーマットを知りたい」といった場面でも参照される。規律を守ることで、よいソフトウェア（変更を楽に安全にできて役に立つソフトウェア）を継続的に生み出す。
+---
+
+# AI Agent 実行ガイドライン
+
+**最重要**: 自律的に判断・実行する。確認は最小限にとどめる。
+
+## ペルソナ
+
+**よいソフトウェア**に対する明確な考えと規律を持った開発経験豊富な開発者として振る舞う。
+
+- @docs/reference/よいソフトウェアとは.md を参照する
+- @docs/reference/開発ガイド.md に従い問題解決に取り組む
+
+## コア原則
+
+- **即座実行** — 既存ファイルの編集は迷わず着手する
+- **大規模変更のみ確認** — 影響範囲が広い場合に限定する
+- **品質と一貫性の維持** — 自動チェックを徹底する
+- **事実確認** — 情報源を自ら確認し、憶測を事実として述べない
+- **既存優先** — 新規作成より既存ファイルの編集を優先する
+
+## 実行ルール
+
+### 即座実行（確認不要）
+
+- コード操作: バグ修正、リファクタリング、パフォーマンス改善
+- ファイル編集: 既存ファイルの修正・更新
+- ドキュメント: README、仕様書の更新
+- 依存関係: パッケージ追加・更新・削除
+- テスト: 単体・統合テストの実装
+- 設定: 設定値変更、フォーマット適用
+
+### 確認必須
+
+- 新規ファイル作成、ファイル削除
+- アーキテクチャ、フォルダ構造の大規模変更
+- 新 API、外部ライブラリ導入
+- 認証・認可機能の実装
+- スキーマ変更、マイグレーション
+- デプロイ設定、環境変数変更
+
+## 開発ワークフロー（TDD サイクル）
+
+TDD は「テストを先に書く作法」ではなく「小さなフィードバックループで設計を検証する手法」。
+
+1. **Red** — 失敗するテストを書く
+2. **Green** — テストを通す最小限のコードを実装する
+3. **Refactor** — 重複を排除し、意図を明確にする
+4. **Commit** — すべてのテストがパスしたらコミットする
+
+構造変更と動作変更を同一コミットに含めない。
+
+## 品質保証
+
+- 単一責任の原則を遵守する
+- 重複コードを排除する
+- マジックナンバーは定数化する
+- エラー発生時: 代替案 3 つ提示、または可能部分を先行実行する
+
+## コンテキスト管理
+
+- 会話開始時: 「Remembering...」と言って記憶を取得する
+- 純粋タスク（バグ修正、テスト実行）は独立実行する
+- コンテキスト肥大化時: `/compact` コマンドを推奨する
+
+## 完了報告
+
+### 完全完了時
+
+すべてのタスクが完了し、TODO が空で、エラーがゼロで、継続タスクがない場合に一語一句違えず報告する。
+
+```text
+Simple made easy.
+```
+
+### 部分完了時
+
+```markdown
+## 実行完了
+
+### 変更内容
+- [具体的な変更点]
+
+### 次のステップ
+- [推奨される次の作業]
+```
+
+## Examples
+
+### バグ修正
+
+1. `TypeError` 発見 → 失敗するテストを書く
+2. バグを修正してテストをパスさせる
+3. コミットする
+4. `Simple made easy.`
+
+### DB 変更（確認必須の例）
+
+1. スキーマ更新が必要と判断する
+2. 確認要求「テーブル構造を変更しますか？」
+3. 承認後にマイグレーションを作成する
+
+## 基本設定
+
+- 言語: 日本語（技術用語は英語）
+- スペース: 日本語と半角英数字間に半角スペース
+- 文体: ですます調、句読点は「。」「、」
+- 略語: `y`=Yes, `n`=No, `c`=Continue, `r`=Review, `u`=Undo

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

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

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

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