@k2works/claude-code-booster 1.10.0 → 1.11.0

package/lib/assets/.claude/skills/analyzing-usecases/SKILL.md

@@ -1,87 +1,87 @@
----
-name: analyzing-usecases
-description: ユースケースとユーザーストーリーの作成を支援。ビジネスユースケースの抽出からシステムユースケースの定義まで。ユースケース分析やストーリー作成時に使用。
----
-
-# ユースケース・ユーザーストーリー作成支援
-
-要件定義からユースケースを抽出し、トレーサビリティを維持します。
-
-## Instructions
-
-### 1. 参照ドキュメント
-
-- @docs/reference/ユースケース作成ガイド.md - ユースケース作成の進め方
-
-### 2. テンプレート
-
-- @docs/template/完全形式のユースケース.md - ユースケーステンプレート（**編集禁止**）
-
-### 3. 入力
-
-- @docs/requirements/requirements_definition.md - 要件定義
-
-### 4. 成果物
-
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
-
-### 5. 作業内容
-
-#### ビジネスユースケース作成
-
-- 要件定義からビジネスユースケースを抽出
-- アクターとユースケースの関係を定義
-
-#### システムユースケース作成
-
-- ビジネスユースケースを詳細化
-- システム境界を明確化
-
-#### ユーザーストーリー作成
-
-- システムユースケースからユーザーストーリーを導出
-- 受け入れ基準の定義
-
-#### トレーサビリティ維持
-
-- ユースケースとユーザーストーリー間のトレーサビリティを確保
-
-### 6. 注意事項
-
-- **前提条件**: @docs/requirements/requirements_definition.md が存在すること
-- **制限事項**:
-  - テンプレート @docs/template/完全形式のユースケース.md は絶対に編集しないこと
-  - user_story.md にはユーザーストーリーのみ記述する
-  - リリース計画とイテレーション計画は別途作成する
-- **推奨事項**: ユースケースとユーザーストーリーでトレーサビリティを維持する
-
-### 7. 記述ルール
-
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] ビジネスユースケースが作成されている
-- [ ] ユーザーストーリーが作成されている
-```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] ビジネスユースケースが作成されている
-- [ ] ユーザーストーリーが作成されている
-```
-
-## Examples
-
-### 要件定義に基づくユースケース作成
-
-1. @docs/requirements/requirements_definition.md を読み込む
-2. @docs/reference/ユースケース作成ガイド.md に基づいてユースケースを作成
-3. ビジネスユースケース → システムユースケース → ユーザーストーリーの順に作成
+---
+name: analyzing-usecases
+description: ユースケースとユーザーストーリーの作成を支援。ビジネスユースケースの抽出からシステムユースケースの定義まで。ユースケース分析やストーリー作成時に使用。
+---
+
+# ユースケース・ユーザーストーリー作成支援
+
+要件定義からユースケースを抽出し、トレーサビリティを維持します。
+
+## Instructions
+
+### 1. 参照ドキュメント
+
+- @docs/reference/ユースケース作成ガイド.md - ユースケース作成の進め方
+
+### 2. テンプレート
+
+- @docs/template/完全形式のユースケース.md - ユースケーステンプレート（**編集禁止**）
+
+### 3. 入力
+
+- @docs/requirements/requirements_definition.md - 要件定義
+
+### 4. 成果物
+
+- @docs/requirements/business_usecase.md - ビジネスユースケース
+- @docs/requirements/system_usecase.md - システムユースケース
+- @docs/requirements/user_story.md - ユーザーストーリー
+
+### 5. 作業内容
+
+#### ビジネスユースケース作成
+
+- 要件定義からビジネスユースケースを抽出
+- アクターとユースケースの関係を定義
+
+#### システムユースケース作成
+
+- ビジネスユースケースを詳細化
+- システム境界を明確化
+
+#### ユーザーストーリー作成
+
+- システムユースケースからユーザーストーリーを導出
+- 受け入れ基準の定義
+
+#### トレーサビリティ維持
+
+- ユースケースとユーザーストーリー間のトレーサビリティを確保
+
+### 6. 注意事項
+
+- **前提条件**: @docs/requirements/requirements_definition.md が存在すること
+- **制限事項**:
+  - テンプレート @docs/template/完全形式のユースケース.md は絶対に編集しないこと
+  - user_story.md にはユーザーストーリーのみ記述する
+  - リリース計画とイテレーション計画は別途作成する
+- **推奨事項**: ユースケースとユーザーストーリーでトレーサビリティを維持する
+
+### 7. 記述ルール
+
+タスク項目などは一行開けて記述する。
+
+OK:
+
+```markdown
+**受入条件**:
+
+- [ ] ビジネスユースケースが作成されている
+- [ ] ユーザーストーリーが作成されている
+```
+
+NG:
+
+```markdown
+**受入条件**:
+- [ ] ビジネスユースケースが作成されている
+- [ ] ユーザーストーリーが作成されている
+```
+
+## Examples
+
+### 要件定義に基づくユースケース作成
+
+1. @docs/requirements/requirements_definition.md を読み込む
+2. @docs/reference/ユースケース作成ガイド.md に基づいてユースケースを作成
+3. ビジネスユースケース → システムユースケース → ユーザーストーリーの順に作成

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

@@ -1,115 +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 として記録
+---
+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

@@ -1,106 +1,106 @@
----
-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. コンテキスト管理
-
-長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
-
-**`/compact` を実施するタイミング**:
-
-- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
-- ユーザーストーリー 1 件の実装が完了したとき
-- コミット完了後、次のタスクに着手する前
-- テストスイートの実行と結果確認が完了したとき
-
-**運用ルール**:
-
-1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
-2. `/compact` 実施後、次のタスクの作業を継続する
-3. 大規模なユーザーストーリーでは、サブタスクごとに `/compact` を検討する
-
-### 8. 注意事項
-
-- **前提条件**: 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 回現れたらリファクタリング
+---
+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. コンテキスト管理
+
+長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
+- ユーザーストーリー 1 件の実装が完了したとき
+- コミット完了後、次のタスクに着手する前
+- テストスイートの実行と結果確認が完了したとき
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
+2. `/compact` 実施後、次のタスクの作業を継続する
+3. 大規模なユーザーストーリーでは、サブタスクごとに `/compact` を検討する
+
+### 8. 注意事項
+
+- **前提条件**: 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 回現れたらリファクタリング