@k2works/claude-code-booster 4.11.0 → 4.13.0

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

@@ -1,147 +1,147 @@
----
-name: operating-qt
-description: SonarQube によるコード品質管理を支援。ローカル SonarQube のセットアップ、スキャン実行、Quality Gate 確認、イシュー分析、メトリクス確認を行う。「SonarQube をセットアップしたい」「コード品質を分析したい」「Quality Gate を確認したい」「静的解析を実行したい」「SonarQube のイシューを確認したい」「コードの重複を調べたい」「カバレッジを SonarQube で見たい」といった場面で発動する。CI/CD パイプラインの品質ゲートチェックにも使用する。
----
-
-# コード品質管理（SonarQube）
-
-SonarQube を使った静的コード解析環境の構築と運用を支援する。SonarQube は Bug・Vulnerability・Code Smell・重複コード・カバレッジを一元的に可視化し、Quality Gate で品質基準を自動判定する。コード品質を継続的に計測することで、技術的負債の蓄積を早期に検知できる。
-
-## Instructions
-
-### 1. 参照ドキュメント
-
-@docs/reference/SonarQubeローカル環境セットアップ手順書.md にセットアップの詳細手順がある。環境構築時はこのドキュメントを参照する。
-
-### 2. 前提条件
-
-- Docker Desktop がインストール済みであること
-- RAM 4GB 以上を Docker Desktop に割り当て（推奨 6GB）
-- Windows の場合、WSL2 で `vm.max_map_count=524288` が設定済み
-
-### 3. コンポーネント構成
-
-| コンポーネント | コンテナ名 | ポート | イメージ |
-|--------------|-----------|-------|---------|
-| SonarQube | sonarqube | 9000 | `sonarqube:community` |
-| PostgreSQL | sonarqube-db | 内部 | `postgres:16-alpine` |
-
-Docker Compose ファイルは `ops/docker/sonarqube-local/docker-compose.yml` に配置する。
-
-### 4. Gulp タスク
-
-既存の `ops/scripts/sonar_local.js` で以下のタスクが利用可能。
-
-**セットアップ:**
-
-```bash
-npx gulp sonar-local:setup      # 初回セットアップ（Docker Compose 配置→起動→ヘルスチェック）
-```
-
-**コンテナ操作:**
-
-```bash
-npx gulp sonar-local:start      # 起動
-npx gulp sonar-local:stop       # 停止
-npx gulp sonar-local:restart    # 再起動
-npx gulp sonar-local:status     # 状態確認
-npx gulp sonar-local:logs       # ログ表示
-npx gulp sonar-local:open       # ダッシュボードをブラウザで開く
-```
-
-**スキャン・分析:**
-
-```bash
-npx gulp sonar-local:scan       # 全プロジェクトのスキャン実行
-npx gulp sonar-local:gate       # Quality Gate ステータス確認
-npx gulp sonar-local:issues     # メトリクス・イシュー・重複コード詳細
-npx gulp sonar-local:check      # スキャン → Quality Gate の一連フロー
-```
-
-**管理:**
-
-```bash
-npx gulp sonar-local:clean      # 環境完全削除（データ含む）
-npx gulp sonar-local:help       # ヘルプ表示
-```
-
-### 5. プロジェクト設定
-
-プロジェクトルートに `sonarqube.config.json` を配置して複数プロジェクトのスキャンを設定する。
-
-```json
-{
-  "projects": [
-    {
-      "name": "backend",
-      "label": "Backend",
-      "projectKey": "fleur-memoire-backend",
-      "scanType": "sonar-scanner",
-      "srcDir": "apps/backend"
-    },
-    {
-      "name": "frontend",
-      "label": "Frontend",
-      "projectKey": "fleur-memoire-frontend",
-      "scanType": "sonar-scanner",
-      "srcDir": "apps/frontend"
-    }
-  ]
-}
-```
-
-`scanType` は `sonar-scanner`（Node.js）、`sbt`、`maven`、`gradle` に対応。
-
-### 6. 環境変数
-
-`.env` に以下を設定する。
-
-| 変数 | 説明 | デフォルト |
-|------|------|----------|
-| `LOCAL_SONAR_PORT` | SonarQube ポート | 9000 |
-| `LOCAL_SONAR_DB_PASSWORD` | DB パスワード | sonarqube_password |
-| `SONAR_HOST_URL` | SonarQube URL | http://localhost:9000 |
-| `SONAR_TOKEN` | 分析トークン（スキャン時必須） | — |
-| `SONAR_PROJECT_KEY` | Quality Gate / Issues 対象キー | — |
-
-### 7. 初回セットアップフロー
-
-1. `npx gulp sonar-local:setup` でコンテナを構築・起動
-2. ブラウザで `http://localhost:9000` にアクセス（初期認証: admin / admin）
-3. admin パスワードを変更
-4. 分析トークンを生成（My Account → Security → Generate Tokens）
-5. `.env` に `SONAR_TOKEN=<生成したトークン>` を追加
-6. `sonarqube.config.json` を作成（複数プロジェクト対応時）
-7. `npx gulp sonar-local:scan` でスキャン実行
-
-### 8. 品質基準
-
-テスト戦略（@docs/design/test_strategy.md）で定義されたカバレッジ目標と SonarQube の Quality Gate を連携する。
-
-| メトリクス | 目標 |
-|-----------|------|
-| カバレッジ | ドメイン層 90%、全体 80% |
-| 重複率 | 3% 未満 |
-| Bug | 0 件 |
-| Vulnerability | 0 件 |
-| Code Smell | 可能な限り 0 件 |
-
-### 9. CI/CD 連携
-
-GitHub Actions で SonarQube スキャンを実行する場合は `operating-cicd` スキルを参照する。ローカルの SonarQube はあくまで開発中の品質確認用で、CI/CD では SonarCloud や別途ホスティングされた SonarQube を使用する。
-
-### 10. トラブルシューティング
-
-| 症状 | 原因 | 対処 |
-|------|------|------|
-| コンテナ起動後すぐ停止 | `vm.max_map_count` 不足 | WSL2 / Docker VM で `524288` に設定 |
-| ヘルスチェックがタイムアウト | メモリ不足 | Docker Desktop の RAM 割り当てを増やす |
-| スキャン時 401 エラー | トークン未設定 or 無効 | `.env` の `SONAR_TOKEN` を確認 |
-| `DOCKER_HOST` 接続エラー | 環境変数の干渉 | `cleanDockerEnv()` を使用（`shared.js`） |
-
-### 関連スキル
-
-- `operating-script` — 運用スクリプト作成ガイドに準拠したスクリプト作成
-- `operating-cicd` — CI/CD パイプラインでの品質ゲート連携
-- `operating-setup` — 環境構築の段階的実行
-- `orchestrating-operation` — 運用フェーズ全体のワークフロー
+---
+name: operating-qt
+description: SonarQube によるコード品質管理を支援。ローカル SonarQube のセットアップ、スキャン実行、Quality Gate 確認、イシュー分析、メトリクス確認を行う。「SonarQube をセットアップしたい」「コード品質を分析したい」「Quality Gate を確認したい」「静的解析を実行したい」「SonarQube のイシューを確認したい」「コードの重複を調べたい」「カバレッジを SonarQube で見たい」といった場面で発動する。CI/CD パイプラインの品質ゲートチェックにも使用する。
+---
+
+# コード品質管理（SonarQube）
+
+SonarQube を使った静的コード解析環境の構築と運用を支援する。SonarQube は Bug・Vulnerability・Code Smell・重複コード・カバレッジを一元的に可視化し、Quality Gate で品質基準を自動判定する。コード品質を継続的に計測することで、技術的負債の蓄積を早期に検知できる。
+
+## Instructions
+
+### 1. 参照ドキュメント
+
+@docs/reference/SonarQubeローカル環境セットアップ手順書.md にセットアップの詳細手順がある。環境構築時はこのドキュメントを参照する。
+
+### 2. 前提条件
+
+- Docker Desktop がインストール済みであること
+- RAM 4GB 以上を Docker Desktop に割り当て（推奨 6GB）
+- Windows の場合、WSL2 で `vm.max_map_count=524288` が設定済み
+
+### 3. コンポーネント構成
+
+| コンポーネント | コンテナ名 | ポート | イメージ |
+|--------------|-----------|-------|---------|
+| SonarQube | sonarqube | 9000 | `sonarqube:community` |
+| PostgreSQL | sonarqube-db | 内部 | `postgres:16-alpine` |
+
+Docker Compose ファイルは `ops/docker/sonarqube-local/docker-compose.yml` に配置する。
+
+### 4. Gulp タスク
+
+既存の `ops/scripts/sonar_local.js` で以下のタスクが利用可能。
+
+**セットアップ:**
+
+```bash
+npx gulp sonar-local:setup      # 初回セットアップ（Docker Compose 配置→起動→ヘルスチェック）
+```
+
+**コンテナ操作:**
+
+```bash
+npx gulp sonar-local:start      # 起動
+npx gulp sonar-local:stop       # 停止
+npx gulp sonar-local:restart    # 再起動
+npx gulp sonar-local:status     # 状態確認
+npx gulp sonar-local:logs       # ログ表示
+npx gulp sonar-local:open       # ダッシュボードをブラウザで開く
+```
+
+**スキャン・分析:**
+
+```bash
+npx gulp sonar-local:scan       # 全プロジェクトのスキャン実行
+npx gulp sonar-local:gate       # Quality Gate ステータス確認
+npx gulp sonar-local:issues     # メトリクス・イシュー・重複コード詳細
+npx gulp sonar-local:check      # スキャン → Quality Gate の一連フロー
+```
+
+**管理:**
+
+```bash
+npx gulp sonar-local:clean      # 環境完全削除（データ含む）
+npx gulp sonar-local:help       # ヘルプ表示
+```
+
+### 5. プロジェクト設定
+
+プロジェクトルートに `sonarqube.config.json` を配置して複数プロジェクトのスキャンを設定する。
+
+```json
+{
+  "projects": [
+    {
+      "name": "backend",
+      "label": "Backend",
+      "projectKey": "fleur-memoire-backend",
+      "scanType": "sonar-scanner",
+      "srcDir": "apps/backend"
+    },
+    {
+      "name": "frontend",
+      "label": "Frontend",
+      "projectKey": "fleur-memoire-frontend",
+      "scanType": "sonar-scanner",
+      "srcDir": "apps/frontend"
+    }
+  ]
+}
+```
+
+`scanType` は `sonar-scanner`（Node.js）、`sbt`、`maven`、`gradle` に対応。
+
+### 6. 環境変数
+
+`.env` に以下を設定する。
+
+| 変数 | 説明 | デフォルト |
+|------|------|----------|
+| `LOCAL_SONAR_PORT` | SonarQube ポート | 9000 |
+| `LOCAL_SONAR_DB_PASSWORD` | DB パスワード | sonarqube_password |
+| `SONAR_HOST_URL` | SonarQube URL | http://localhost:9000 |
+| `SONAR_TOKEN` | 分析トークン（スキャン時必須） | — |
+| `SONAR_PROJECT_KEY` | Quality Gate / Issues 対象キー | — |
+
+### 7. 初回セットアップフロー
+
+1. `npx gulp sonar-local:setup` でコンテナを構築・起動
+2. ブラウザで `http://localhost:9000` にアクセス（初期認証: admin / admin）
+3. admin パスワードを変更
+4. 分析トークンを生成（My Account → Security → Generate Tokens）
+5. `.env` に `SONAR_TOKEN=<生成したトークン>` を追加
+6. `sonarqube.config.json` を作成（複数プロジェクト対応時）
+7. `npx gulp sonar-local:scan` でスキャン実行
+
+### 8. 品質基準
+
+テスト戦略（@docs/design/test_strategy.md）で定義されたカバレッジ目標と SonarQube の Quality Gate を連携する。
+
+| メトリクス | 目標 |
+|-----------|------|
+| カバレッジ | ドメイン層 90%、全体 80% |
+| 重複率 | 3% 未満 |
+| Bug | 0 件 |
+| Vulnerability | 0 件 |
+| Code Smell | 可能な限り 0 件 |
+
+### 9. CI/CD 連携
+
+GitHub Actions で SonarQube スキャンを実行する場合は `operating-cicd` スキルを参照する。ローカルの SonarQube はあくまで開発中の品質確認用で、CI/CD では SonarCloud や別途ホスティングされた SonarQube を使用する。
+
+### 10. トラブルシューティング
+
+| 症状 | 原因 | 対処 |
+|------|------|------|
+| コンテナ起動後すぐ停止 | `vm.max_map_count` 不足 | WSL2 / Docker VM で `524288` に設定 |
+| ヘルスチェックがタイムアウト | メモリ不足 | Docker Desktop の RAM 割り当てを増やす |
+| スキャン時 401 エラー | トークン未設定 or 無効 | `.env` の `SONAR_TOKEN` を確認 |
+| `DOCKER_HOST` 接続エラー | 環境変数の干渉 | `cleanDockerEnv()` を使用（`shared.js`） |
+
+### 関連スキル
+
+- `operating-script` — 運用スクリプト作成ガイドに準拠したスクリプト作成
+- `operating-cicd` — CI/CD パイプラインでの品質ゲート連携
+- `operating-setup` — 環境構築の段階的実行
+- `orchestrating-operation` — 運用フェーズ全体のワークフロー

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

@@ -1,171 +1,171 @@
----
-name: operating-review
-description: 運用成果物のマルチパースペクティブレビューを実施。XP エージェント（アーキテクト、テスター、プロジェクトマネージャー）を並列起動し、インフラ設計・セキュリティ・信頼性・運用性の観点からフィードバックを収集・統合する。「インフラ設定をレビューして」「CI/CD パイプラインをチェックして」「デプロイ設定をレビュー」「Terraform コードをレビュー」「運用スクリプトを確認して」「Dockerfile をレビュー」といった場面で発動する。運用成果物に対するレビュー依頼があれば積極的に使用すること。
----
-
-# 運用成果物レビュー
-
-運用フェーズの成果物（インフラ定義、CI/CD パイプライン、デプロイ設定、運用スクリプト、Dockerfile、環境設定など）を複数の XP エージェントで並列レビューし、信頼性・セキュリティ・運用性の観点からフィードバックを統合する。
-
-## レビューの価値
-
-運用成果物の不備は本番障害に直結する。インフラ設定のミス、セキュリティの穴、デプロイ手順の不備は、発見が遅れるほど影響が大きくなる。複数の専門的視点で事前に検証することで、本番環境のリスクを最小化する。
-
-## レビューエージェント
-
-| エージェント | 視点 | 着眼点 |
-|:---|:---|:---|
-| `xp-architect` | インフラ設計 | アーキテクチャとの整合、スケーラビリティ、可用性、コスト効率、IaC のモジュール化 |
-| `xp-tester` | 信頼性・セキュリティ | セキュリティ設定、権限の最小化、障害シナリオ、ロールバック手順、テスト可能性 |
-| `xp-project-manager` | 運用性・持続可能性 | 運用手順の明確さ、ドキュメントの十分性、チームへの影響、持続可能なペースの維持 |
-
-## レビュー対象と重点観点
-
-| 成果物 | 重点観点 |
-|:---|:---|
-| Terraform / IaC コード | セキュリティグループ、IAM ポリシー、状態管理、モジュール設計 |
-| CI/CD パイプライン | ビルドの再現性、テスト網羅性、シークレット管理、OIDC 認証 |
-| Dockerfile / docker-compose | ベースイメージの安全性、レイヤーの最適化、マルチステージビルド |
-| デプロイ設定 | ロールバック手順、ヘルスチェック、環境変数管理、段階的デプロイ |
-| 運用スクリプト | エラーハンドリング、冪等性、ログ出力、ドキュメント整合性 |
-| 環境設定 | 環境間の差異管理、シークレット管理、設定の外部化 |
-
-## レビューワークフロー
-
-### 1. レビュー対象の特定
-
-レビュー対象のファイルを特定する。ユーザーが明示的に指定しない場合は、以下のディレクトリを確認する。
-
-- `ops/` — 運用スクリプト、Gulp タスク
-- `infra/` / `terraform/` — IaC 定義
-- `.github/workflows/` — CI/CD パイプライン
-- `docker-compose*.yml` / `Dockerfile*` — コンテナ定義
-- `docs/operation/` — 運用手順書
-
-### 2. エージェントの並列起動
-
-Agent ツールを使い、3 つのエージェントを **同一メッセージで並列起動** する。各エージェントには以下を指示する。
-
-```
-あなたは {エージェント名} です。
-.claude/agents/{エージェント名}.md の定義に従ってレビューしてください。
-
-## レビュー対象
-{ファイルパスとその内容}
-
-## 関連コンテキスト
-{関連する設計ドキュメント、運用要件、環境情報}
-
-## レビュー観点
-{エージェント固有の着眼点}
-
-## 出力形式
-以下の形式でフィードバックを返してください：
-
-### 評価サマリー
-（1-2 文で全体評価）
-
-### 良い点
-- （具体的に）
-
-### 改善提案
-- 【重要度: 高/中/低】（ファイル:行番号）（具体的な改善提案と理由）
-
-### セキュリティ懸念
-- （権限、シークレット、ネットワーク設定に関する懸念）
-
-### 運用リスク
-- （障害時の影響範囲、復旧手順の有無、監視の網羅性）
-
-### スコープ外の発見
-- （レビュー対象外だが報告すべき問題）
-```
-
-#### Agent ツールが利用できない場合のフォールバック
-
-Agent ツールが利用できない環境では、3 つの視点を逐次的にシミュレートする。各エージェントの定義ファイル（`.claude/agents/{エージェント名}.md`）を読み、その視点でレビューを順次実施する。出力形式は同一のテンプレートに従う。
-
-### 3. フィードバックの統合
-
-全エージェントのフィードバックを受け取った後、以下の形式で統合レポートを作成する。
-
-```markdown
-## 運用レビュー結果
-
-### レビュー対象
-- {ファイル名 / 設定名}
-
-### 総合評価
-（全エージェントの評価を統合した 2-3 文の評価）
-
-### 改善提案（重要度順）
-
-#### 高（本番適用前に対応必須）
-| # | 提案 | 箇所 | 指摘元 | 理由 |
-|---|------|------|--------|------|
-
-#### 中（対応推奨）
-| # | 提案 | 箇所 | 指摘元 | 理由 |
-|---|------|------|--------|------|
-
-#### 低（改善の余地あり）
-| # | 提案 | 箇所 | 指摘元 | 理由 |
-|---|------|------|--------|------|
-
-### 矛盾事項
-
-複数エージェントの指摘が相反する場合、ここに記載する。
-
-| # | 視点 A | 視点 B | 論点 | 推奨判断 |
-|---|--------|--------|------|----------|
-
-### エージェント別フィードバック詳細
-
-<details>
-<summary>xp-architect（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-tester（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-project-manager（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-```
-
-### 4. 改善アクションの提案
-
-重要度「高」の指摘（特にセキュリティ関連）は具体的な修正内容を提案する。本番環境に関する変更は、適用前にユーザーの明示的な承認を得る。
-
-### 5. レビュー結果の保存
-
-統合レポートを `docs/review/{対象名}_review_{YYYYMMDD}.md` に保存する。過去のレビュー結果と比較できるようにし、改善のトレーサビリティを確保する。
-
-## レビュー完了条件
-
-以下をすべて満たした場合にレビュー完了とする。
-
-- 全エージェントのフィードバックが収集済み
-- 統合レポートが作成済み
-- 重要度「高」の指摘について対応方針（修正する / 許容する / 保留する）が決定済み
-- レビュー結果がドキュメントとして保存済み
-
-## 注意事項
-
-- セキュリティに関する指摘は常に重要度「高」として扱う
-- 本番環境に影響する変更は慎重に扱い、段階的な適用を推奨する
-- IaC の変更は `plan` 結果を確認してから `apply` する原則を維持する
-- 運用手順書の更新漏れがないかも確認する
-
-## 関連スキル
-
-- `orchestrating-operation` — 運用フェーズの全体ワークフロー
-- `operating-setup` — 環境構築
-- `operating-provision` — IaC プロビジョニング
-- `operating-cicd` — CI/CD パイプライン構築
-- `operating-deploy` — デプロイ・ロールバック
-- `git-commit` — レビュー結果の保存後のコミット
+---
+name: operating-review
+description: 運用成果物のマルチパースペクティブレビューを実施。XP エージェント（アーキテクト、テスター、プロジェクトマネージャー）を並列起動し、インフラ設計・セキュリティ・信頼性・運用性の観点からフィードバックを収集・統合する。「インフラ設定をレビューして」「CI/CD パイプラインをチェックして」「デプロイ設定をレビュー」「Terraform コードをレビュー」「運用スクリプトを確認して」「Dockerfile をレビュー」といった場面で発動する。運用成果物に対するレビュー依頼があれば積極的に使用すること。
+---
+
+# 運用成果物レビュー
+
+運用フェーズの成果物（インフラ定義、CI/CD パイプライン、デプロイ設定、運用スクリプト、Dockerfile、環境設定など）を複数の XP エージェントで並列レビューし、信頼性・セキュリティ・運用性の観点からフィードバックを統合する。
+
+## レビューの価値
+
+運用成果物の不備は本番障害に直結する。インフラ設定のミス、セキュリティの穴、デプロイ手順の不備は、発見が遅れるほど影響が大きくなる。複数の専門的視点で事前に検証することで、本番環境のリスクを最小化する。
+
+## レビューエージェント
+
+| エージェント | 視点 | 着眼点 |
+|:---|:---|:---|
+| `xp-architect` | インフラ設計 | アーキテクチャとの整合、スケーラビリティ、可用性、コスト効率、IaC のモジュール化 |
+| `xp-tester` | 信頼性・セキュリティ | セキュリティ設定、権限の最小化、障害シナリオ、ロールバック手順、テスト可能性 |
+| `xp-project-manager` | 運用性・持続可能性 | 運用手順の明確さ、ドキュメントの十分性、チームへの影響、持続可能なペースの維持 |
+
+## レビュー対象と重点観点
+
+| 成果物 | 重点観点 |
+|:---|:---|
+| Terraform / IaC コード | セキュリティグループ、IAM ポリシー、状態管理、モジュール設計 |
+| CI/CD パイプライン | ビルドの再現性、テスト網羅性、シークレット管理、OIDC 認証 |
+| Dockerfile / docker-compose | ベースイメージの安全性、レイヤーの最適化、マルチステージビルド |
+| デプロイ設定 | ロールバック手順、ヘルスチェック、環境変数管理、段階的デプロイ |
+| 運用スクリプト | エラーハンドリング、冪等性、ログ出力、ドキュメント整合性 |
+| 環境設定 | 環境間の差異管理、シークレット管理、設定の外部化 |
+
+## レビューワークフロー
+
+### 1. レビュー対象の特定
+
+レビュー対象のファイルを特定する。ユーザーが明示的に指定しない場合は、以下のディレクトリを確認する。
+
+- `ops/` — 運用スクリプト、Gulp タスク
+- `infra/` / `terraform/` — IaC 定義
+- `.github/workflows/` — CI/CD パイプライン
+- `docker-compose*.yml` / `Dockerfile*` — コンテナ定義
+- `docs/operation/` — 運用手順書
+
+### 2. エージェントの並列起動
+
+Agent ツールを使い、3 つのエージェントを **同一メッセージで並列起動** する。各エージェントには以下を指示する。
+
+```
+あなたは {エージェント名} です。
+.claude/agents/{エージェント名}.md の定義に従ってレビューしてください。
+
+## レビュー対象
+{ファイルパスとその内容}
+
+## 関連コンテキスト
+{関連する設計ドキュメント、運用要件、環境情報}
+
+## レビュー観点
+{エージェント固有の着眼点}
+
+## 出力形式
+以下の形式でフィードバックを返してください：
+
+### 評価サマリー
+（1-2 文で全体評価）
+
+### 良い点
+- （具体的に）
+
+### 改善提案
+- 【重要度: 高/中/低】（ファイル:行番号）（具体的な改善提案と理由）
+
+### セキュリティ懸念
+- （権限、シークレット、ネットワーク設定に関する懸念）
+
+### 運用リスク
+- （障害時の影響範囲、復旧手順の有無、監視の網羅性）
+
+### スコープ外の発見
+- （レビュー対象外だが報告すべき問題）
+```
+
+#### Agent ツールが利用できない場合のフォールバック
+
+Agent ツールが利用できない環境では、3 つの視点を逐次的にシミュレートする。各エージェントの定義ファイル（`.claude/agents/{エージェント名}.md`）を読み、その視点でレビューを順次実施する。出力形式は同一のテンプレートに従う。
+
+### 3. フィードバックの統合
+
+全エージェントのフィードバックを受け取った後、以下の形式で統合レポートを作成する。
+
+```markdown
+## 運用レビュー結果
+
+### レビュー対象
+- {ファイル名 / 設定名}
+
+### 総合評価
+（全エージェントの評価を統合した 2-3 文の評価）
+
+### 改善提案（重要度順）
+
+#### 高（本番適用前に対応必須）
+| # | 提案 | 箇所 | 指摘元 | 理由 |
+|---|------|------|--------|------|
+
+#### 中（対応推奨）
+| # | 提案 | 箇所 | 指摘元 | 理由 |
+|---|------|------|--------|------|
+
+#### 低（改善の余地あり）
+| # | 提案 | 箇所 | 指摘元 | 理由 |
+|---|------|------|--------|------|
+
+### 矛盾事項
+
+複数エージェントの指摘が相反する場合、ここに記載する。
+
+| # | 視点 A | 視点 B | 論点 | 推奨判断 |
+|---|--------|--------|------|----------|
+
+### エージェント別フィードバック詳細
+
+<details>
+<summary>xp-architect（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-tester（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-project-manager（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+```
+
+### 4. 改善アクションの提案
+
+重要度「高」の指摘（特にセキュリティ関連）は具体的な修正内容を提案する。本番環境に関する変更は、適用前にユーザーの明示的な承認を得る。
+
+### 5. レビュー結果の保存
+
+統合レポートを `docs/review/{対象名}_review_{YYYYMMDD}.md` に保存する。過去のレビュー結果と比較できるようにし、改善のトレーサビリティを確保する。
+
+## レビュー完了条件
+
+以下をすべて満たした場合にレビュー完了とする。
+
+- 全エージェントのフィードバックが収集済み
+- 統合レポートが作成済み
+- 重要度「高」の指摘について対応方針（修正する / 許容する / 保留する）が決定済み
+- レビュー結果がドキュメントとして保存済み
+
+## 注意事項
+
+- セキュリティに関する指摘は常に重要度「高」として扱う
+- 本番環境に影響する変更は慎重に扱い、段階的な適用を推奨する
+- IaC の変更は `plan` 結果を確認してから `apply` する原則を維持する
+- 運用手順書の更新漏れがないかも確認する
+
+## 関連スキル
+
+- `orchestrating-operation` — 運用フェーズの全体ワークフロー
+- `operating-setup` — 環境構築
+- `operating-provision` — IaC プロビジョニング
+- `operating-cicd` — CI/CD パイプライン構築
+- `operating-deploy` — デプロイ・ロールバック
+- `git-commit` — レビュー結果の保存後のコミット