@k2works/claude-code-booster 4.4.1 → 4.5.0

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` — レビュー結果の保存後のコミット

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` — 運用フェーズ全体のワークフロー