@k2works/claude-code-booster 6.4.0 → 6.6.0

package/lib/assets/.claude/skills/operating-script/SKILL.md

@@ -1,145 +1,145 @@
----
-name: operating-script
-description: 運用スクリプト（Gulp タスク）の作成・更新を支援。ops/scripts/ 配下に運用スクリプト作成ガイドに準拠したスクリプトを作成し、gulpfile.js に登録する。「Gulp タスクを作りたい」「デプロイスクリプトを作成したい」「運用タスクを自動化したい」「新しい環境の運用スクリプトを追加したい」「開発タスクランナーを更新したい」といった場面で発動する。環境構築完了後に対応する運用スクリプトを作成する場面でも積極的に使用する。
----
-
-# 運用スクリプト作成
-
-環境構築やデプロイ、プロビジョニングなどの運用タスクを自動化する Gulp スクリプトを作成する。スクリプトはプロジェクトの運用効率を左右するため、ネーミング・構造・実装スタイルの一貫性が重要になる。
-
-## Instructions
-
-### 1. 参照ガイド
-
-@docs/reference/運用スクリプト作成ガイド.md に定義されたルールに従う。このガイドがネーミング規則・ディレクトリ構成・コーディング規約の正とする。
-
-### 2. ファイル命名規則
-
-`{カテゴリ}_{環境}.js` の形式で命名する。
-
-| カテゴリ | 説明 | 例 |
-|---------|------|-----|
-| `develop` | アプリケーション開発タスク | `develop.js` |
-| `deploy` | デプロイスクリプト | `deploy_dev.js`, `deploy_stg.js` |
-| `provision` | IaC プロビジョニング | `provision_stg.js` |
-| `ssh` | SSH・踏み台操作 | `ssh_stg.js` |
-
-環境サフィックス: `_dev`（開発）、`_stg`（ステージング）、`_prd`（本番）、`_local`（ローカル）、なし（環境非依存）
-
-### 3. Gulp タスク命名規則
-
-`{カテゴリ}:{環境}:{アクション}` の形式で命名する。
-
-```
-deploy:dev:build          # 開発環境: ビルド
-provision:stg:vpc         # ステージング: VPC プロビジョニング
-dev:db:start              # アプリ開発: DB 起動
-tdd:backend               # TDD モード: バックエンド
-```
-
-### 4. スクリプトの基本構造
-
-すべてのスクリプトは以下のセクション構成に従う。
-
-```javascript
-'use strict';
-
-import path from 'path';
-import { execSync } from 'child_process';
-import { cleanDockerEnv } from './shared.js';
-
-// ============================================
-// 設定
-// ============================================
-
-const PREFIX = 'DEV'; // 環境変数プレフィックス
-
-/** サービス定義 */
-const SERVICES = [
-  { name: 'backend', port: 8080, label: 'バックエンド' },
-];
-
-// ============================================
-// ヘルパー関数
-// ============================================
-
-/**
- * JSDoc コメントで関数の目的・引数・戻り値を記述
- * @param {string} param - パラメータの説明
- * @returns {string}
- */
-function helperFunction(param) {
-  // 実装
-}
-
-// ============================================
-// Gulp タスク
-// ============================================
-
-export default function(gulp) {
-  gulp.task('category:action', (done) => {
-    // タスク実装
-    done();
-  });
-
-  // ヘルプタスク（必須）
-  gulp.task('category:help', (done) => {
-    console.log(`...`);
-    done();
-  });
-}
-```
-
-### 5. 実装ルール
-
-- **ESM**: `import` / `export` を使用。`require` は使わない
-- **strict mode**: ファイル先頭に `'use strict';`
-- **JSDoc**: すべての関数に JSDoc コメント
-- **DOCKER_HOST 対応**: Docker 操作は `cleanDockerEnv()` を使用
-- **ヘルプタスク**: 各カテゴリに `{category}:help` タスクを必ず作成
-- **共通関数**: `shared.js` と `ssh.js` の既存関数を活用
-
-### 6. 環境変数
-
-`.env` で管理し、環境プレフィックス（`DEV_`, `STG_`, `PRD_`）で名前空間を分離する。新しい環境変数を追加した場合は `.env.example` も更新する。
-
-### 7. 作成手順
-
-1. カテゴリと環境からファイル名を決定
-2. 基本構造テンプレートに従って実装
-3. `shared.js` / `ssh.js` の既存関数を活用
-4. ヘルプタスクを作成
-5. `gulpfile.js` にインポートとタスク登録を追加
-6. `npx gulp {category}:help` で動作確認
-7. `.env.example` に必要な環境変数を追記
-
-### 8. gulpfile.js への登録
-
-```javascript
-import newTasks from './ops/scripts/{new_file}.js';
-newTasks(gulp);
-```
-
-### 9. 対応する環境とスクリプト
-
-| 環境 | スクリプト | 関連スキル |
-|------|----------|----------|
-| アプリケーション開発 | `develop.js` | `operating-setup` |
-| 開発環境サーバー | `deploy_dev.js` | `operating-deploy` |
-| ステージング AWS | `deploy_stg.js`, `provision_stg.js`, `ssh_stg.js` | `operating-deploy`, `operating-provision` |
-| 本番 AWS | `deploy_prd.js`, `provision_prd.js`, `ssh_prd.js` | `operating-deploy`, `operating-provision` |
-
-### 10. 注意事項
-
-- 運用スクリプト作成ガイド（@docs/reference/運用スクリプト作成ガイド.md）を正として従う
-- Docker 操作では `cleanDockerEnv()` を必ず使う（`DOCKER_HOST` 環境変数による接続エラーを防ぐため）
-- 既存スクリプト（`shared.js`, `ssh.js`, `develop.js` 等）のパターンを踏襲する
-- 新しいスクリプト作成時は `.env.example` とドキュメントも同時に更新する
-
-### 関連スキル
-
-- `operating-setup` — 環境構築（スクリプト作成のトリガー）
-- `operating-deploy` — デプロイ・ロールバック
-- `operating-provision` — IaC プロビジョニング
-- `operating-cicd` — CI/CD パイプライン構築
-- `orchestrating-operation` — 運用フェーズ全体のワークフロー
+---
+name: operating-script
+description: 運用スクリプト（Gulp タスク）の作成・更新を支援。ops/scripts/ 配下に運用スクリプト作成ガイドに準拠したスクリプトを作成し、gulpfile.js に登録する。「Gulp タスクを作りたい」「デプロイスクリプトを作成したい」「運用タスクを自動化したい」「新しい環境の運用スクリプトを追加したい」「開発タスクランナーを更新したい」といった場面で発動する。環境構築完了後に対応する運用スクリプトを作成する場面でも積極的に使用する。
+---
+
+# 運用スクリプト作成
+
+環境構築やデプロイ、プロビジョニングなどの運用タスクを自動化する Gulp スクリプトを作成する。スクリプトはプロジェクトの運用効率を左右するため、ネーミング・構造・実装スタイルの一貫性が重要になる。
+
+## Instructions
+
+### 1. 参照ガイド
+
+@docs/reference/運用スクリプト作成ガイド.md に定義されたルールに従う。このガイドがネーミング規則・ディレクトリ構成・コーディング規約の正とする。
+
+### 2. ファイル命名規則
+
+`{カテゴリ}_{環境}.js` の形式で命名する。
+
+| カテゴリ | 説明 | 例 |
+|---------|------|-----|
+| `develop` | アプリケーション開発タスク | `develop.js` |
+| `deploy` | デプロイスクリプト | `deploy_dev.js`, `deploy_stg.js` |
+| `provision` | IaC プロビジョニング | `provision_stg.js` |
+| `ssh` | SSH・踏み台操作 | `ssh_stg.js` |
+
+環境サフィックス: `_dev`（開発）、`_stg`（ステージング）、`_prd`（本番）、`_local`（ローカル）、なし（環境非依存）
+
+### 3. Gulp タスク命名規則
+
+`{カテゴリ}:{環境}:{アクション}` の形式で命名する。
+
+```
+deploy:dev:build          # 開発環境: ビルド
+provision:stg:vpc         # ステージング: VPC プロビジョニング
+dev:db:start              # アプリ開発: DB 起動
+tdd:backend               # TDD モード: バックエンド
+```
+
+### 4. スクリプトの基本構造
+
+すべてのスクリプトは以下のセクション構成に従う。
+
+```javascript
+'use strict';
+
+import path from 'path';
+import { execSync } from 'child_process';
+import { cleanDockerEnv } from './shared.js';
+
+// ============================================
+// 設定
+// ============================================
+
+const PREFIX = 'DEV'; // 環境変数プレフィックス
+
+/** サービス定義 */
+const SERVICES = [
+  { name: 'backend', port: 8080, label: 'バックエンド' },
+];
+
+// ============================================
+// ヘルパー関数
+// ============================================
+
+/**
+ * JSDoc コメントで関数の目的・引数・戻り値を記述
+ * @param {string} param - パラメータの説明
+ * @returns {string}
+ */
+function helperFunction(param) {
+  // 実装
+}
+
+// ============================================
+// Gulp タスク
+// ============================================
+
+export default function(gulp) {
+  gulp.task('category:action', (done) => {
+    // タスク実装
+    done();
+  });
+
+  // ヘルプタスク（必須）
+  gulp.task('category:help', (done) => {
+    console.log(`...`);
+    done();
+  });
+}
+```
+
+### 5. 実装ルール
+
+- **ESM**: `import` / `export` を使用。`require` は使わない
+- **strict mode**: ファイル先頭に `'use strict';`
+- **JSDoc**: すべての関数に JSDoc コメント
+- **DOCKER_HOST 対応**: Docker 操作は `cleanDockerEnv()` を使用
+- **ヘルプタスク**: 各カテゴリに `{category}:help` タスクを必ず作成
+- **共通関数**: `shared.js` と `ssh.js` の既存関数を活用
+
+### 6. 環境変数
+
+`.env` で管理し、環境プレフィックス（`DEV_`, `STG_`, `PRD_`）で名前空間を分離する。新しい環境変数を追加した場合は `.env.example` も更新する。
+
+### 7. 作成手順
+
+1. カテゴリと環境からファイル名を決定
+2. 基本構造テンプレートに従って実装
+3. `shared.js` / `ssh.js` の既存関数を活用
+4. ヘルプタスクを作成
+5. `gulpfile.js` にインポートとタスク登録を追加
+6. `npx gulp {category}:help` で動作確認
+7. `.env.example` に必要な環境変数を追記
+
+### 8. gulpfile.js への登録
+
+```javascript
+import newTasks from './ops/scripts/{new_file}.js';
+newTasks(gulp);
+```
+
+### 9. 対応する環境とスクリプト
+
+| 環境 | スクリプト | 関連スキル |
+|------|----------|----------|
+| アプリケーション開発 | `develop.js` | `operating-setup` |
+| 開発環境サーバー | `deploy_dev.js` | `operating-deploy` |
+| ステージング AWS | `deploy_stg.js`, `provision_stg.js`, `ssh_stg.js` | `operating-deploy`, `operating-provision` |
+| 本番 AWS | `deploy_prd.js`, `provision_prd.js`, `ssh_prd.js` | `operating-deploy`, `operating-provision` |
+
+### 10. 注意事項
+
+- 運用スクリプト作成ガイド（@docs/reference/運用スクリプト作成ガイド.md）を正として従う
+- Docker 操作では `cleanDockerEnv()` を必ず使う（`DOCKER_HOST` 環境変数による接続エラーを防ぐため）
+- 既存スクリプト（`shared.js`, `ssh.js`, `develop.js` 等）のパターンを踏襲する
+- 新しいスクリプト作成時は `.env.example` とドキュメントも同時に更新する
+
+### 関連スキル
+
+- `operating-setup` — 環境構築（スクリプト作成のトリガー）
+- `operating-deploy` — デプロイ・ロールバック
+- `operating-provision` — IaC プロビジョニング
+- `operating-cicd` — CI/CD パイプライン構築
+- `orchestrating-operation` — 運用フェーズ全体のワークフロー

package/lib/assets/.claude/skills/operating-setup/SKILL.md

@@ -1,63 +1,63 @@
----
-name: operating-setup
-description: 環境構築を段階的に実行。アプリケーション開発環境→開発環境→ステージング→本番の順序でセットアップ。テンプレートから手順書を生成し環境を構築。環境構築やセットアップ、新しい環境の追加時に使用。
----
-
-# 環境構築
-
-開発ガイドの運用セクションに準拠し、各環境を段階的にセットアップします。テンプレートからプロジェクト固有の手順書を生成し、その手順書に従って環境を構築します。
-
-## Instructions
-
-### 1. 段階的構築フロー
-
-環境構築は以下の順序で段階的に進める。前段の環境が構築済みであることを確認してから次に進む。
-
-```
-アプリケーション開発環境 → 開発環境 → ステージング環境 → 本番環境
-```
-
-| 段階 | 環境 | テンプレート | 目的 |
-|------|------|-------------|------|
-| 1 | アプリケーション開発環境 | @docs/template/アプリケーション開発環境セットアップ手順書.md | ローカル開発の効率化 |
-| 2 | 開発環境 | @docs/template/開発環境セットアップ手順書.md | Docker ベースのチーム共有環境 |
-| 3 | ステージング環境 | @docs/template/AWSステージング環境セットアップ手順書.md | AWS 上の本番相当テスト環境 |
-| 4 | 本番環境 | @docs/template/AWSプロダクション環境セットアップ手順書.md | プロダクション環境 |
-
-### 2. 実行手順
-
-1. テンプレートを読み込む
-2. プレースホルダー（`{プロジェクト名}`、`{サービス名}` 等）をプロジェクト固有の値に置換
-3. `docs/operation/` 配下にプロジェクト固有の手順書を生成
-4. 手順書に従って環境を構築
-5. 構築完了後、運用スクリプトを作成（`operating-script` 参照）
-6. 手順書とドキュメントを更新
-
-### 3. 基本例
-
-```bash
-# アプリケーション開発環境のセットアップ
-# 「ローカル開発環境を構築して」
-
-# 開発環境のセットアップ（Docker ベース）
-# 「開発サーバーの環境を構築して」
-
-# ステージング環境のセットアップ（AWS）
-# 「ステージング環境を AWS にセットアップしたい」
-
-# 本番環境のセットアップ（AWS）
-# 「本番環境を構築して」
-```
-
-### 4. 注意事項
-
-- **段階的構築**: アプリ開発環境 → 開発環境 → ステージング → 本番の順序を厳守
-- **テンプレート活用**: 手順書テンプレートを基にプロジェクト固有の手順書を必ず作成してから環境構築を実行
-- **ドキュメント同期**: 環境変更時は手順書を同時更新
-- **本番環境の安全**: 本番環境の構築は十分な確認と承認のもとで実行
-
-### 関連スキル
-
-- `orchestrating-operation` : 運用フェーズ全体のワークフロー案内
-- `operating-provision` : IaC によるインフラプロビジョニング
-- `operating-cicd` : CI/CD パイプライン構築
+---
+name: operating-setup
+description: 環境構築を段階的に実行。アプリケーション開発環境→開発環境→ステージング→本番の順序でセットアップ。テンプレートから手順書を生成し環境を構築。環境構築やセットアップ、新しい環境の追加時に使用。
+---
+
+# 環境構築
+
+開発ガイドの運用セクションに準拠し、各環境を段階的にセットアップします。テンプレートからプロジェクト固有の手順書を生成し、その手順書に従って環境を構築します。
+
+## Instructions
+
+### 1. 段階的構築フロー
+
+環境構築は以下の順序で段階的に進める。前段の環境が構築済みであることを確認してから次に進む。
+
+```
+アプリケーション開発環境 → 開発環境 → ステージング環境 → 本番環境
+```
+
+| 段階 | 環境 | テンプレート | 目的 |
+|------|------|-------------|------|
+| 1 | アプリケーション開発環境 | @docs/template/アプリケーション開発環境セットアップ手順書.md | ローカル開発の効率化 |
+| 2 | 開発環境 | @docs/template/開発環境セットアップ手順書.md | Docker ベースのチーム共有環境 |
+| 3 | ステージング環境 | @docs/template/AWSステージング環境セットアップ手順書.md | AWS 上の本番相当テスト環境 |
+| 4 | 本番環境 | @docs/template/AWSプロダクション環境セットアップ手順書.md | プロダクション環境 |
+
+### 2. 実行手順
+
+1. テンプレートを読み込む
+2. プレースホルダー（`{プロジェクト名}`、`{サービス名}` 等）をプロジェクト固有の値に置換
+3. `docs/operation/` 配下にプロジェクト固有の手順書を生成
+4. 手順書に従って環境を構築
+5. 構築完了後、運用スクリプトを作成（`operating-script` 参照）
+6. 手順書とドキュメントを更新
+
+### 3. 基本例
+
+```bash
+# アプリケーション開発環境のセットアップ
+# 「ローカル開発環境を構築して」
+
+# 開発環境のセットアップ（Docker ベース）
+# 「開発サーバーの環境を構築して」
+
+# ステージング環境のセットアップ（AWS）
+# 「ステージング環境を AWS にセットアップしたい」
+
+# 本番環境のセットアップ（AWS）
+# 「本番環境を構築して」
+```
+
+### 4. 注意事項
+
+- **段階的構築**: アプリ開発環境 → 開発環境 → ステージング → 本番の順序を厳守
+- **テンプレート活用**: 手順書テンプレートを基にプロジェクト固有の手順書を必ず作成してから環境構築を実行
+- **ドキュメント同期**: 環境変更時は手順書を同時更新
+- **本番環境の安全**: 本番環境の構築は十分な確認と承認のもとで実行
+
+### 関連スキル
+
+- `orchestrating-operation` : 運用フェーズ全体のワークフロー案内
+- `operating-provision` : IaC によるインフラプロビジョニング
+- `operating-cicd` : CI/CD パイプライン構築

package/lib/assets/.claude/skills/orchestrating-analysis/SKILL.md

@@ -1,110 +1,110 @@
----
-name: orchestrating-analysis
-description: 分析フェーズ全体のワークフローをオーケストレーション。戦略→要件定義→機能要件→非機能要件の順序で各 analyzing-* スキルの実行を案内。分析フェーズの開始、全体像の把握、次に何を分析すべきかの判断、分析の進め方の相談時に使用。「分析を始めたい」「要件定義の次は何？」「設計ドキュメントを一通り作りたい」といった場面で発動する。
----
-
-# 分析フェーズオーケストレーション
-
-分析フェーズ全体の作業順序を案内する。各工程には専門の analyzing-* スキルがあるため、このスキルの役割は「何を・どの順序で・なぜその順序で」進めるかを示すことにある。
-
-開発ガイド（@docs/reference/開発ガイド.md）の分析セクションに定義されたフローに準拠する。
-
-## 分析フェーズの構成
-
-分析は **戦略 → 要件定義 → 機能要件 → 非機能要件** の 4 段階で進める。各段階の出力が次の段階の入力になるため、この順序を守ることが品質を確保する上で重要になる。
-
-### 段階 1: 戦略
-
-プロジェクトの「なぜ・何を・どうやって」を明確にする。ここが曖昧だと後工程すべてがブレるため、最初に固める。
-
-| 工程 | スキル | 成果物 |
-|------|--------|--------|
-| ビジネスアーキテクチャ分析 | `analyzing-business-architecture` | ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ |
-| インセプションデッキ作成 | `analyzing-inception-deck` | 10 の問いへの回答、概念アーキテクチャ、マイルストーン |
-
-### 段階 2: 要件定義
-
-システムが解決すべき問題と境界を定義する。RDRA 2.0 の体系に従い、システム価値→外部環境→境界の順で分析を進める。
-
-| 工程 | スキル | 成果物 |
-|------|--------|--------|
-| 要件定義 | `analyzing-requirements` | システムコンテキスト、要求モデル、業務フロー |
-| ユースケース・ユーザーストーリー | `analyzing-usecases` | ビジネスユースケース、システムユースケース、ユーザーストーリー |
-
-### 段階 3: 機能要件
-
-要件をどう実現するかの設計を行う。アーキテクチャが決まらないとデータモデルやドメインモデルの粒度が定まらないため、アーキテクチャ設計を先に行う。
-
-| 工程 | スキル | 成果物 |
-|------|--------|--------|
-| アーキテクチャ設計 | `analyzing-architecture` | バックエンド・フロントエンド・インフラ設計 |
-| データモデル設計 | `analyzing-data-model` | ER 図、テーブル定義 |
-| ドメインモデル設計 | `analyzing-domain-model` | エンティティ、値オブジェクト、集約 |
-| UI 設計 | `analyzing-ui-design` | 画面遷移図、画面イメージ |
-
-### 段階 4: 非機能要件
-
-システムの品質特性と運用方針を定義する。機能要件が見えた段階で策定することで、現実的な要件を設定できる。
-
-| 工程 | スキル | 成果物 |
-|------|--------|--------|
-| テスト戦略 | `analyzing-test-strategy` | テストピラミッド、テスト種別、カバレッジ目標 |
-| 非機能要件 | `analyzing-non-functional` | 性能・セキュリティ・可用性・保守性要件 |
-| 運用要件 | `analyzing-operation` | 運用フロー、監視設計、障害対応手順 |
-
-### 横断: 技術スタック・ADR
-
-技術スタック選定とアーキテクチャ決定記録は、分析の進行に応じて随時実施する。
-
-| 工程 | スキル | 成果物 |
-|------|--------|--------|
-| 技術スタック選定 | `analyzing-tech-stack` | 技術選定・評価結果 |
-| ADR 作成 | `creating-adr` | Architecture Decision Record |
-| 構成適用 | `apply-docs-structure` | 各工程の成果物の配置先判断（戦略は `strategy/` 単一、要件以降はプロジェクト別 `<category>/<project>/`） |
-| OKF 適用 | `apply-okf` | 各工程の成果物へのフロントマター付与・`index.md`/`log.md` 更新 |
-
-`docs/` がドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）を採用しているなら、各工程で成果物を書く**直前**に `apply-docs-structure` で配置先を判断する。戦略工程（企業分析・経営戦略・ビジネスアーキテクチャ・インセプションデッキ）の成果物は `docs/strategy/` に単一管理、要件定義以降の成果物はプロジェクト別カテゴリの `<category>/<project>/` 配下に置く。配置を書いた後に直すと索引・リンク・OKF の来歴すべての修正が必要になるため、判断は必ず書く前に行う。
-
-`docs/` が OKF 知識バンドル（ルート `index.md` に `okf_version` がある）なら、各工程で設計ドキュメントを作成・更新するたびに `apply-okf` を実行する。分析の成果物はエージェントが書き、人がレビューして確定する流れなので、作成時は `status: draft`、レビュー後に `verify --by human:<id>` で `stable` に昇格させる。工程ごとにこれを行えば、分析フェーズの終わりには「どの文書が誰に確認済みか」がフロントマターから読める状態になる。
-
-## 進め方
-
-### 現状を確認してから始める
-
-分析を開始する前に、プロジェクトの現状を把握する。既存のドキュメントやコードがある場合、ゼロから始める必要はない。
-
-1. `docs/` 配下の既存ドキュメントを確認
-2. `docs/design/` 配下の設計ドキュメントの有無を確認
-3. 未着手の工程を特定し、次のアクションを提案
-
-### 途中から再開する場合
-
-すべての工程を最初から実施する必要はない。既に完了している工程はスキップし、未着手または更新が必要な工程から再開する。
-
-**Example:**
-
-```
-ユーザー: 「要件定義は終わった。次は何をすればいい？」
-回答: 段階 3（機能要件）のアーキテクチャ設計から開始。
-      analyzing-architecture スキルを使ってアーキテクチャ設計を進める。
-```
-
-### 工程間のフィードバック
-
-分析は一方通行ではない。後工程の検討で前工程の見直しが必要になることがある。たとえば、データモデル設計中に要件の不足に気づいた場合は、要件定義に戻って補完する。
-
-## コンテキスト管理
-
-分析フェーズは多くの工程を含むため、長時間セッションになりやすい。以下のタイミングで `/compact` を実施し、コンテキストを圧縮する。
-
-- 分析工程 1 件が完了したとき
-- 設計ドキュメント 1 件の作成・更新が完了したとき
-- コミット完了後、次の工程に着手する前
-
-`/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する。これにより、圧縮後も作業の連続性を保てる。
-
-## 注意事項
-
-- 分析結果は開発フェーズで継続的に見直す。完璧を目指して分析を長引かせるより、十分な品質で開発に進み、フィードバックで改善する方が効果的
-- 各工程の成果物は `docs/` 配下に Markdown + PlantUML で文書化する。配置先は書く前に `apply-docs-structure` で判断し、OKF バンドルなら作成・更新のたびに `apply-okf` で規約を適用し、`gulp okf:check` が ERROR 0 の状態でコミットする
-- リリース計画（`planning-releases`）は分析フェーズの最後に、技術スタック選定後に実施する
+---
+name: orchestrating-analysis
+description: 分析フェーズ全体のワークフローをオーケストレーション。戦略→要件定義→機能要件→非機能要件の順序で各 analyzing-* スキルの実行を案内。分析フェーズの開始、全体像の把握、次に何を分析すべきかの判断、分析の進め方の相談時に使用。「分析を始めたい」「要件定義の次は何？」「設計ドキュメントを一通り作りたい」といった場面で発動する。
+---
+
+# 分析フェーズオーケストレーション
+
+分析フェーズ全体の作業順序を案内する。各工程には専門の analyzing-* スキルがあるため、このスキルの役割は「何を・どの順序で・なぜその順序で」進めるかを示すことにある。
+
+開発ガイド（@docs/reference/開発ガイド.md）の分析セクションに定義されたフローに準拠する。
+
+## 分析フェーズの構成
+
+分析は **戦略 → 要件定義 → 機能要件 → 非機能要件** の 4 段階で進める。各段階の出力が次の段階の入力になるため、この順序を守ることが品質を確保する上で重要になる。
+
+### 段階 1: 戦略
+
+プロジェクトの「なぜ・何を・どうやって」を明確にする。ここが曖昧だと後工程すべてがブレるため、最初に固める。
+
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| ビジネスアーキテクチャ分析 | `analyzing-business-architecture` | ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ |
+| インセプションデッキ作成 | `analyzing-inception-deck` | 10 の問いへの回答、概念アーキテクチャ、マイルストーン |
+
+### 段階 2: 要件定義
+
+システムが解決すべき問題と境界を定義する。RDRA 2.0 の体系に従い、システム価値→外部環境→境界の順で分析を進める。
+
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| 要件定義 | `analyzing-requirements` | システムコンテキスト、要求モデル、業務フロー |
+| ユースケース・ユーザーストーリー | `analyzing-usecases` | ビジネスユースケース、システムユースケース、ユーザーストーリー |
+
+### 段階 3: 機能要件
+
+要件をどう実現するかの設計を行う。アーキテクチャが決まらないとデータモデルやドメインモデルの粒度が定まらないため、アーキテクチャ設計を先に行う。
+
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| アーキテクチャ設計 | `analyzing-architecture` | バックエンド・フロントエンド・インフラ設計 |
+| データモデル設計 | `analyzing-data-model` | ER 図、テーブル定義 |
+| ドメインモデル設計 | `analyzing-domain-model` | エンティティ、値オブジェクト、集約 |
+| UI 設計 | `analyzing-ui-design` | 画面遷移図、画面イメージ |
+
+### 段階 4: 非機能要件
+
+システムの品質特性と運用方針を定義する。機能要件が見えた段階で策定することで、現実的な要件を設定できる。
+
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| テスト戦略 | `analyzing-test-strategy` | テストピラミッド、テスト種別、カバレッジ目標 |
+| 非機能要件 | `analyzing-non-functional` | 性能・セキュリティ・可用性・保守性要件 |
+| 運用要件 | `analyzing-operation` | 運用フロー、監視設計、障害対応手順 |
+
+### 横断: 技術スタック・ADR
+
+技術スタック選定とアーキテクチャ決定記録は、分析の進行に応じて随時実施する。
+
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| 技術スタック選定 | `analyzing-tech-stack` | 技術選定・評価結果 |
+| ADR 作成 | `creating-adr` | Architecture Decision Record |
+| 構成適用 | `apply-docs-structure` | 各工程の成果物の配置先判断（戦略は `strategy/` 単一、要件以降はプロジェクト別 `<category>/<project>/`） |
+| OKF 適用 | `apply-okf` | 各工程の成果物へのフロントマター付与・`index.md`/`log.md` 更新 |
+
+`docs/` がドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）を採用しているなら、各工程で成果物を書く**直前**に `apply-docs-structure` で配置先を判断する。戦略工程（企業分析・経営戦略・ビジネスアーキテクチャ・インセプションデッキ）の成果物は `docs/strategy/` に単一管理、要件定義以降の成果物はプロジェクト別カテゴリの `<category>/<project>/` 配下に置く。配置を書いた後に直すと索引・リンク・OKF の来歴すべての修正が必要になるため、判断は必ず書く前に行う。
+
+`docs/` が OKF 知識バンドル（ルート `index.md` に `okf_version` がある）なら、各工程で設計ドキュメントを作成・更新するたびに `apply-okf` を実行する。分析の成果物はエージェントが書き、人がレビューして確定する流れなので、作成時は `status: draft`、レビュー後に `verify --by human:<id>` で `stable` に昇格させる。工程ごとにこれを行えば、分析フェーズの終わりには「どの文書が誰に確認済みか」がフロントマターから読める状態になる。
+
+## 進め方
+
+### 現状を確認してから始める
+
+分析を開始する前に、プロジェクトの現状を把握する。既存のドキュメントやコードがある場合、ゼロから始める必要はない。
+
+1. `docs/` 配下の既存ドキュメントを確認
+2. `docs/design/` 配下の設計ドキュメントの有無を確認
+3. 未着手の工程を特定し、次のアクションを提案
+
+### 途中から再開する場合
+
+すべての工程を最初から実施する必要はない。既に完了している工程はスキップし、未着手または更新が必要な工程から再開する。
+
+**Example:**
+
+```
+ユーザー: 「要件定義は終わった。次は何をすればいい？」
+回答: 段階 3（機能要件）のアーキテクチャ設計から開始。
+      analyzing-architecture スキルを使ってアーキテクチャ設計を進める。
+```
+
+### 工程間のフィードバック
+
+分析は一方通行ではない。後工程の検討で前工程の見直しが必要になることがある。たとえば、データモデル設計中に要件の不足に気づいた場合は、要件定義に戻って補完する。
+
+## コンテキスト管理
+
+分析フェーズは多くの工程を含むため、長時間セッションになりやすい。以下のタイミングで `/compact` を実施し、コンテキストを圧縮する。
+
+- 分析工程 1 件が完了したとき
+- 設計ドキュメント 1 件の作成・更新が完了したとき
+- コミット完了後、次の工程に着手する前
+
+`/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する。これにより、圧縮後も作業の連続性を保てる。
+
+## 注意事項
+
+- 分析結果は開発フェーズで継続的に見直す。完璧を目指して分析を長引かせるより、十分な品質で開発に進み、フィードバックで改善する方が効果的
+- 各工程の成果物は `docs/` 配下に Markdown + PlantUML で文書化する。配置先は書く前に `apply-docs-structure` で判断し、OKF バンドルなら作成・更新のたびに `apply-okf` で規約を適用し、`gulp okf:check` が ERROR 0 の状態でコミットする
+- リリース計画（`planning-releases`）は分析フェーズの最後に、技術スタック選定後に実施する