@k2works/claude-code-booster 3.5.0 → 3.6.1

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

@@ -1,72 +1,72 @@
----
-name: analyzing-usecases
-description: 要件定義からユースケースとユーザーストーリーを体系的に作成。ビジネスユースケース→システムユースケース→ユーザーストーリーの順に導出し、トレーサビリティを維持する。「ユースケースを作成したい」「ユーザーストーリーを書きたい」「要件定義からストーリーを導出したい」「受け入れ基準を定義したい」といった場面で発動する。ユースケースとストーリーを構造的に紐づけることで、開発フェーズでの「なぜこの機能を作るのか」が常に追跡可能になる。
----
-
-# ユースケース・ユーザーストーリー作成
-
-要件定義からユースケースを抽出し、ユーザーストーリーまで一貫したトレーサビリティを維持しながら作成する。
-
-ビジネスユースケース→システムユースケース→ユーザーストーリーの 3 段階で具体化することで、「ビジネス要求」と「実装タスク」の間の論理的なつながりを保証する。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @docs/reference/ユースケース作成ガイド.md | ユースケース作成の進め方詳細 |
-| テンプレート | @docs/template/完全形式のユースケース.md | 編集禁止。参照のみ |
-| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
-| 成果物 | `docs/requirements/business_usecase.md` | ビジネスユースケース |
-| 成果物 | `docs/requirements/system_usecase.md` | システムユースケース |
-| 成果物 | `docs/requirements/user_story.md` | ユーザーストーリー |
-
-## 作成の 3 ステップ
-
-### ステップ 1: ビジネスユースケース作成
-
-要件定義からビジネスレベルのユースケースを抽出する。システムの詳細には踏み込まず、業務目標とアクターの関係を定義する。
-
-- 要件定義のシステム外部環境（層 2）を起点にアクターとユースケースを識別する
-- アクターとユースケースの関係を PlantUML で図示する
-
-### ステップ 2: システムユースケース作成
-
-ビジネスユースケースをシステム境界の視点で詳細化する。「システムが何を提供するか」を明確にする。
-
-- ビジネスユースケースの各項目をシステムレベルに分解する
-- システム境界を明確にし、テンプレートの完全形式で記述する
-
-### ステップ 3: ユーザーストーリー作成
-
-システムユースケースから開発可能な粒度のユーザーストーリーを導出する。
-
-- 「〜として、〜したい。なぜなら〜だからだ」の形式で記述する
-- 各ストーリーに受け入れ基準を定義する
-- ユースケースとの対応関係を明記してトレーサビリティを確保する
-
-## 途中から再開・更新
-
-既存の成果物がある場合は、まず現在の状態を確認する。不足しているステップや更新が必要な部分のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「ビジネスユースケースは作った。ユーザーストーリーを書きたい」
-回答: ステップ 2（システムユースケース）の存在を確認する。
-      未作成ならステップ 2 から開始。作成済みならステップ 3 に進む。
-      既存のビジネスユースケースのアクターとユースケースを起点に、
-      システムユースケースを詳細化してからユーザーストーリーを導出する。
-```
-
-## 注意事項
-
-- 入力の `requirements_definition.md` が存在しない場合は `analyzing-requirements` を先に実行する
-- テンプレートは編集禁止。参照のみとし、成果物は別ファイルに作成する
-- `user_story.md` にはユーザーストーリーのみ記述する。リリース計画・イテレーション計画は `planning-releases` で別途作成する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `analyzing-requirements` — 前段の要件定義（RDRA 2.0）
-- `planning-releases` — 後続のリリース・イテレーション計画
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+---
+name: analyzing-usecases
+description: 要件定義からユースケースとユーザーストーリーを体系的に作成。ビジネスユースケース→システムユースケース→ユーザーストーリーの順に導出し、トレーサビリティを維持する。「ユースケースを作成したい」「ユーザーストーリーを書きたい」「要件定義からストーリーを導出したい」「受け入れ基準を定義したい」といった場面で発動する。ユースケースとストーリーを構造的に紐づけることで、開発フェーズでの「なぜこの機能を作るのか」が常に追跡可能になる。
+---
+
+# ユースケース・ユーザーストーリー作成
+
+要件定義からユースケースを抽出し、ユーザーストーリーまで一貫したトレーサビリティを維持しながら作成する。
+
+ビジネスユースケース→システムユースケース→ユーザーストーリーの 3 段階で具体化することで、「ビジネス要求」と「実装タスク」の間の論理的なつながりを保証する。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/ユースケース作成ガイド.md | ユースケース作成の進め方詳細 |
+| テンプレート | @docs/template/完全形式のユースケース.md | 編集禁止。参照のみ |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 成果物 | `docs/requirements/business_usecase.md` | ビジネスユースケース |
+| 成果物 | `docs/requirements/system_usecase.md` | システムユースケース |
+| 成果物 | `docs/requirements/user_story.md` | ユーザーストーリー |
+
+## 作成の 3 ステップ
+
+### ステップ 1: ビジネスユースケース作成
+
+要件定義からビジネスレベルのユースケースを抽出する。システムの詳細には踏み込まず、業務目標とアクターの関係を定義する。
+
+- 要件定義のシステム外部環境（層 2）を起点にアクターとユースケースを識別する
+- アクターとユースケースの関係を PlantUML で図示する
+
+### ステップ 2: システムユースケース作成
+
+ビジネスユースケースをシステム境界の視点で詳細化する。「システムが何を提供するか」を明確にする。
+
+- ビジネスユースケースの各項目をシステムレベルに分解する
+- システム境界を明確にし、テンプレートの完全形式で記述する
+
+### ステップ 3: ユーザーストーリー作成
+
+システムユースケースから開発可能な粒度のユーザーストーリーを導出する。
+
+- 「〜として、〜したい。なぜなら〜だからだ」の形式で記述する
+- 各ストーリーに受け入れ基準を定義する
+- ユースケースとの対応関係を明記してトレーサビリティを確保する
+
+## 途中から再開・更新
+
+既存の成果物がある場合は、まず現在の状態を確認する。不足しているステップや更新が必要な部分のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「ビジネスユースケースは作った。ユーザーストーリーを書きたい」
+回答: ステップ 2（システムユースケース）の存在を確認する。
+      未作成ならステップ 2 から開始。作成済みならステップ 3 に進む。
+      既存のビジネスユースケースのアクターとユースケースを起点に、
+      システムユースケースを詳細化してからユーザーストーリーを導出する。
+```
+
+## 注意事項
+
+- 入力の `requirements_definition.md` が存在しない場合は `analyzing-requirements` を先に実行する
+- テンプレートは編集禁止。参照のみとし、成果物は別ファイルに作成する
+- `user_story.md` にはユーザーストーリーのみ記述する。リリース計画・イテレーション計画は `planning-releases` で別途作成する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `analyzing-requirements` — 前段の要件定義（RDRA 2.0）
+- `planning-releases` — 後続のリリース・イテレーション計画
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内

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

@@ -1,113 +1,113 @@
----
-name: creating-adr
-description: Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。
----
-
-# ADR 作成
-
-アーキテクチャ決定記録（ADR）を作成・管理する。技術的意思決定のコンテキスト・決定内容・影響を構造化して記録する。
-
-ADR の価値は「決定そのもの」ではなく「なぜその決定に至ったか」を残すこと。代替案と却下理由を含めることで、将来の見直し時に同じ検討を繰り返さずに済む。
-
-## ADR テンプレート
-
-```markdown
-# ADR-NNN: タイトル
-
-簡潔な説明（1 行で決定内容を要約）。
-
-日付: YYYY-MM-DD
-
-## ステータス
-
-提案中 | 承認済み | 廃止 | 置換（ADR-XXX で置換）
-
-## コンテキスト
-
-この決定が必要になった背景・状況を説明。
-
-- 現在の課題や制約
-- 関連するシステムやサービス
-- ビジネス要件
-
-## 決定
-
-**何を決定したか** を明確に記述。
-
-### 変更箇所
-
-具体的な実装変更がある場合は記載。
-
-### 代替案
-
-検討した代替案とその却下理由。
-
-## 影響
-
-### ポジティブ
-
-- 良い影響
-
-### ネガティブ
-
-- 悪い影響や注意点
-
-## コンプライアンス
-
-決定が正しく実装されていることを確認する方法。
-
-## 備考
-
-- 著者: 担当者名
-- 関連コミット: コミットハッシュ
-- 関連 ADR: ADR-XXX
-```
-
-## ステータスの種類
-
-| ステータス | 説明 |
-|-----------|------|
-| 提案中 | レビュー待ちの ADR |
-| 承認済み | 採用された決定 |
-| 廃止 | 無効になった決定 |
-| 置換 | 別の ADR で置き換えられた |
-
-## 作成の進め方
-
-### 新規 ADR の作成
-
-1. `docs/adr/` ディレクトリ内の既存 ADR の最大番号を確認する
-2. 次の連番でテンプレートに基づいて ADR を作成する
-3. `docs/index.md` と `mkdocs.yml` を更新する
-
-### 既存設計からの ADR 抽出
-
-1. アーキテクチャ設計ドキュメントを読み込む
-2. 主要な技術的意思決定を識別する
-3. 各決定を ADR として記録する
-
-## 途中から再開・更新
-
-既存の ADR がある場合は `docs/adr/` の内容を確認する。ステータス変更や新規 ADR の追記のみを行う。
-
-**Example:**
-
-```
-ユーザー: 「フレームワークを変更する決定を記録したい」
-回答: docs/adr/ の最大番号を確認し、次の連番で ADR を作成する。
-      既存の関連 ADR があればステータスを「置換」に変更し、
-      新しい ADR の「コンテキスト」に経緯を記載する。
-```
-
-## 注意事項
-
-- 採番は `001` から連番。ファイル名は `NNN-kebab-case-title.md` 形式（例: `006-cache-strategy.md`）
-- 配置場所は必ず `docs/adr/`。新規作成時は `docs/index.md` と `mkdocs.yml` も更新する
-- ユーザーの指示があるまでコミットしない
-- コンテキストの明確化・代替案の記録・影響の両面記載・コンプライアンス項目を必ず含める
-
-## 関連スキル
-
-- `analyzing-architecture` — アーキテクチャ設計（ADR の主な発生源）
-- `analyzing-tech-stack` — 技術スタック選定（ADR として記録すべき決定）
-- `git-commit` — ADR 作成後のコミット
+---
+name: creating-adr
+description: Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。
+---
+
+# ADR 作成
+
+アーキテクチャ決定記録（ADR）を作成・管理する。技術的意思決定のコンテキスト・決定内容・影響を構造化して記録する。
+
+ADR の価値は「決定そのもの」ではなく「なぜその決定に至ったか」を残すこと。代替案と却下理由を含めることで、将来の見直し時に同じ検討を繰り返さずに済む。
+
+## ADR テンプレート
+
+```markdown
+# ADR-NNN: タイトル
+
+簡潔な説明（1 行で決定内容を要約）。
+
+日付: YYYY-MM-DD
+
+## ステータス
+
+提案中 | 承認済み | 廃止 | 置換（ADR-XXX で置換）
+
+## コンテキスト
+
+この決定が必要になった背景・状況を説明。
+
+- 現在の課題や制約
+- 関連するシステムやサービス
+- ビジネス要件
+
+## 決定
+
+**何を決定したか** を明確に記述。
+
+### 変更箇所
+
+具体的な実装変更がある場合は記載。
+
+### 代替案
+
+検討した代替案とその却下理由。
+
+## 影響
+
+### ポジティブ
+
+- 良い影響
+
+### ネガティブ
+
+- 悪い影響や注意点
+
+## コンプライアンス
+
+決定が正しく実装されていることを確認する方法。
+
+## 備考
+
+- 著者: 担当者名
+- 関連コミット: コミットハッシュ
+- 関連 ADR: ADR-XXX
+```
+
+## ステータスの種類
+
+| ステータス | 説明 |
+|-----------|------|
+| 提案中 | レビュー待ちの ADR |
+| 承認済み | 採用された決定 |
+| 廃止 | 無効になった決定 |
+| 置換 | 別の ADR で置き換えられた |
+
+## 作成の進め方
+
+### 新規 ADR の作成
+
+1. `docs/adr/` ディレクトリ内の既存 ADR の最大番号を確認する
+2. 次の連番でテンプレートに基づいて ADR を作成する
+3. `docs/index.md` と `mkdocs.yml` を更新する
+
+### 既存設計からの ADR 抽出
+
+1. アーキテクチャ設計ドキュメントを読み込む
+2. 主要な技術的意思決定を識別する
+3. 各決定を ADR として記録する
+
+## 途中から再開・更新
+
+既存の ADR がある場合は `docs/adr/` の内容を確認する。ステータス変更や新規 ADR の追記のみを行う。
+
+**Example:**
+
+```
+ユーザー: 「フレームワークを変更する決定を記録したい」
+回答: docs/adr/ の最大番号を確認し、次の連番で ADR を作成する。
+      既存の関連 ADR があればステータスを「置換」に変更し、
+      新しい ADR の「コンテキスト」に経緯を記載する。
+```
+
+## 注意事項
+
+- 採番は `001` から連番。ファイル名は `NNN-kebab-case-title.md` 形式（例: `006-cache-strategy.md`）
+- 配置場所は必ず `docs/adr/`。新規作成時は `docs/index.md` と `mkdocs.yml` も更新する
+- ユーザーの指示があるまでコミットしない
+- コンテキストの明確化・代替案の記録・影響の両面記載・コンプライアンス項目を必ず含める
+
+## 関連スキル
+
+- `analyzing-architecture` — アーキテクチャ設計（ADR の主な発生源）
+- `analyzing-tech-stack` — 技術スタック選定（ADR として記録すべき決定）
+- `git-commit` — ADR 作成後のコミット

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

@@ -1,100 +1,100 @@
----
-name: developing-backend
-description: バックエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとインサイドアウトアプローチで品質の高いバックエンドを実装する。「バックエンドを実装したい」「API を作りたい」「サーバーサイドの機能を追加したい」「バックエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、リファクタリングの安全網を確保し、変更を楽に安全にできるコードを維持する。
----
-
-# バックエンド開発
-
-TDD サイクルに従いバックエンドを開発する。インサイドアウトアプローチ（データ層→ドメイン層→API 層）で、内側から外側へ段階的に構築する。
-
-インサイドアウトの利点は、ドメインロジックのテストが外部依存なしで書けること。テストの実行速度が速く、フィードバックループを短く保てる。
-
-## 参照ドキュメント
-
-| 種類 | パス |
-|------|------|
-| ワークフロー | @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 |
-
-## TDD サイクル
-
-10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
-
-1. **Red**: 失敗するテストを最初に書く
-2. **Green**: テストを通す最小限のコードを実装する
-3. **Refactor**: 重複を除去し設計を改善する
-
-## アプローチ
-
-- **インサイドアウト**（推奨）: データ層から開始し上位層へ展開する
-- **アウトサイドイン**: API から開始しドメインロジックを段階的に実装する
-
-## テストコマンド
-
-```bash
-# 全テスト実行
-cd apps/backend && ./gradlew test
-
-# 特定テストクラス実行
-cd apps/backend && ./gradlew test --tests "UserServiceTest"
-
-# テストカバレッジ確認
-cd apps/backend && ./gradlew jacocoTestReport
-```
-
-## API ドキュメント
-
-```bash
-# バックエンドを起動
-cd apps/backend && ./gradlew bootRun
-# Swagger UI: http://localhost:8080/swagger-ui.html
-# OpenAPI JSON: http://localhost:8080/v3/api-docs
-```
-
-## 品質チェックリスト
-
-コミット前に必ず確認する。
-
-- [ ] すべてのテストがパス
-- [ ] ESLint/コンパイラの警告がゼロ
-- [ ] テストカバレッジが目標を満たしている
-- [ ] 単一の論理的作業単位を表現
-- [ ] コミットメッセージが変更内容を明確に説明
-
-## 途中から再開
-
-開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
-
-**Example:**
-
-```
-ユーザー: 「ユーザー認証の Entity と Repository は実装済み。Service 層に進みたい」
-回答: 既存テストを実行して Green 状態を確認する。
-      Service 層の失敗するテスト（Red）を書いてから実装に進む。
-      Repository の戻り値を使った Service のビジネスロジックをテストする。
-```
-
-## コンテキスト管理
-
-タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
-
-- TDD サイクルを数回繰り返した後、ユーザーストーリー完了時、コミット完了後に実施する
-- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
-
-## 注意事項
-
-- Java/Gradle のテスト環境が設定済みであること（前提条件）
-- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
-- コミット前に必ず品質チェックリストを実行する
-- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
-- TODO 駆動開発でタスクを細かく分割し、Rule of Three で 3 回同じコードが現れたらリファクタリングする
-
-## 関連スキル
-
-- `developing-frontend` — フロントエンド TDD 開発
-- `orchestrating-development` — 開発フェーズ全体のワークフロー
-- `git-commit` — Conventional Commits 準拠のコミット
+---
+name: developing-backend
+description: バックエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとインサイドアウトアプローチで品質の高いバックエンドを実装する。「バックエンドを実装したい」「API を作りたい」「サーバーサイドの機能を追加したい」「バックエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、リファクタリングの安全網を確保し、変更を楽に安全にできるコードを維持する。
+---
+
+# バックエンド開発
+
+TDD サイクルに従いバックエンドを開発する。インサイドアウトアプローチ（データ層→ドメイン層→API 層）で、内側から外側へ段階的に構築する。
+
+インサイドアウトの利点は、ドメインロジックのテストが外部依存なしで書けること。テストの実行速度が速く、フィードバックループを短く保てる。
+
+## 参照ドキュメント
+
+| 種類 | パス |
+|------|------|
+| ワークフロー | @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 |
+
+## TDD サイクル
+
+10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
+
+1. **Red**: 失敗するテストを最初に書く
+2. **Green**: テストを通す最小限のコードを実装する
+3. **Refactor**: 重複を除去し設計を改善する
+
+## アプローチ
+
+- **インサイドアウト**（推奨）: データ層から開始し上位層へ展開する
+- **アウトサイドイン**: API から開始しドメインロジックを段階的に実装する
+
+## テストコマンド
+
+```bash
+# 全テスト実行
+cd apps/backend && ./gradlew test
+
+# 特定テストクラス実行
+cd apps/backend && ./gradlew test --tests "UserServiceTest"
+
+# テストカバレッジ確認
+cd apps/backend && ./gradlew jacocoTestReport
+```
+
+## API ドキュメント
+
+```bash
+# バックエンドを起動
+cd apps/backend && ./gradlew bootRun
+# Swagger UI: http://localhost:8080/swagger-ui.html
+# OpenAPI JSON: http://localhost:8080/v3/api-docs
+```
+
+## 品質チェックリスト
+
+コミット前に必ず確認する。
+
+- [ ] すべてのテストがパス
+- [ ] ESLint/コンパイラの警告がゼロ
+- [ ] テストカバレッジが目標を満たしている
+- [ ] 単一の論理的作業単位を表現
+- [ ] コミットメッセージが変更内容を明確に説明
+
+## 途中から再開
+
+開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
+
+**Example:**
+
+```
+ユーザー: 「ユーザー認証の Entity と Repository は実装済み。Service 層に進みたい」
+回答: 既存テストを実行して Green 状態を確認する。
+      Service 層の失敗するテスト（Red）を書いてから実装に進む。
+      Repository の戻り値を使った Service のビジネスロジックをテストする。
+```
+
+## コンテキスト管理
+
+タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
+
+- TDD サイクルを数回繰り返した後、ユーザーストーリー完了時、コミット完了後に実施する
+- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
+
+## 注意事項
+
+- Java/Gradle のテスト環境が設定済みであること（前提条件）
+- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
+- コミット前に必ず品質チェックリストを実行する
+- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
+- TODO 駆動開発でタスクを細かく分割し、Rule of Three で 3 回同じコードが現れたらリファクタリングする
+
+## 関連スキル
+
+- `developing-frontend` — フロントエンド TDD 開発
+- `orchestrating-development` — 開発フェーズ全体のワークフロー
+- `git-commit` — Conventional Commits 準拠のコミット