@k2works/claude-code-booster 0.22.0 → 1.0.0

package/lib/assets/.claude/skills/creating-adr/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: creating-adr
+description: Architecture Decision Record の作成を支援。技術的意思決定の記録フォーマットとベストプラクティス。アーキテクチャ上の意思決定を記録する際に使用。
+---
+
+# ADR (Architecture Decision Record) 作成支援
+
+アーキテクチャ決定記録（ADR）の作成・管理を支援します。
+
+## Instructions
+
+### 1. ADR ファイル構造
+
+ADR は `docs/adr/` ディレクトリに以下の命名規則で保存：
+
+```
+docs/adr/
+├── 001-backend-architecture-pattern.md
+├── 002-backend-framework.md
+├── 003-frontend-framework.md
+└── 004-database.md
+```
+
+### 2. ADR テンプレート
+
+```markdown
+# ADR-NNN: タイトル
+
+簡潔な説明（1行で決定内容を要約）。
+
+日付: YYYY-MM-DD
+
+## ステータス
+
+提案中 | 承認済み | 廃止 | 置換（ADR-XXX で置換）
+
+## コンテキスト
+
+この決定が必要になった背景・状況を説明。
+
+- 現在の課題や制約
+- 関連するシステムやサービス
+- ビジネス要件
+
+## 決定
+
+**何を決定したか** を明確に記述。
+
+### 変更箇所
+
+具体的な実装変更がある場合は記載。
+
+### 代替案
+
+検討した代替案とその却下理由。
+
+## 影響
+
+### ポジティブ
+
+- 良い影響
+
+### ネガティブ
+
+- 悪い影響や注意点
+
+## コンプライアンス
+
+決定が正しく実装されていることを確認する方法。
+
+## 備考
+
+- 著者: 担当者名
+- 関連コミット: コミットハッシュ
+- 関連 ADR: ADR-XXX
+```
+
+### 3. ステータスの種類
+
+| ステータス | 説明 |
+|-----------|------|
+| 提案中 | レビュー待ちの ADR |
+| 承認済み | 採用された決定 |
+| 廃止 | 無効になった決定 |
+| 置換 | 別の ADR で置き換えられた |
+
+### 4. 注意事項
+
+- **採番規則**: ADR 番号は 001 から連番で管理。既存の最大番号 + 1 で採番
+- **ファイル名**: `NNN-kebab-case-title.md` 形式（例: `006-cache-strategy.md`）
+- **配置場所**: 必ず `docs/adr/` ディレクトリに配置
+- **ドキュメント更新**: 新規 ADR 作成時は `docs/index.md` と `mkdocs.yml` も更新が必要
+- **コミット禁止**: ユーザーの指示があるまでコミットしない
+
+### 5. ベストプラクティス
+
+1. **簡潔な要約**: タイトル直下に 1 行で決定内容を要約する
+2. **コンテキストの明確化**: なぜこの決定が必要なのか背景を説明
+3. **代替案の記録**: 検討した選択肢と却下理由を残す
+4. **影響の両面記載**: ポジティブ・ネガティブ両方の影響を記載
+5. **コンプライアンス項目**: 決定が守られていることを確認する方法を記載
+
+## Examples
+
+### 新しい ADR の作成
+
+1. `docs/adr/` ディレクトリ内の既存 ADR の最大番号を確認
+2. 次の連番でテンプレートに基づいて ADR を作成
+3. `docs/index.md` と `mkdocs.yml` を更新
+
+### 既存設計からの ADR 抽出
+
+1. アーキテクチャ設計ドキュメントを読み込む
+2. 主要な技術的意思決定を識別
+3. 各決定を ADR として記録

package/lib/assets/.claude/skills/developing-backend/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: developing-backend
+description: バックエンド開発の TDD ワークフロー。Red-Green-Refactor サイクル、インサイドアウトアプローチ、品質チェックリスト。Java/Spring Boot のバックエンド実装時に使用。
+---
+
+# バックエンド開発ガイド
+
+TDD サイクルに従ったバックエンド開発を支援します。
+
+## Instructions
+
+### 1. 参照ドキュメント
+
+- @docs/reference/コーディングとテストガイド.md - ワークフロー
+- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
+- @docs/design/data-model.md - データモデル
+- @docs/design/domain-model.md - ドメインモデル
+- @docs/design/tech_stack.md - 技術スタック
+- @docs/design/test_strategy.md - テスト戦略
+
+### 2. TDD サイクルの実践
+
+Red-Green-Refactor サイクルを厳密に実行：
+
+1. **Red フェーズ**: 失敗するテストを最初に書く
+2. **Green フェーズ**: テストを通す最小限のコードを実装
+3. **Refactor フェーズ**: 重複を除去し設計を改善
+
+### 3. アプローチ戦略の選択
+
+- **インサイドアウト**: データ層から開始し上位層へ展開（推奨）
+- **アウトサイドイン**: API から開始しドメインロジックを段階的に実装
+
+### 4. テストコマンド
+
+```bash
+# 全テスト実行
+cd apps/backend && ./gradlew test
+
+# 特定テストクラス実行
+cd apps/backend && ./gradlew test --tests "UserServiceTest"
+
+# テストカバレッジ確認
+cd apps/backend && ./gradlew jacocoTestReport
+```
+
+### 5. API ドキュメント
+
+バックエンドには Swagger UI が組み込まれています。
+
+```bash
+# バックエンドを起動
+cd apps/backend && ./gradlew bootRun
+
+# Swagger UI: http://localhost:8080/swagger-ui.html
+# OpenAPI JSON: http://localhost:8080/v3/api-docs
+# OpenAPI YAML: http://localhost:8080/api-docs.yaml
+```
+
+### 6. 品質チェックリスト
+
+- [ ] すべてのテストがパス
+- [ ] ESLint/コンパイラの警告がゼロ
+- [ ] テストカバレッジが目標を満たしている
+- [ ] 単一の論理的作業単位を表現
+- [ ] コミットメッセージが変更内容を明確に説明
+
+### 7. 注意事項
+
+- **前提条件**: Java/Gradle のテスト環境が設定済みであること
+- **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
+- **推奨事項**: コミット前に必ず品質チェックリストを実行
+- 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
+
+## Examples
+
+### 新機能の TDD 実装
+
+1. 失敗するテストを書く（Red）
+2. テストを通す最小限のコードを実装（Green）
+3. 重複を排除し設計を改善（Refactor）
+4. 品質チェックリストを実行してコミット
+
+### ベストプラクティス
+
+1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
+2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
+3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
+4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング

package/lib/assets/.claude/skills/developing-frontend/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: developing-frontend
+description: フロントエンド開発の TDD ワークフロー。Red-Green-Refactor サイクル、アウトサイドインアプローチ、コンポーネント設計。React/TypeScript のフロントエンド実装時に使用。
+---
+
+# フロントエンド開発ガイド
+
+TDD サイクルに従ったフロントエンド開発を支援します。
+
+## Instructions
+
+### 1. 参照ドキュメント
+
+- @docs/reference/コーディングとテストガイド.md - ワークフロー
+- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
+- @docs/design/ui-design.md - UI 設計
+- @docs/design/tech_stack.md - 技術スタック
+- @docs/design/test_strategy.md - テスト戦略
+
+### 2. TDD サイクルの実践
+
+Red-Green-Refactor サイクルを厳密に実行：
+
+1. **Red フェーズ**: 失敗するテストを最初に書く
+2. **Green フェーズ**: テストを通す最小限のコードを実装
+3. **Refactor フェーズ**: 重複を除去し設計を改善
+
+### 3. アプローチ戦略の選択
+
+- **アウトサイドイン**: UI から開始しロジックを段階的に実装（推奨）
+- **インサイドアウト**: ユーティリティ/hooks から開始し上位層へ展開
+
+### 4. テストコマンド
+
+```bash
+# 全テスト実行
+cd apps/frontend && npm run test
+
+# ウォッチモードでテスト実行
+cd apps/frontend && npm run test:watch
+
+# テストカバレッジ確認
+cd apps/frontend && npm run test:coverage
+
+# E2E テスト実行
+cd apps/frontend && npm run test:e2e
+```
+
+### 5. 品質チェックリスト
+
+- [ ] すべてのテストがパス
+- [ ] ESLint の警告がゼロ
+- [ ] テストカバレッジが目標を満たしている
+- [ ] 単一の論理的作業単位を表現
+- [ ] コミットメッセージが変更内容を明確に説明
+
+### 6. 注意事項
+
+- **前提条件**: Node.js/npm のテスト環境が設定済みであること
+- **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
+- **推奨事項**: コミット前に必ず品質チェックリストを実行
+- 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
+
+## Examples
+
+### 新コンポーネントの TDD 実装
+
+1. 失敗するテストを書く（Red）
+2. テストを通す最小限のコードを実装（Green）
+3. 重複を排除し設計を改善（Refactor）
+4. 品質チェックリストを実行してコミット
+
+### ベストプラクティス
+
+1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
+2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
+3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
+4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング
+5. **コンポーネント分割**: 単一責任の原則に従いコンポーネントを小さく保つ

package/lib/assets/.claude/skills/killing-processes/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: killing-processes
+description: 開発サーバーや Node.js プロセスを強制終了。ポート競合の解決やプロセスリセット時に使用。
+---
+
+# Kill Development Processes
+
+開発サーバーや Node.js プロセスを強制終了するスキル。複数ポートで起動している開発プロセスを一括で停止できます。
+
+## Instructions
+
+### 1. オプション
+
+- なし : すべての Node.js 開発プロセスを強制終了
+- `--port <ポート番号>` : 特定のポートのプロセスのみ終了
+- `--check` : プロセス状況の確認のみ（終了せず）
+
+### 2. 基本例
+
+```bash
+# 全開発プロセスを強制終了
+# 「すべての Node.js 開発サーバー（npm run dev 等）を停止」
+
+# ポート 3000 番のプロセスのみ終了
+# --port 3000
+# 「ポート 3000 で動作中のプロセスを終了」
+
+# プロセス状況の確認
+# --check
+# 「現在起動中の開発プロセスを一覧表示」
+```
+
+### 3. 詳細機能
+
+#### 一括プロセス終了
+
+Windows 環境で複数の開発サーバーが起動している場合の一括終了処理。
+
+```bash
+# ポート範囲でのプロセス検索・終了
+netstat -ano | findstr ":300[0-9]" | findstr LISTENING
+taskkill //F //PID <PID1> && taskkill //F //PID <PID2>
+```
+
+#### 個別ポート指定終了
+
+特定のポートで起動しているプロセスのみを終了する。
+
+- **安全性**: 指定ポートのみ終了で他に影響しない
+- **精密性**: 必要最小限のプロセス停止
+- **確認**: 終了前にプロセス情報を表示
+
+### 4. 出力例
+
+```
+現在起動中の開発プロセス:
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+ポート 3000: PID 34348 (Node.js)
+ポート 3001: PID 16676 (Node.js)
+ポート 3002: PID 25696 (Node.js)
+
+プロセス終了中...
+PID 34348 を終了しました
+PID 16676 を終了しました
+PID 25696 を終了しました
+
+すべての開発プロセスを停止しました。
+```
+
+### 5. 連携シナリオ
+
+```bash
+# 開発中のエラー修正後にプロセスリセット
+npm run dev
+# 「エラーが発生」→ kill → 「全プロセス停止して再起動準備」
+
+# ポート競合の解決
+npm start
+# 「Port 3000 is already in use」→ kill --port 3000
+
+# 開発環境のクリーンアップ
+git checkout main
+# → kill → 「ブランチ切り替え前に開発プロセスをクリーンアップ」
+```
+
+### 6. 注意事項
+
+- **前提条件**: Windows 環境（taskkill コマンド使用）
+- **制限事項**: 管理者権限が必要な場合があります
+- **推奨事項**: 重要な作業中は事前にファイル保存を行う
+
+### 7. ベストプラクティス
+
+1. **安全な終了**: 作業中のファイルは事前に保存する
+2. **段階的終了**: まず `--check` で状況確認してから終了
+3. **ポート指定**: 必要に応じて特定ポートのみ終了
+4. **再起動準備**: プロセス終了後は適切にサーバーを再起動

package/lib/assets/.claude/skills/managing-docs/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: managing-docs
+description: 設計ドキュメントの一覧表示、進捗確認、内容参照、インデックス更新、Markdown Lint を実行。ドキュメント管理や整備時に使用。
+---
+
+# ドキュメント管理ガイド
+
+設計ドキュメントの一覧表示、進捗確認、内容参照を行います。
+
+## Instructions
+
+### 1. オプション
+
+- なし : ドキュメント一覧と進捗状況を表示
+- `--list` : ドキュメント一覧のみを表示
+- `--status` : ドキュメントの作成状況を詳細表示
+- `--read <ファイル名>` : 指定したドキュメントの内容を表示
+- `--summary` : 全ドキュメントの概要を表示
+- `--update` : `docs/index.md` と `mkdocs.yml` を現在のドキュメント構成に合わせて更新
+- `--update-index` : `docs/index.md` のみを更新
+- `--update-mkdocs` : `mkdocs.yml` のみを更新
+- `--lint` : Markdown フォーマットをチェックし、違反を自動修正
+
+### 2. 基本例
+
+```bash
+# ドキュメント一覧と進捗確認
+# 「設計ドキュメントの一覧と作成状況を確認」
+
+# 特定ドキュメントの参照
+# --read tech_stack
+# 「技術スタック選定ドキュメントの内容を表示」
+
+# docs/index.md と mkdocs.yml を更新
+# --update
+# 「現在のドキュメント構成に合わせて両ファイルを更新」
+
+# Markdown フォーマットをチェック・修正
+# --lint
+# 「タスク項目の前に空行がないなどのフォーマット違反を検出し自動修正」
+```
+
+### 3. ドキュメント構成
+
+本プロジェクトのドキュメントは以下の構成で管理されています:
+
+**要件定義ドキュメント** (`docs/requirements/`)
+
+- `requirements_definition.md` : 要件定義書（RDRA 2.0）
+- `business_usecase.md` : ビジネスユースケース
+- `system_usecase.md` : システムユースケース
+- `user_story.md` : ユーザーストーリー
+
+**設計ドキュメント** (`docs/design/`)
+
+- `architecture_backend.md` : バックエンドアーキテクチャ
+- `architecture_frontend.md` : フロントエンドアーキテクチャ
+- `architecture_infrastructure.md` : インフラストラクチャ
+- `data-model.md` : データモデル設計
+- `domain-model.md` : ドメインモデル設計
+- `ui-design.md` : UI 設計
+- `test_strategy.md` : テスト戦略
+- `non_functional.md` : 非機能要件
+- `operation.md` : 運用要件
+- `tech_stack.md` : 技術スタック選定
+
+### 4. ドキュメント更新機能
+
+`--update` オプションを使用すると、現在のドキュメント構成に合わせて `docs/index.md` と `mkdocs.yml` を自動更新できます。
+
+**docs/index.md の更新内容**:
+
+- ドキュメント一覧をカテゴリ別に整理
+- 各ドキュメントへのリンクと説明を生成
+- 「まずこれを読もうリスト」形式で構成
+
+**mkdocs.yml の更新内容**:
+
+- `nav` セクションを現在のドキュメント構成に合わせて更新
+- 要件定義、設計、開発、運用などのカテゴリで階層化
+- 新しいドキュメントを自動的にナビゲーションに追加
+
+### 5. Lint 機能
+
+`--lint` オプションを使用すると、Markdown ドキュメントのフォーマットをチェックし、違反を自動修正できます。
+
+**チェックルール**:
+
+- タスク項目（リスト）の前には空行が必要
+- 番号付きリストのサブリスト前にも空行が必要
+- コロンで終わる行の直後にリストがある場合も空行が必要
+- 太字ラベル（半角・全角コロン両方）の直後にリストがある場合も空行が必要
+
+**NG 例** - ラベルの直後にリスト:
+
+```markdown
+**受入条件**:
+- [ ] ログアウトボタンをクリックするとログアウトできる
+```
+
+**OK 例**:
+
+```markdown
+**受入条件**:
+
+- [ ] ログアウトボタンをクリックするとログアウトできる
+```
+
+**NG 例** - 番号付きリストの直後にサブリスト:
+
+```markdown
+1. **対処**: SMB バージョンを確認
+   - コントロールパネル > ファイルサービス > SMB で設定
+```
+
+**OK 例**:
+
+```markdown
+1. **対処**: SMB バージョンを確認
+
+   - コントロールパネル > ファイルサービス > SMB で設定
+```
+
+**NG 例** - コロンで終わる行の直後にリスト:
+
+```markdown
+PMD はカスタム設定で以下をチェック：
+- マジックナンバーの使用
+```
+
+**OK 例**:
+
+```markdown
+PMD はカスタム設定で以下をチェック：
+
+- マジックナンバーの使用
+```
+
+**実行手順**:
+
+1. `docs/` 配下の全 Markdown ファイルをスキャン
+2. 上記ルールに違反する箇所を検出
+3. 違反箇所を自動修正
+4. 修正結果を報告
+
+### 6. 出力例
+
+```
+設計ドキュメント一覧
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+docs/requirements/
+├─ requirements_definition.md (要件定義書)
+├─ business_usecase.md (ビジネスユースケース)
+├─ system_usecase.md (システムユースケース)
+└─ user_story.md (ユーザーストーリー)
+
+docs/design/
+├─ architecture_backend.md (バックエンドアーキテクチャ)
+├─ architecture_frontend.md (フロントエンドアーキテクチャ)
+├─ data-model.md (データモデル設計)
+├─ domain-model.md (ドメインモデル設計)
+├─ ui-design.md (UI 設計)
+├─ test_strategy.md (テスト戦略)
+├─ non_functional.md (非機能要件)
+├─ operation.md (運用要件)
+└─ tech_stack.md (技術スタック選定)
+
+進捗: 14/14 ドキュメント完成 (100%)
+```
+
+### 7. 注意事項
+
+- **前提条件**: `docs/` ディレクトリが存在すること
+- **制限事項**: Markdown 形式のドキュメントのみ対応
+- **推奨事項**: 定期的にドキュメントの進捗を確認し、最新の状態を維持すること
+- **更新時の注意**: `--update` 実行前に現在の `docs/index.md` と `mkdocs.yml` をバックアップすることを推奨
+- **MkDocs 依存**: `--update-mkdocs` を使用する場合、MkDocs がインストールされている必要がある
+
+### 8. ベストプラクティス
+
+1. **定期確認**: 開発フェーズ移行前にドキュメントの完成度を確認する
+2. **整合性維持**: コード変更時は関連ドキュメントも更新する
+3. **レビュー活用**: チームレビュー前にドキュメント概要を共有する
+4. **バージョン管理**: ドキュメントの変更は Git でコミットする
+5. **インデックス同期**: 新しいドキュメント作成後は `--update` でインデックスを同期する
+6. **プレビュー確認**: `--update-mkdocs` 後は `mkdocs serve` でナビゲーションを確認する
+7. **フォーマット統一**: コミット前に `--lint` でフォーマットの一貫性を確保する
+
+### 関連スキル
+
+- `orchestrating-analysis` : 分析フェーズ全体の作業支援
+- `analyzing-requirements` : 要件定義関連の作業支援
+- `analyzing-architecture` : アーキテクチャ設計支援
+- `tracking-progress` : プロジェクト全体の進捗確認

package/lib/assets/.claude/skills/managing-operations/DEPLOY.md

@@ -0,0 +1,77 @@
+# デプロイメント管理・運用監視・バックアップ
+
+## デプロイメント管理
+
+ゼロダウンタイムデプロイとブルーグリーンデプロイメント。
+
+### 環境別デプロイ戦略
+
+- **Development**: 即座デプロイ・自動テスト実行
+- **Staging**: 統合テスト・パフォーマンステスト
+- **Production**: ブルーグリーンデプロイ・段階的ロールアウト
+
+```bash
+# ステージング環境への自動デプロイ
+# --deploy staging
+
+# 本番環境への慎重なデプロイ
+# --deploy production --strategy blue-green
+```
+
+## 運用監視とログ管理
+
+リアルタイム監視とプロアクティブなアラート。
+
+### 監視項目
+
+- **パフォーマンス**: CPU・メモリ・ディスク・ネットワーク使用率
+- **アプリケーション**: レスポンス時間・エラー率・スループット
+- **インフラ**: サーバー・データベース・外部 API の稼働状況
+- **ビジネス**: ユーザーアクティビティ・売上・KPI 指標
+
+```bash
+# 特定サービスのリアルタイムログ
+# --logs backend --follow
+
+# システム全体の統合ダッシュボード
+# --health --dashboard
+```
+
+## バックアップと災害復旧
+
+自動バックアップと迅速な災害復旧。
+
+### バックアップ対象
+
+- **データベース**: 完全バックアップ・増分バックアップ
+- **アプリケーション**: 設定ファイル・静的リソース・ログ
+- **インフラ**: 環境設定・SSL 証明書・監視設定
+
+```bash
+# 自動バックアップの実行
+# --backup --schedule daily
+
+# 緊急時の完全復元
+# --restore backup-2024-09-12-003000
+```
+
+## 連携シナリオ
+
+```bash
+# システム状況と組み合わせた総合分析
+ps aux | grep -E "(java|node|postgres)"
+netstat -tlnp | grep -E ":3000|:5432|:8080"
+# → --health
+# 「実行中プロセスとポート使用状況を含めた運用状況の総合分析」
+
+# Git 状況と組み合わせたデプロイ準備
+git log --oneline -5
+git status
+# → --deploy staging
+# 「最新コミットを含めたステージング環境へのデプロイ実行」
+
+# ログ分析と組み合わせた障害対応
+tail -100 /var/log/apps.log
+# → --rollback production
+# 「エラーログ分析に基づく緊急ロールバック実行」
+```