@k2works/claude-code-booster 3.5.0 → 3.6.0

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

@@ -1,161 +1,162 @@
----
-name: orchestrating-development
-description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
----
-
-# 開発フェーズオーケストレーション
-
-開発フェーズ全体のワークフローを案内する。TDD サイクルに従い、バックエンド→フロントエンドの順序で品質を担保しながら開発を進める。
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | 開発フェーズ全体のワークフローを表示 |
-| `--codex` | Claude（計画・設計・受入）と Codex（実装）の分業体制で開発 |
-
-## 開発フェーズの全体像
-
-1. **バックエンド開発** (Skill: `developing-backend`) — インサイドアウトアプローチ推奨
-2. **フロントエンド開発** (Skill: `developing-frontend`) — アウトサイドインアプローチ推奨
-
-各開発で Red-Green-Refactor サイクルを厳密に実行する。テストなしでプロダクションコードを書かない。
-
-### レビューポイント
-
-コーディングとテストガイドのイテレーション開発フローに準拠し、以下のタイミングでレビュースキルを発動する。
-
-| タイミング | スキル | 説明 |
-|-----------|--------|------|
-| TODO 完了時（コードレビュー） | `developing-review` | TDD サイクルで TODO を完了するたびにコード品質・テスト品質・設計整合性をレビュー |
-| 受け入れ前（品質チェック） | `operating-qt` | SonarQube によるコード品質分析・Quality Gate 確認を実施し、品質基準を満たしていることを検証 |
-| イテレーション完了時（ユーザーレビュー） | `analyzing-review` | 受け入れフェーズでユーザー視点・プロダクト視点からの成果物レビュー |
-
-## TDD サイクル
-
-TDD は「テストを書いてからコードを書く」手順ではなく、「設計を小さなフィードバックループで検証する」手法。10-15 分で 1 サイクルを完了させる。
-
-1. **Red**: 失敗するテストを最初に書く
-2. **Green**: テストを通す最小限のコードを実装する
-3. **Refactor**: 重複を除去し設計を改善する
-4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
-
-## 参照ドキュメント
-
-- @docs/reference/コーディングとテストガイド.md — TDD ワークフロー詳細
-- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md — Codex 連携フロー
-- @docs/design/architecture.md, @docs/design/architecture_backend.md, @docs/design/architecture_frontend.md
-- @docs/design/data-model.md, @docs/design/domain-model.md, @docs/design/tech_stack.md
-- @docs/design/ui-design.md, @docs/design/test_strategy.md
-- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
-
-## Codex 分業モード（--codex）
-
-Claude と Codex の役割を分離し、計画・設計・受入を Claude が担い、実装を Codex に委譲する。
-
-**前提条件**: Codex MCP サーバーが設定済みであること（@docs/reference/CodexCLIMCPサーバー設定手順.md 参照）
-
-### 役割分担
-
-| フェーズ | 担当 | 責務 |
-|---------|------|------|
-| 計画 | Claude | 要件分析、タスク分解、優先度決定 |
-| 設計 | Claude | API 設計、UI 設計、データモデル設計 |
-| 実装 | Codex | コード実装、ユニットテスト作成 |
-| 受入 | Claude | 設計レビュー、E2E テスト作成・実行、品質確認 |
-
-### 開発フロー
-
-```mermaid
-graph LR
-    A[計画] --> B[設計]
-    B --> C[実装指示]
-    C --> D[受入]
-    subgraph Claude
-    A
-    B
-    D
-    end
-    subgraph Codex
-    C
-    end
-```
-
-### 指示サイズ
-
-| 粒度 | 推奨度 | 説明 |
-|------|--------|------|
-| タスク単位（1-3 ファイル） | 推奨 | 1 つのコンポーネントや機能単位 |
-| 機能単位（3-5 ファイル） | 注意 | 進捗確認を頻繁に行う |
-| ユーザーストーリー単位 | 非推奨 | タスクに分割して実行する |
-
-### Codex への指示例
-
-```
-mcp__codex__codex
-  prompt: |
-    お知らせ管理機能を実装してください。
-    ## 開発ガイド
-    docs/reference/コーディングとテストガイド.md に従って実装すること。
-    特に TDD サイクル（Red-Green-Refactor）を厳守すること。
-    ## タスク
-    1. AuthContext に role と canManageAnnouncements を追加
-    2. API クライアントに create/update/delete 関数を追加
-    ## 完了条件
-    - ESLint エラーなし
-    - 既存テストがパス
-    - TDD サイクルに従って実装
-  sandbox: danger-full-access
-  approval-policy: never
-  cwd: プロジェクトルート
-```
-
-### 受入基準
-
-- [ ] すべての受入条件が満たされている
-- [ ] E2E テストがすべてパス
-- [ ] ESLint エラーがない
-- [ ] 既存テストが壊れていない
-
-### Codex が書き込みできない場合
-
-1. Claude が勝手に直接編集を進めてはいけない
-2. ユーザーに状況を報告し、確認を待つ
-3. ユーザーの許可を得てから代替手段を実行する
-
-## 途中から再開
-
-開発セッションの途中から再開する場合は、まず現在の実装状況を確認する。
-
-**Example:**
-
-```
-ユーザー: 「バックエンドの認証機能は実装済み。次の機能に進みたい」
-回答: イテレーション計画を確認し、次のユーザーストーリーを特定する。
-      既存コードのテスト結果を確認し、Green 状態であることを検証してから
-      次のタスクの Red フェーズに進む。
-```
-
-## コンテキスト管理
-
-タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
-
-- ユーザーストーリー 1 件の実装完了時、TDD サイクルを数回繰り返した後、コミット完了後に実施する
-- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
-
-## 注意事項
-
-- プロジェクトのテスト環境が設定済みであること（前提条件）
-- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
-- コミット前に必ず品質チェックリストを実行する
-- TODO 駆動開発でタスクを細かく分割してから実装を開始する
-- Rule of Three: 同じコードが 3 回現れたらリファクタリングする
-
-## 関連スキル
-
-- `developing-backend` — バックエンド TDD 開発
-- `developing-frontend` — フロントエンド TDD 開発
-- `developing-review` — 開発成果物のマルチパースペクティブレビュー（TODO 完了時のコードレビュー）
-- `analyzing-review` — 分析成果物のマルチパースペクティブレビュー（イテレーション完了時のユーザーレビュー）
-- `operating-qt` — コード品質管理（受け入れ前の SonarQube 品質チェック）
-- `developing-release` — リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）
+---
+name: orchestrating-development
+description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
+---
+
+# 開発フェーズオーケストレーション
+
+開発フェーズ全体のワークフローを案内する。TDD サイクルに従い、バックエンド→フロントエンドの順序で品質を担保しながら開発を進める。
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | 開発フェーズ全体のワークフローを表示 |
+| `--codex` | Claude（計画・設計・受入）と Codex（実装）の分業体制で開発 |
+
+## 開発フェーズの全体像
+
+1. **バックエンド開発** (Skill: `developing-backend`) — インサイドアウトアプローチ推奨
+2. **フロントエンド開発** (Skill: `developing-frontend`) — アウトサイドインアプローチ推奨
+
+各開発で Red-Green-Refactor サイクルを厳密に実行する。テストなしでプロダクションコードを書かない。
+
+### レビューポイント
+
+コーディングとテストガイドのイテレーション開発フローに準拠し、以下のタイミングでレビュースキルを発動する。
+
+| タイミング | スキル | 説明 |
+|-----------|--------|------|
+| TODO 完了時（コードレビュー） | `developing-review` | TDD サイクルで TODO を完了するたびにコード品質・テスト品質・設計整合性をレビュー |
+| 受け入れ前（品質チェック） | `operating-qt` | SonarQube によるコード品質分析・Quality Gate 確認を実施し、品質基準を満たしていることを検証 |
+| イテレーション完了時（ユーザーレビュー） | `analyzing-review` | 受け入れフェーズでユーザー視点・プロダクト視点からの成果物レビュー |
+
+## TDD サイクル
+
+TDD は「テストを書いてからコードを書く」手順ではなく、「設計を小さなフィードバックループで検証する」手法。10-15 分で 1 サイクルを完了させる。
+
+1. **Red**: 失敗するテストを最初に書く
+2. **Green**: テストを通す最小限のコードを実装する
+3. **Refactor**: 重複を除去し設計を改善する
+4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
+
+## 参照ドキュメント
+
+- @docs/reference/コーディングとテストガイド.md — TDD ワークフロー詳細
+- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md — Codex 連携フロー
+- @docs/design/architecture.md, @docs/design/architecture_backend.md, @docs/design/architecture_frontend.md
+- @docs/design/data-model.md, @docs/design/domain-model.md, @docs/design/tech_stack.md
+- @docs/design/ui-design.md, @docs/design/test_strategy.md
+- 作業開始前に対象の @docs/development/iteration_plan-N.md の内容を確認する
+- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
+
+## Codex 分業モード（--codex）
+
+Claude と Codex の役割を分離し、計画・設計・受入を Claude が担い、実装を Codex に委譲する。
+
+**前提条件**: Codex MCP サーバーが設定済みであること（@docs/reference/CodexCLIMCPサーバー設定手順.md 参照）
+
+### 役割分担
+
+| フェーズ | 担当 | 責務 |
+|---------|------|------|
+| 計画 | Claude | 要件分析、タスク分解、優先度決定 |
+| 設計 | Claude | API 設計、UI 設計、データモデル設計 |
+| 実装 | Codex | コード実装、ユニットテスト作成 |
+| 受入 | Claude | 設計レビュー、E2E テスト作成・実行、品質確認 |
+
+### 開発フロー
+
+```mermaid
+graph LR
+    A[計画] --> B[設計]
+    B --> C[実装指示]
+    C --> D[受入]
+    subgraph Claude
+    A
+    B
+    D
+    end
+    subgraph Codex
+    C
+    end
+```
+
+### 指示サイズ
+
+| 粒度 | 推奨度 | 説明 |
+|------|--------|------|
+| タスク単位（1-3 ファイル） | 推奨 | 1 つのコンポーネントや機能単位 |
+| 機能単位（3-5 ファイル） | 注意 | 進捗確認を頻繁に行う |
+| ユーザーストーリー単位 | 非推奨 | タスクに分割して実行する |
+
+### Codex への指示例
+
+```
+mcp__codex__codex
+  prompt: |
+    お知らせ管理機能を実装してください。
+    ## 開発ガイド
+    docs/reference/コーディングとテストガイド.md に従って実装すること。
+    特に TDD サイクル（Red-Green-Refactor）を厳守すること。
+    ## タスク
+    1. AuthContext に role と canManageAnnouncements を追加
+    2. API クライアントに create/update/delete 関数を追加
+    ## 完了条件
+    - ESLint エラーなし
+    - 既存テストがパス
+    - TDD サイクルに従って実装
+  sandbox: danger-full-access
+  approval-policy: never
+  cwd: プロジェクトルート
+```
+
+### 受入基準
+
+- [ ] すべての受入条件が満たされている
+- [ ] E2E テストがすべてパス
+- [ ] ESLint エラーがない
+- [ ] 既存テストが壊れていない
+
+### Codex が書き込みできない場合
+
+1. Claude が勝手に直接編集を進めてはいけない
+2. ユーザーに状況を報告し、確認を待つ
+3. ユーザーの許可を得てから代替手段を実行する
+
+## 途中から再開
+
+開発セッションの途中から再開する場合は、まず現在の実装状況を確認する。
+
+**Example:**
+
+```
+ユーザー: 「バックエンドの認証機能は実装済み。次の機能に進みたい」
+回答: イテレーション計画を確認し、次のユーザーストーリーを特定する。
+      既存コードのテスト結果を確認し、Green 状態であることを検証してから
+      次のタスクの Red フェーズに進む。
+```
+
+## コンテキスト管理
+
+タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
+
+- ユーザーストーリー 1 件の実装完了時、TDD サイクルを数回繰り返した後、コミット完了後に実施する
+- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
+
+## 注意事項
+
+- プロジェクトのテスト環境が設定済みであること（前提条件）
+- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
+- コミット前に必ず品質チェックリストを実行する
+- TODO 駆動開発でタスクを細かく分割してから実装を開始する
+- Rule of Three: 同じコードが 3 回現れたらリファクタリングする
+
+## 関連スキル
+
+- `developing-backend` — バックエンド TDD 開発
+- `developing-frontend` — フロントエンド TDD 開発
+- `developing-review` — 開発成果物のマルチパースペクティブレビュー（TODO 完了時のコードレビュー）
+- `analyzing-review` — 分析成果物のマルチパースペクティブレビュー（イテレーション完了時のユーザーレビュー）
+- `operating-qt` — コード品質管理（受け入れ前の SonarQube 品質チェック）
+- `developing-release` — リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）

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

@@ -1,158 +1,158 @@
----
-name: orchestrating-operation
-description: 運用フェーズ全体のワークフローをオーケストレーション。環境構築、プロビジョニング、CI/CD 構築、デプロイ設定、運用スクリプト作成の実行順序を案内。運用フェーズの開始や環境構築・デプロイの全体像の把握時に使用。
----
-
-# 運用フェーズオーケストレーション
-
-運用フェーズ全体の作業を支援します。環境構築からデプロイ設定、運用スクリプト作成までの包括的なワークフローを提供します。
-
-## Instructions
-
-### 1. 運用フェーズの全体像
-
-運用フェーズは「構築」と「配置」の 2 つの活動で構成されます。各環境の構築作業では、環境固有の手順書を作成・参照しながら進めます。
-
-```
-構築 → 配置 → ドキュメント更新
-```
-
-#### 構築
-
-環境の準備とインフラの整備を行います。
-
-1. **環境構築** — 各環境のセットアップ
-2. **プロビジョニング** — IaC によるインフラ管理
-3. **CI/CD 構築** — パイプラインの設計と実装
-4. **運用スクリプト作成** — 各環境のタスクランナー・自動化スクリプト
-
-#### 配置
-
-アプリケーションのビルドとデプロイを行います。
-
-1. **デプロイ設定** — デプロイ戦略の設計と実装
-
-### 2. 環境構築の段階的フロー
-
-環境構築は以下の順序で段階的に進めます。各環境のセットアップ時には対応するテンプレートを参照し、手順書を作成します。
-
-```
-アプリケーション開発環境 → 開発環境 → ステージング環境 → 本番環境
-```
-
-| 段階 | 環境 | 目的 | 手順書テンプレート |
-|------|------|------|------------------|
-| 1 | アプリケーション開発環境 | ローカル開発の効率化 | @docs/template/アプリケーション開発環境セットアップ手順書.md |
-| 2 | 開発環境 | チーム共有の動作確認環境 | @docs/template/開発環境セットアップ手順書.md |
-| 3 | ステージング環境 | 本番相当のテスト環境 | @docs/template/AWSステージング環境セットアップ手順書.md |
-| 4 | 本番環境 | プロダクション環境 | @docs/template/AWSプロダクション環境セットアップ手順書.md |
-
-各環境のセットアップ完了後、運用スクリプトを作成し、ドキュメントを更新します。
-
-### 3. プロビジョニング
-
-IaC（Infrastructure as Code）によるインフラ管理を行います。
-
-**主要な活動**:
-
-- Terraform / CloudFormation 等によるインフラ定義
-- 状態管理（S3 + DynamoDB 等）
-- モジュール化とコードの再利用
-- テスト（LocalStack / Terratest 等）
-
-**プロビジョニングのサイクル**:
-
-```
-インフラコード作成 → plan → apply → テスト → ドキュメント更新
-```
-
-### 4. CI/CD 構築
-
-継続的インテグレーション・デプロイのパイプラインを構築します。
-
-**主要な活動**:
-
-- CI パイプライン設計（ビルド・テスト・品質チェック）
-- CD パイプライン設計（デプロイ自動化）
-- OIDC 認証によるセキュアな CI/CD 連携
-- 環境別のデプロイ戦略
-
-### 5. デプロイ設定
-
-各環境へのデプロイ戦略を設計・実装します。
-
-| デプロイ方式 | 説明 | 用途 |
-|-------------|------|------|
-| ローリングデプロイ | 段階的にインスタンスを更新 | ECS / Kubernetes |
-| Blue/Green | 新旧環境を切り替え | RDS アップグレード等 |
-| Docker イメージ配布 | Registry 経由でイメージをプル | 開発環境サーバー |
-
-### 6. 運用スクリプト作成
-
-各環境の構築・デプロイ・管理を自動化するスクリプトを作成します。
-
-@docs/reference/運用スクリプト作成ガイド.md に従い、ネーミングルール・ディレクトリ構成・実装スタイルを統一します。
-
-**作成タイミング**: 各環境のセットアップ完了時に、その環境の運用スクリプトを作成します。
-
-**スクリプトの種類**:
-
-- 環境構築・セットアップ
-- ビルド・プッシュ
-- デプロイ・ロールバック
-- ステータス確認・ログ取得
-- バックアップ・リストア
-- クリーンアップ
-
-### 7. 実行手順
-
-運用フェーズを開始する際の推奨手順:
-
-1. **現状確認**: 既存の環境・インフラ・ドキュメントを確認
-2. **環境計画**: 必要な環境と構築順序を決定
-3. **手順書作成**: テンプレートを基に環境ごとの手順書を作成
-4. **環境構築**: 手順書に従い段階的に環境を構築（Skill: `managing-operations`）
-5. **CI/CD 構築**: パイプラインの設計と実装
-6. **運用スクリプト**: タスクランナー・自動化スクリプトの作成
-7. **ドキュメント更新**: 手順書・コマンドリファレンスの整備
-
-### 8. コンテキスト管理
-
-長時間の運用セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
-
-**`/compact` を実施するタイミング**:
-
-- 環境 1 つのセットアップが完了したとき
-- プロビジョニングの plan → apply サイクルが完了したとき
-- CI/CD パイプラインの設計・実装が一段落したとき
-- 運用スクリプト一式の作成が完了したとき
-- コミット完了後、次の環境構築に着手する前
-
-**運用ルール**:
-
-1. `/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する
-2. `/compact` 実施後、次の工程の作業を継続する
-3. 大規模な環境構築（例: AWS ステージング環境）では、リソースグループごとに `/compact` を検討する
-
-### 9. 注意事項
-
-- **前提条件**: 分析フェーズで運用要件が定義済みであること
-- **制限事項**: 本番環境の構築・デプロイは十分な確認と承認のもとで実行
-- **推奨事項**: ステージング環境で十分に検証してから本番環境に適用
-
-### 10. ベストプラクティス
-
-1. **段階的構築**: アプリ開発環境 → 開発環境 → ステージング → 本番の順序を厳守
-2. **IaC 優先**: 手作業を最小限に抑え、インフラをコードで管理
-3. **テンプレート活用**: 手順書テンプレートを基に環境固有の手順書を作成
-4. **自動化徹底**: 環境構築の各段階で運用スクリプトを作成
-5. **ドキュメント同期**: 環境変更時は手順書・コマンドリファレンスを同時更新
-
-### 関連スキル
-
-- `operating-setup` : 環境構築の段階的実行
-- `operating-provision` : IaC によるインフラプロビジョニング
-- `operating-cicd` : CI/CD パイプライン構築
-- `operating-deploy` : デプロイ・ロールバック
-- `operating-backup` : バックアップ・リストア
-- `analyzing-operation` : 運用要件の定義
+---
+name: orchestrating-operation
+description: 運用フェーズ全体のワークフローをオーケストレーション。環境構築、プロビジョニング、CI/CD 構築、デプロイ設定、運用スクリプト作成の実行順序を案内。運用フェーズの開始や環境構築・デプロイの全体像の把握時に使用。
+---
+
+# 運用フェーズオーケストレーション
+
+運用フェーズ全体の作業を支援します。環境構築からデプロイ設定、運用スクリプト作成までの包括的なワークフローを提供します。
+
+## Instructions
+
+### 1. 運用フェーズの全体像
+
+運用フェーズは「構築」と「配置」の 2 つの活動で構成されます。各環境の構築作業では、環境固有の手順書を作成・参照しながら進めます。
+
+```
+構築 → 配置 → ドキュメント更新
+```
+
+#### 構築
+
+環境の準備とインフラの整備を行います。
+
+1. **環境構築** — 各環境のセットアップ
+2. **プロビジョニング** — IaC によるインフラ管理
+3. **CI/CD 構築** — パイプラインの設計と実装
+4. **運用スクリプト作成** — 各環境のタスクランナー・自動化スクリプト
+
+#### 配置
+
+アプリケーションのビルドとデプロイを行います。
+
+1. **デプロイ設定** — デプロイ戦略の設計と実装
+
+### 2. 環境構築の段階的フロー
+
+環境構築は以下の順序で段階的に進めます。各環境のセットアップ時には対応するテンプレートを参照し、手順書を作成します。
+
+```
+アプリケーション開発環境 → 開発環境 → ステージング環境 → 本番環境
+```
+
+| 段階 | 環境 | 目的 | 手順書テンプレート |
+|------|------|------|------------------|
+| 1 | アプリケーション開発環境 | ローカル開発の効率化 | @docs/template/アプリケーション開発環境セットアップ手順書.md |
+| 2 | 開発環境 | チーム共有の動作確認環境 | @docs/template/開発環境セットアップ手順書.md |
+| 3 | ステージング環境 | 本番相当のテスト環境 | @docs/template/AWSステージング環境セットアップ手順書.md |
+| 4 | 本番環境 | プロダクション環境 | @docs/template/AWSプロダクション環境セットアップ手順書.md |
+
+各環境のセットアップ完了後、運用スクリプトを作成し、ドキュメントを更新します。
+
+### 3. プロビジョニング
+
+IaC（Infrastructure as Code）によるインフラ管理を行います。
+
+**主要な活動**:
+
+- Terraform / CloudFormation 等によるインフラ定義
+- 状態管理（S3 + DynamoDB 等）
+- モジュール化とコードの再利用
+- テスト（LocalStack / Terratest 等）
+
+**プロビジョニングのサイクル**:
+
+```
+インフラコード作成 → plan → apply → テスト → ドキュメント更新
+```
+
+### 4. CI/CD 構築
+
+継続的インテグレーション・デプロイのパイプラインを構築します。
+
+**主要な活動**:
+
+- CI パイプライン設計（ビルド・テスト・品質チェック）
+- CD パイプライン設計（デプロイ自動化）
+- OIDC 認証によるセキュアな CI/CD 連携
+- 環境別のデプロイ戦略
+
+### 5. デプロイ設定
+
+各環境へのデプロイ戦略を設計・実装します。
+
+| デプロイ方式 | 説明 | 用途 |
+|-------------|------|------|
+| ローリングデプロイ | 段階的にインスタンスを更新 | ECS / Kubernetes |
+| Blue/Green | 新旧環境を切り替え | RDS アップグレード等 |
+| Docker イメージ配布 | Registry 経由でイメージをプル | 開発環境サーバー |
+
+### 6. 運用スクリプト作成
+
+各環境の構築・デプロイ・管理を自動化するスクリプトを作成します。
+
+@docs/reference/運用スクリプト作成ガイド.md に従い、ネーミングルール・ディレクトリ構成・実装スタイルを統一します。
+
+**作成タイミング**: 各環境のセットアップ完了時に、その環境の運用スクリプトを作成します。
+
+**スクリプトの種類**:
+
+- 環境構築・セットアップ
+- ビルド・プッシュ
+- デプロイ・ロールバック
+- ステータス確認・ログ取得
+- バックアップ・リストア
+- クリーンアップ
+
+### 7. 実行手順
+
+運用フェーズを開始する際の推奨手順:
+
+1. **現状確認**: 既存の環境・インフラ・ドキュメントを確認
+2. **環境計画**: 必要な環境と構築順序を決定
+3. **手順書作成**: テンプレートを基に環境ごとの手順書を作成
+4. **環境構築**: 手順書に従い段階的に環境を構築（Skill: `managing-operations`）
+5. **CI/CD 構築**: パイプラインの設計と実装
+6. **運用スクリプト**: タスクランナー・自動化スクリプトの作成
+7. **ドキュメント更新**: 手順書・コマンドリファレンスの整備
+
+### 8. コンテキスト管理
+
+長時間の運用セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- 環境 1 つのセットアップが完了したとき
+- プロビジョニングの plan → apply サイクルが完了したとき
+- CI/CD パイプラインの設計・実装が一段落したとき
+- 運用スクリプト一式の作成が完了したとき
+- コミット完了後、次の環境構築に着手する前
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する
+2. `/compact` 実施後、次の工程の作業を継続する
+3. 大規模な環境構築（例: AWS ステージング環境）では、リソースグループごとに `/compact` を検討する
+
+### 9. 注意事項
+
+- **前提条件**: 分析フェーズで運用要件が定義済みであること
+- **制限事項**: 本番環境の構築・デプロイは十分な確認と承認のもとで実行
+- **推奨事項**: ステージング環境で十分に検証してから本番環境に適用
+
+### 10. ベストプラクティス
+
+1. **段階的構築**: アプリ開発環境 → 開発環境 → ステージング → 本番の順序を厳守
+2. **IaC 優先**: 手作業を最小限に抑え、インフラをコードで管理
+3. **テンプレート活用**: 手順書テンプレートを基に環境固有の手順書を作成
+4. **自動化徹底**: 環境構築の各段階で運用スクリプトを作成
+5. **ドキュメント同期**: 環境変更時は手順書・コマンドリファレンスを同時更新
+
+### 関連スキル
+
+- `operating-setup` : 環境構築の段階的実行
+- `operating-provision` : IaC によるインフラプロビジョニング
+- `operating-cicd` : CI/CD パイプライン構築
+- `operating-deploy` : デプロイ・ロールバック
+- `operating-backup` : バックアップ・リストア
+- `analyzing-operation` : 運用要件の定義