@k2works/claude-code-booster 1.13.0 → 2.0.1

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

@@ -0,0 +1,59 @@
+---
+name: operating-backup
+description: データベースのバックアップ・リストアを実行。AWS Backup による自動バックアップ、SSH トンネル経由の手動バックアップ、スナップショットからのリストア。バックアップやリストア、データ復旧時に使用。
+---
+
+# バックアップ・リストア
+
+データベースのバックアップ・リストアを実行します。
+
+## Instructions
+
+### 1. AWS Backup（自動バックアップ）
+
+`Backup = "true"` タグが付与された RDS インスタンスに対して日次・週次でスナップショットを自動取得する。
+
+| ルール | スケジュール | 保持期間 |
+|--------|-------------|---------|
+| daily | 毎日 JST 0:00 | 7 日 |
+| weekly | 毎週日曜 JST 0:00 | 35 日 |
+
+### 2. 手動バックアップ（SSH トンネル経由）
+
+踏み台サーバー経由で RDS に接続し、スキーマ単位のバックアップを実行する。
+
+```bash
+# SSH トンネルを確立
+ssh -L 5432:<RDS エンドポイント>:5432 ec2-user@<踏み台 IP> -i <キーペア>.pem
+
+# スキーマ単位でバックアップ
+PGPASSWORD=<パスワード> pg_dump -h 127.0.0.1 -p 5432 -U <ユーザー名> -d <DB 名> -n <スキーマ名> -Fc -f <スキーマ名>_backup.dump
+```
+
+### 3. リストア
+
+```bash
+# pg_restore によるリストア
+PGPASSWORD=<パスワード> pg_restore -h 127.0.0.1 -p 5432 -U <ユーザー名> -d <DB 名> --clean --if-exists <ダンプファイル>
+```
+
+### 4. AWS Backup からのリストア
+
+1. AWS コンソール → AWS Backup → バックアップボールト → リカバリポイントを選択
+2. 「復元」をクリック → リストア先の DB インスタンス識別子を指定
+3. リストア完了後、アプリケーションの接続先を切り替え
+
+> **注意**: AWS Backup からのリストアは新しい RDS インスタンスとして作成されます。
+
+### 5. 基本例
+
+```bash
+# 「データベースをバックアップして」
+# 「SMS スキーマをバックアップして」
+# 「バックアップからリストアして」
+```
+
+### 関連スキル
+
+- `operating-deploy` : デプロイ前のバックアップ確認
+- `operating-provision` : AWS Backup リソースのプロビジョニング

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

@@ -0,0 +1,54 @@
+---
+name: operating-cicd
+description: CI/CD パイプラインを構築。CI（Lint・テスト・ビルド・セキュリティスキャン）と CD（環境別デプロイ・OIDC 認証）の設計・実装。CI/CD パイプラインの構築やデプロイ自動化の設定時に使用。
+---
+
+# CI/CD パイプライン構築
+
+継続的インテグレーション・デプロイのパイプラインを構築します。
+
+## Instructions
+
+### 1. CI パイプライン
+
+ビルド・テスト・品質チェックを自動化する。
+
+| 段階 | 内容 | 目的 |
+|------|------|------|
+| ソースチェックアウト | リポジトリのコード取得 | 最新コードの取得 |
+| 依存関係インストール | パッケージのインストール | ビルド環境の準備 |
+| 静的解析 | Lint、型チェック | コード品質の担保 |
+| テスト | 単体・統合テストの実行 | 機能の正しさの検証 |
+| ビルド | アプリケーションのビルド | デプロイ可能な成果物の生成 |
+| セキュリティスキャン | 依存関係の脆弱性チェック | セキュリティリスクの排除 |
+
+### 2. CD パイプライン
+
+環境別のデプロイを自動化する。
+
+| 環境 | トリガー | 方式 | 承認 |
+|------|---------|------|------|
+| Development | `develop` ブランチ push | 即座デプロイ | 不要 |
+| Staging | `main` ブランチ push | 自動デプロイ | 不要 |
+| Production | リリースタグ作成 | ローリング or Blue/Green | 必須 |
+
+### 3. OIDC 認証
+
+クラウド環境へのデプロイではシークレットキーの直接管理を避け、OIDC（OpenID Connect）認証を使用する。
+
+- **AWS**: GitHub Actions OIDC Provider + IAM Role
+- **GCP**: Workload Identity Federation
+- **Azure**: Federated Identity Credentials
+
+### 4. ベストプラクティス
+
+- **高速フィードバック**: Lint → テスト → ビルドの順で失敗を早期検知
+- **キャッシュ活用**: 依存関係のキャッシュで実行時間を短縮
+- **並列実行**: 独立したジョブは並列で実行
+- **段階的導入**: CI 基盤 → 開発環境 CD → ステージング CD → 本番 CD の順
+
+### 関連スキル
+
+- `operating-deploy` : デプロイの実行
+- `operating-provision` : OIDC 用 IAM ロールのプロビジョニング
+- `orchestrating-operation` : 運用フェーズ全体のワークフロー案内

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

@@ -0,0 +1,67 @@
+---
+name: operating-deploy
+description: 各環境へのデプロイを実行。Docker イメージのビルド・プッシュ、ローリングデプロイ、Blue/Green デプロイ、ロールバック、ステータス確認、ログ取得。デプロイやロールバック、サービス状態確認時に使用。
+---
+
+# デプロイ
+
+各環境へのデプロイ、ロールバック、ステータス確認を実行します。
+
+## Instructions
+
+### 1. デプロイフロー
+
+```
+Docker ビルド → Registry プッシュ → 対象環境でプル → サービス更新 → ヘルスチェック
+```
+
+### 2. デプロイ方式
+
+| 方式 | 説明 | 用途 |
+|------|------|------|
+| Docker イメージ配布 | Registry 経由でイメージをプル | 開発環境 |
+| ローリングデプロイ | 段階的にインスタンスを更新 | ECS ステージング・本番 |
+| Blue/Green | 新旧環境を切り替え | RDS アップグレード |
+
+### 3. 環境別デプロイ
+
+```bash
+# 開発環境: Docker イメージ配布
+# 「開発環境にデプロイして」
+
+# ステージング環境: ECS ローリングデプロイ
+# 「ステージングにデプロイして」
+
+# 本番環境: 承認後デプロイ
+# 「本番にデプロイして」
+```
+
+### 4. ロールバック
+
+問題発生時は前バージョンに切り戻す。
+
+```bash
+# 「開発環境をロールバックして」
+# 「本番を前バージョンに戻して」
+```
+
+### 5. ステータス確認・ログ
+
+```bash
+# 「開発環境の状態を確認して」
+# 「ステージングのログを見せて」
+# 「全環境の状態を確認して」
+```
+
+### 6. 注意事項
+
+- **段階的デプロイ**: Development → Staging → Production の順序を厳守
+- **ステージング検証**: 本番デプロイ前にステージングで十分に検証
+- **ロールバック準備**: デプロイ前にロールバック手順を確認
+- **ヘルスチェック**: デプロイ後に必ず動作確認を実施
+
+### 関連スキル
+
+- `operating-cicd` : CI/CD パイプライン構築
+- `operating-backup` : デプロイ前のバックアップ
+- `developing-release` : リリースワークフロー

package/lib/assets/.claude/skills/{managing-docs → operating-docs}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: managing-docs
+name: operating-docs
 description: 設計ドキュメントの一覧表示、進捗確認、内容参照、インデックス更新、Markdown Lint を実行。ドキュメント管理や整備時に使用。
 ---
 

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

@@ -0,0 +1,77 @@
+---
+name: operating-provision
+description: IaC（Terraform）によるインフラプロビジョニングを実行。S3 状態管理、VPC、RDS、ECR、ECS 等の AWS リソースを段階的に構築・管理。Terraform の init/plan/apply やインフラ構築時に使用。
+---
+
+# インフラプロビジョニング
+
+IaC（Infrastructure as Code）により、ステージング・本番環境のインフラを構築・管理します。
+
+## Instructions
+
+### 1. Terraform ワークフロー
+
+```
+インフラコード作成 → init → plan → apply → テスト → ドキュメント更新
+```
+
+```bash
+# 初期化
+terraform init --backend-config=backend.hcl
+
+# 変更確認
+terraform plan
+
+# 適用
+terraform apply
+
+# 廃棄
+terraform destroy
+```
+
+aws-vault 使用時は `aws-vault exec <profile> --` プレフィックスを付与する。
+
+### 2. プロビジョニング順序
+
+ステージング・本番環境では以下のリソースを段階的にプロビジョニングする。
+
+1. **状態管理**: S3 バケット + DynamoDB（Terraform State）
+2. **IAM**: OIDC 認証用 IAM ロール（GitHub Actions 連携）
+3. **シークレット**: SSM パラメータストア（DB 認証情報）
+4. **ネットワーク**: VPC・サブネット・NAT Gateway
+5. **データストア**: RDS
+6. **バックアップ**: AWS Backup
+7. **レジストリ**: ECR リポジトリ
+8. **コンピュート**: ECS（Fargate + ALB）
+9. **管理**: Application Manager（リソースグループ）
+10. **DNS**: Route 53・カスタムドメイン（任意）
+11. **踏み台**: EC2 踏み台サーバー（任意）
+
+### 3. Terraform ディレクトリ構成
+
+```text
+ops/terraform/
+├── live/
+│   ├── global/          # S3 状態管理、IAM ロール
+│   ├── stage/           # ステージング環境リソース
+│   └── prod/            # 本番環境リソース
+├── modules/             # 再利用可能モジュール
+└── test/                # Terratest
+```
+
+### 4. 環境廃棄
+
+廃棄は**構築時と逆の順序**で実行する。本番環境では `deletion_protection` を事前に `false` に変更する。
+
+### 5. 注意事項
+
+- **状態管理が先**: S3 + DynamoDB は他の全リソースより先に作成
+- **IaC 優先**: 手作業を最小限に抑え、インフラをコードで管理
+- **テスト**: LocalStack（ローカル）、Terratest（単体・結合）で検証
+- **secret.tfvars**: Git 管理外にすること
+
+### 関連スキル
+
+- `operating-setup` : 環境構築の段階的実行
+- `operating-cicd` : CI/CD パイプライン構築
+- `operating-deploy` : デプロイ実行

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

@@ -0,0 +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 パイプライン構築

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

@@ -1,134 +1,104 @@
 ---
 name: orchestrating-analysis
-description: 分析フェーズ全体のワークフローをオーケストレーション。要件定義から非機能要件まで各 analyzing-* スキルの実行順序を案内。分析フェーズの開始や全体像の把握時に使用。
+description: 分析フェーズ全体のワークフローをオーケストレーション。戦略→要件定義→機能要件→非機能要件の順序で各 analyzing-* スキルの実行を案内。分析フェーズの開始、全体像の把握、次に何を分析すべきかの判断、分析の進め方の相談時に使用。「分析を始めたい」「要件定義の次は何？」「設計ドキュメントを一通り作りたい」といった場面で発動する。
 ---
 
 # 分析フェーズオーケストレーション
 
-分析フェーズ全体の作業を支援します。要件定義から非機能要件まで包括的な分析ワークフローを提供します。
+分析フェーズ全体の作業順序を案内する。各工程には専門の analyzing-* スキルがあるため、このスキルの役割は「何を・どの順序で・なぜその順序で」進めるかを示すことにある。
 
-## Instructions
+開発ガイド（@docs/reference/開発ガイド.md）の分析セクションに定義されたフローに準拠する。
 
-### 1. 分析フェーズの全体像
+## 分析フェーズの構成
 
-分析フェーズは以下の工程で構成されます:
+分析は **戦略 → 要件定義 → 機能要件 → 非機能要件** の 4 段階で進める。各段階の出力が次の段階の入力になるため、この順序を守ることが品質を確保する上で重要になる。
 
-1. **ビジネスアーキテクチャ分析** (Skill: `analyzing-business`)
+### 段階 1: 戦略
 
-   - ビジネスモデルキャンバスの作成
-   - バリューストリームの設計
-   - ビジネスケイパビリティモデルの構築
+プロジェクトの「なぜ・何を・どうやって」を明確にする。ここが曖昧だと後工程すべてがブレるため、最初に固める。
 
-2. **インセプションデッキ作成** (Skill: `analyzing-inception-deck`)
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| ビジネスアーキテクチャ分析 | `analyzing-business` | ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ |
+| インセプションデッキ作成 | `analyzing-inception-deck` | 10 の問いへの回答、概念アーキテクチャ、マイルストーン |
 
-   - プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理
-   - スコープ・リスク・トレードオフの明確化
-   - 概念アーキテクチャとマイルストーンの策定
+### 段階 2: 要件定義
 
-3. **要件定義** (Skill: `analyzing-requirements`)
+システムが解決すべき問題と境界を定義する。RDRA 2.0 の体系に従い、システム価値→外部環境→境界の順で分析を進める。
 
-   - システム価値の明確化
-   - システム外部環境の分析
-   - システム境界の定義
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| 要件定義 | `analyzing-requirements` | システムコンテキスト、要求モデル、業務フロー |
+| ユースケース・ユーザーストーリー | `analyzing-usecases` | ビジネスユースケース、システムユースケース、ユーザーストーリー |
 
-4. **ユースケース作成** (Skill: `analyzing-usecases`)
+### 段階 3: 機能要件
 
-   - ビジネスユースケースの抽出
-   - システムユースケースの定義
-   - ユーザーストーリーの作成
+要件をどう実現するかの設計を行う。アーキテクチャが決まらないとデータモデルやドメインモデルの粒度が定まらないため、アーキテクチャ設計を先に行う。
 
-5. **アーキテクチャ設計** (Skill: `analyzing-architecture`)
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| アーキテクチャ設計 | `analyzing-architecture` | バックエンド・フロントエンド・インフラ設計 |
+| データモデル設計 | `analyzing-data-model` | ER 図、テーブル定義 |
+| ドメインモデル設計 | `analyzing-domain-model` | エンティティ、値オブジェクト、集約 |
+| UI 設計 | `analyzing-ui-design` | 画面遷移図、画面イメージ |
 
-   - バックエンドアーキテクチャ
-   - フロントエンドアーキテクチャ
-   - インフラストラクチャアーキテクチャ
+### 段階 4: 非機能要件
 
-6. **データモデル設計** (Skill: `analyzing-data-model`)
+システムの品質特性と運用方針を定義する。機能要件が見えた段階で策定することで、現実的な要件を設定できる。
 
-   - ER 図の作成
-   - テーブル定義
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| テスト戦略 | `analyzing-test-strategy` | テストピラミッド、テスト種別、カバレッジ目標 |
+| 非機能要件 | `analyzing-non-functional` | 性能・セキュリティ・可用性・保守性要件 |
+| 運用要件 | `analyzing-operation` | 運用フロー、監視設計、障害対応手順 |
 
-7. **ドメインモデル設計** (Skill: `analyzing-domain-model`)
+### 横断: 技術スタック・ADR
 
-   - エンティティ定義
-   - 値オブジェクト定義
-   - 集約の設計
+技術スタック選定とアーキテクチャ決定記録は、分析の進行に応じて随時実施する。
 
-8. **UI 設計** (Skill: `analyzing-ui-design`)
+| 工程 | スキル | 成果物 |
+|------|--------|--------|
+| 技術スタック選定 | `analyzing-tech-stack` | 技術選定・評価結果 |
+| ADR 作成 | `creating-adr` | Architecture Decision Record |
 
-   - 画面遷移図
-   - 画面イメージ
+## 進め方
 
-9. **テスト戦略** (Skill: `analyzing-test-strategy`)
+### 現状を確認してから始める
 
-   - テストピラミッド設計
-   - テスト種別の定義
+分析を開始する前に、プロジェクトの現状を把握する。既存のドキュメントやコードがある場合、ゼロから始める必要はない。
 
-10. **非機能要件** (Skill: `analyzing-non-functional`)
+1. `docs/` 配下の既存ドキュメントを確認
+2. `docs/design/` 配下の設計ドキュメントの有無を確認
+3. 未着手の工程を特定し、次のアクションを提案
 
-    - 性能要件
-    - セキュリティ要件
+### 途中から再開する場合
 
-11. **運用要件** (Skill: `analyzing-operation`)
+すべての工程を最初から実施する必要はない。既に完了している工程はスキップし、未着手または更新が必要な工程から再開する。
 
-    - 運用フロー
-    - 監視設計
+**Example:**
 
-12. **技術スタック** (Skill: `analyzing-tech-stack`)
+```
+ユーザー: 「要件定義は終わった。次は何をすればいい？」
+回答: 段階 3（機能要件）のアーキテクチャ設計から開始。
+      analyzing-architecture スキルを使ってアーキテクチャ設計を進める。
+```
 
-    - 技術選定
-    - バージョン管理
+### 工程間のフィードバック
 
-### 2. 連携シナリオ
+分析は一方通行ではない。後工程の検討で前工程の見直しが必要になることがある。たとえば、データモデル設計中に要件の不足に気づいた場合は、要件定義に戻って補完する。
 
-```bash
-# プロジェクト情報の確認後に分析開始
-ls -la docs/
-cat README.md
-# 「プロジェクトの現状を踏まえた分析フェーズの進め方を提案」
-```
+## コンテキスト管理
 
-### 3. コンテキスト管理
+分析フェーズは多くの工程を含むため、長時間セッションになりやすい。以下のタイミングで `/compact` を実施し、コンテキストを圧縮する。
 
-長時間の分析セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+- 分析工程 1 件が完了したとき
+- 設計ドキュメント 1 件の作成・更新が完了したとき
+- コミット完了後、次の工程に着手する前
 
-**`/compact` を実施するタイミング**:
+`/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する。これにより、圧縮後も作業の連続性を保てる。
 
-- 分析工程 1 件（例: 要件定義、ユースケース作成）が完了したとき
-- 設計ドキュメント 1 件の作成・更新が完了したとき
-- 複数の analyzing-* スキルを連続実行する間
-- コミット完了後、次の分析工程に着手する前
-
-**運用ルール**:
-
-1. `/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する
-2. `/compact` 実施後、次の工程の作業を継続する
-3. 大規模な分析工程（例: アーキテクチャ設計）では、サブ工程ごとに `/compact` を検討する
-
-### 4. 注意事項
-
-- **前提条件**: プロジェクトの基本的な背景情報の把握が必要
-- **制限事項**: 分析結果は開発フェーズで継続的に見直し・改善が必要
-- **推奨事項**: 各工程の成果物を文書化し、チーム内で共有することを推奨
-
-### 5. ベストプラクティス
-
-1. **段階的分析**: 要件定義から始めて段階的に詳細化する
-2. **チーム連携**: 分析結果をチーム全体で共有し、合意形成を行う
-3. **継続的改善**: 開発フェーズでのフィードバックを基に分析結果を見直す
-4. **文書化**: 分析結果は PlantUML や Markdown で視覚的に文書化する
-
-### 関連スキル
-
-- `analyzing-business` : ビジネスアーキテクチャ分析支援
-- `analyzing-inception-deck` : インセプションデッキ作成支援
-- `analyzing-requirements` : 要件定義関連の作業支援
-- `analyzing-usecases` : ユースケース・ユーザーストーリー作成支援
-- `analyzing-architecture` : アーキテクチャ設計支援
-- `analyzing-data-model` : データモデル設計支援
-- `analyzing-domain-model` : ドメインモデル設計支援
-- `analyzing-ui-design` : UI 設計支援
-- `analyzing-test-strategy` : テスト戦略策定支援
-- `analyzing-non-functional` : 非機能要件定義支援
-- `analyzing-operation` : 運用要件定義支援
-- `analyzing-tech-stack` : 技術スタック選定支援
+## 注意事項
+
+- 分析結果は開発フェーズで継続的に見直す。完璧を目指して分析を長引かせるより、十分な品質で開発に進み、フィードバックで改善する方が効果的
+- 各工程の成果物は `docs/` 配下に Markdown + PlantUML で文書化する
+- リリース計画（`planning-releases`）は分析フェーズの最後に、技術スタック選定後に実施する