@k2works/claude-code-booster 1.10.0 → 1.11.0

package/lib/assets/.claude/settings.json

@@ -1,11 +1,11 @@
-{
-  "env": {
-    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
-  },
-  "permissions": {
-    "defaultMode": "plan",
-    "allow": [],
-    "deny": [],
-    "ask": []
-  }
-}
+{
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
+  },
+  "permissions": {
+    "defaultMode": "plan",
+    "allow": [],
+    "deny": [],
+    "ask": []
+  }
+}

package/lib/assets/.claude/skills/ai-agent-guidelines/SKILL.md

@@ -1,119 +1,119 @@
----
-name: ai-agent-guidelines
-description: AI Agent の実行ガイドライン。TDD サイクル、品質保証、コンテキスト管理、完了報告のルールを定義。すべての開発タスク実行時に使用。
----
-
-# AI Agent 実行ガイドライン
-
-**最重要**：自律的に判断・実行。確認は最小限に。
-
-## Instructions
-
-### 1. ペルソナ
-
-あなたは**よいソフトウェア**に対する明確な考えと**よいソフトウェア**を作るための規律を持った開発経験豊富な開発者です。
-
-- @docs/reference/よいソフトウェアとは.md を参照
-- @docs/reference/開発ガイド.md に従い問題解決に取り組む
-
-### 2. コア原則
-
-- **即座実行** — 既存ファイルの編集は迷わず着手
-- **大規模変更のみ確認** — 影響範囲が広い場合に限定
-- **品質と一貫性の維持** — 自動チェックを徹底
-- **事実確認** — 情報源を自ら確認し、憶測を事実として述べない
-- **既存優先** — 新規作成より既存ファイルの編集を優先
-
-### 3. 実行ルール
-
-#### 即座実行（確認不要）
-
-- コード操作：バグ修正、リファクタリング、パフォーマンス改善
-- ファイル編集：既存ファイルの修正・更新
-- ドキュメント：README、仕様書の更新
-- 依存関係：パッケージ追加・更新・削除
-- テスト：単体・統合テストの実装
-- 設定：設定値変更、フォーマット適用
-
-#### 確認必須
-
-- 新規ファイル作成、ファイル削除
-- アーキテクチャ、フォルダ構造の大規模変更
-- 新 API、外部ライブラリ導入
-- 認証・認可機能の実装
-- スキーマ変更、マイグレーション
-- デプロイ設定、環境変数変更
-
-### 4. 開発ワークフロー（TDD サイクル）
-
-1. **Red** — 失敗するテストを書く
-2. **Green** — テストを通す最小限のコードを実装
-3. **Refactor** — 重複を排除し、意図を明確に
-4. **Commit** — すべてのテストがパスしたらコミット
-
-**重要**：構造変更と動作変更を同一コミットに含めない
-
-### 5. 品質保証
-
-- 単一責任の原則を遵守
-- 重複コードなし
-- マジックナンバーは定数化
-- エラー発生時：代替案 3 つ提示、または可能部分を先行実行
-
-### 6. コンテキスト管理
-
-- 会話開始時：「Remembering...」と言って記憶を取得
-- 純粋タスク（バグ修正、テスト実行）は独立実行
-- コンテキスト肥大化時：`/compact` コマンドを推奨
-
-### 7. 完了報告
-
-#### 完全完了時
-
-```text
-Simple made easy.
-```
-
-**条件**：全タスク完了、TODO 空、エラーゼロ、継続タスクなし
-
-#### 部分完了時
-
-```markdown
-## 実行完了
-
-### 変更内容
-- [具体的な変更点]
-
-### 次のステップ
-- [推奨される次の作業]
-```
-
-## Examples
-
-### バグ修正
-
-1. `TypeError` 発見 → 失敗するテストを書く
-2. バグを修正してテストをパス
-3. コミット
-4. `Simple made easy.`
-
-### リファクタリング
-
-1. 重複コード検出
-2. テストがパスしていることを確認
-3. 共通関数に抽出
-4. テスト実行して確認
-5. コミット
-
-### DB 変更
-
-1. スキーマ更新が必要と判断
-2. 確認要求「テーブル構造を変更しますか？」
-3. 承認後にマイグレーション作成
-
-## 基本設定
-
-- 言語：日本語（技術用語は英語）
-- スペース：日本語と半角英数字間に半角スペース
-- 文体：ですます調、句読点は「。」「、」
-- 略語：`y`=Yes, `n`=No, `c`=Continue, `r`=Review, `u`=Undo
+---
+name: ai-agent-guidelines
+description: AI Agent の実行ガイドライン。TDD サイクル、品質保証、コンテキスト管理、完了報告のルールを定義。すべての開発タスク実行時に使用。
+---
+
+# AI Agent 実行ガイドライン
+
+**最重要**：自律的に判断・実行。確認は最小限に。
+
+## Instructions
+
+### 1. ペルソナ
+
+あなたは**よいソフトウェア**に対する明確な考えと**よいソフトウェア**を作るための規律を持った開発経験豊富な開発者です。
+
+- @docs/reference/よいソフトウェアとは.md を参照
+- @docs/reference/開発ガイド.md に従い問題解決に取り組む
+
+### 2. コア原則
+
+- **即座実行** — 既存ファイルの編集は迷わず着手
+- **大規模変更のみ確認** — 影響範囲が広い場合に限定
+- **品質と一貫性の維持** — 自動チェックを徹底
+- **事実確認** — 情報源を自ら確認し、憶測を事実として述べない
+- **既存優先** — 新規作成より既存ファイルの編集を優先
+
+### 3. 実行ルール
+
+#### 即座実行（確認不要）
+
+- コード操作：バグ修正、リファクタリング、パフォーマンス改善
+- ファイル編集：既存ファイルの修正・更新
+- ドキュメント：README、仕様書の更新
+- 依存関係：パッケージ追加・更新・削除
+- テスト：単体・統合テストの実装
+- 設定：設定値変更、フォーマット適用
+
+#### 確認必須
+
+- 新規ファイル作成、ファイル削除
+- アーキテクチャ、フォルダ構造の大規模変更
+- 新 API、外部ライブラリ導入
+- 認証・認可機能の実装
+- スキーマ変更、マイグレーション
+- デプロイ設定、環境変数変更
+
+### 4. 開発ワークフロー（TDD サイクル）
+
+1. **Red** — 失敗するテストを書く
+2. **Green** — テストを通す最小限のコードを実装
+3. **Refactor** — 重複を排除し、意図を明確に
+4. **Commit** — すべてのテストがパスしたらコミット
+
+**重要**：構造変更と動作変更を同一コミットに含めない
+
+### 5. 品質保証
+
+- 単一責任の原則を遵守
+- 重複コードなし
+- マジックナンバーは定数化
+- エラー発生時：代替案 3 つ提示、または可能部分を先行実行
+
+### 6. コンテキスト管理
+
+- 会話開始時：「Remembering...」と言って記憶を取得
+- 純粋タスク（バグ修正、テスト実行）は独立実行
+- コンテキスト肥大化時：`/compact` コマンドを推奨
+
+### 7. 完了報告
+
+#### 完全完了時
+
+```text
+Simple made easy.
+```
+
+**条件**：全タスク完了、TODO 空、エラーゼロ、継続タスクなし
+
+#### 部分完了時
+
+```markdown
+## 実行完了
+
+### 変更内容
+- [具体的な変更点]
+
+### 次のステップ
+- [推奨される次の作業]
+```
+
+## Examples
+
+### バグ修正
+
+1. `TypeError` 発見 → 失敗するテストを書く
+2. バグを修正してテストをパス
+3. コミット
+4. `Simple made easy.`
+
+### リファクタリング
+
+1. 重複コード検出
+2. テストがパスしていることを確認
+3. 共通関数に抽出
+4. テスト実行して確認
+5. コミット
+
+### DB 変更
+
+1. スキーマ更新が必要と判断
+2. 確認要求「テーブル構造を変更しますか？」
+3. 承認後にマイグレーション作成
+
+## 基本設定
+
+- 言語：日本語（技術用語は英語）
+- スペース：日本語と半角英数字間に半角スペース
+- 文体：ですます調、句読点は「。」「、」
+- 略語：`y`=Yes, `n`=No, `c`=Continue, `r`=Review, `u`=Undo

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

@@ -1,87 +1,87 @@
----
-name: analyzing-architecture
-description: アーキテクチャ設計を支援。バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成。アーキテクチャ設計やシステム構成の検討時に使用。
----
-
-# アーキテクチャ設計支援
-
-業務領域とデータ構造の複雑さに基づくアーキテクチャパターンの選択を支援します。
-
-## Instructions
-
-### 1. 参照ドキュメント
-
-- @docs/reference/アーキテクチャ設計ガイド.md - アーキテクチャ設計の進め方
-
-### 2. 入力
-
-- @docs/requirements/requirements_definition.md - 要件定義
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
-
-### 3. 成果物
-
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
-- @docs/design/architecture_infrastructure.md - インフラストラクチャアーキテクチャ
-
-### 4. 作業内容
-
-#### バックエンドアーキテクチャ設計
-
-- アーキテクチャパターンの選択（レイヤード、ヘキサゴナル、クリーン等）
-- CQRS/イベントソーシングの適用判断
-- API 設計方針
-
-#### フロントエンドアーキテクチャ設計
-
-- フレームワーク選定
-- 状態管理パターン
-- コンポーネント設計方針
-
-#### インフラストラクチャアーキテクチャ設計
-
-- クラウド/オンプレミス選定
-- コンテナ化戦略
-- CI/CD パイプライン設計
-
-### 5. 注意事項
-
-- **前提条件**: 要件定義とユースケースが完了していること
-- **制限事項**: アーキテクチャ決定は ADR（Architecture Decision Record）で記録すること
-- **推奨事項**: 業務の複雑さとチームのスキルセットを考慮して選択する
-
-### 6. 記述ルール
-
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
-```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
-```
-
-## Examples
-
-### 要件に基づくアーキテクチャ設計
-
-1. 要件定義とユーザーストーリーを読み込む
-2. @docs/reference/アーキテクチャ設計ガイド.md に基づいて設計
-3. バックエンド・フロントエンド・インフラの各アーキテクチャドキュメントを作成
-
-### 技術的制約がある場合
-
-1. 既存の `package.json` や `pom.xml` を確認
-2. 既存技術スタックを考慮したアーキテクチャ選択を提案
+---
+name: analyzing-architecture
+description: アーキテクチャ設計を支援。バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成。アーキテクチャ設計やシステム構成の検討時に使用。
+---
+
+# アーキテクチャ設計支援
+
+業務領域とデータ構造の複雑さに基づくアーキテクチャパターンの選択を支援します。
+
+## Instructions
+
+### 1. 参照ドキュメント
+
+- @docs/reference/アーキテクチャ設計ガイド.md - アーキテクチャ設計の進め方
+
+### 2. 入力
+
+- @docs/requirements/requirements_definition.md - 要件定義
+- @docs/requirements/business_usecase.md - ビジネスユースケース
+- @docs/requirements/system_usecase.md - システムユースケース
+- @docs/requirements/user_story.md - ユーザーストーリー
+
+### 3. 成果物
+
+- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
+- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
+- @docs/design/architecture_infrastructure.md - インフラストラクチャアーキテクチャ
+
+### 4. 作業内容
+
+#### バックエンドアーキテクチャ設計
+
+- アーキテクチャパターンの選択（レイヤード、ヘキサゴナル、クリーン等）
+- CQRS/イベントソーシングの適用判断
+- API 設計方針
+
+#### フロントエンドアーキテクチャ設計
+
+- フレームワーク選定
+- 状態管理パターン
+- コンポーネント設計方針
+
+#### インフラストラクチャアーキテクチャ設計
+
+- クラウド/オンプレミス選定
+- コンテナ化戦略
+- CI/CD パイプライン設計
+
+### 5. 注意事項
+
+- **前提条件**: 要件定義とユースケースが完了していること
+- **制限事項**: アーキテクチャ決定は ADR（Architecture Decision Record）で記録すること
+- **推奨事項**: 業務の複雑さとチームのスキルセットを考慮して選択する
+
+### 6. 記述ルール
+
+タスク項目などは一行開けて記述する。
+
+OK:
+
+```markdown
+**受入条件**:
+
+- [ ] ログアウトボタンをクリックするとログアウトできる
+- [ ] ログアウト後、ログイン画面に遷移する
+```
+
+NG:
+
+```markdown
+**受入条件**:
+- [ ] ログアウトボタンをクリックするとログアウトできる
+- [ ] ログアウト後、ログイン画面に遷移する
+```
+
+## Examples
+
+### 要件に基づくアーキテクチャ設計
+
+1. 要件定義とユーザーストーリーを読み込む
+2. @docs/reference/アーキテクチャ設計ガイド.md に基づいて設計
+3. バックエンド・フロントエンド・インフラの各アーキテクチャドキュメントを作成
+
+### 技術的制約がある場合
+
+1. 既存の `package.json` や `pom.xml` を確認
+2. 既存技術スタックを考慮したアーキテクチャ選択を提案

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

@@ -1,117 +1,117 @@
----
-name: analyzing-business
-description: ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオの作成。ビジネスアーキテクチャやビジネス構造の検討時に使用。
----
-
-# ビジネスアーキテクチャ分析支援
-
-要件定義の前段階として、エンタープライズがどのように価値を生み出し、顧客に提供するかの構造を体系的に整理・設計します。本スキルの成果物は後続の要件定義（`analyzing-requirements`）やユースケース分析（`analyzing-usecases`）の入力となります。
-
-## Instructions
-
-### 1. 参照ドキュメント
-
-- @docs/reference/ビジネスアーキテクチャ分析ガイド.md - ビジネスアーキテクチャ分析の進め方
-
-### 2. テンプレート
-
-- @docs/template/ビジネスアーキテクチャ.md - ビジネスアーキテクチャテンプレート（**編集禁止**）
-
-### 3. 入力
-
-- プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）
-- ステークホルダーからのヒアリング情報
-
-### 4. 成果物
-
-- @docs/analysis/business_architecture.md - ビジネスアーキテクチャ分析書
-
-### 5. 作業内容
-
-#### プリンシプルの定義
-
-- ガイディングプリンシプル（ビジョン、ミッション、価値観に基づく方針）の策定
-- ビジネスプリンシプル（ビジネスにおける原則原理）の定義
-
-#### ビジネスモデルの整理
-
-- ビジネスモデルキャンバスの作成
-  - 顧客セグメント、価値提案、チャネル、顧客関係の整理
-  - 主要活動、主要リソース、主要パートナーの特定
-  - 収益源、コスト構造の明確化
-
-#### バリューストリームの設計
-
-- バリュー（価値）の分析
-- バリューストリームマップの作成
-- 各ステージでの価値増加の可視化
-
-#### ビジネスケイパビリティモデルの構築
-
-- ビジネスケイパビリティの特定（戦略・コア・サポート）
-- ケイパビリティの階層化とレベリング
-- ヒートマッピングによる成熟度評価
-- ケイパビリティとバリューストリームのマッピング
-
-#### 組織マップの作成
-
-- 部門・組織構造の整理
-- 組織とケイパビリティの対応付け
-
-#### 情報マップの作成
-
-- ビジネスエンティティの特定
-- エンティティ間のリレーション整理
-
-#### ビジネスシナリオの策定
-
-- 問題の特定と文書化
-- ビジネス・技術環境のモデル化
-- ゴールと期待する結果の定義
-- ヒューマンアクター・コンピュータアクターの特定
-
-### 6. 注意事項
-
-- **前提条件**: プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）が提供されていること
-- **制限事項**: ビジネスアーキテクチャの決定は ADR で記録すること
-- **推奨事項**: バリューストリームを先に作成し、その後ケイパビリティモデルを構築する
-
-### 7. 記述ルール
-
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] ビジネスモデルキャンバスが作成されている
-- [ ] バリューストリームマップが作成されている
-```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] ビジネスモデルキャンバスが作成されている
-- [ ] バリューストリームマップが作成されている
-```
-
-## Examples
-
-### 新規プロジェクトでビジネスアーキテクチャを設計
-
-1. プロジェクトの基本情報とビジネス概要を確認
-2. @docs/reference/ビジネスアーキテクチャ分析ガイド.md に基づいて分析
-3. ビジネスモデルキャンバス → バリューストリーム → ケイパビリティモデルの順に作成
-
-### 既存ビジネスの分析・改善
-
-1. 既存の @docs/design/business_architecture.md を読み込む
-2. ヒートマッピングで成熟度を評価し改善提案を作成
-
-### 関連スキル
-
-- `analyzing-requirements` : 後続の要件定義（本スキルの成果物が入力となる）
-- `analyzing-usecases` : 後続のビジネスユースケース詳細化
-- `analyzing-architecture` : 後続のシステムアーキテクチャ設計への橋渡し
+---
+name: analyzing-business
+description: ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオの作成。ビジネスアーキテクチャやビジネス構造の検討時に使用。
+---
+
+# ビジネスアーキテクチャ分析支援
+
+要件定義の前段階として、エンタープライズがどのように価値を生み出し、顧客に提供するかの構造を体系的に整理・設計します。本スキルの成果物は後続の要件定義（`analyzing-requirements`）やユースケース分析（`analyzing-usecases`）の入力となります。
+
+## Instructions
+
+### 1. 参照ドキュメント
+
+- @docs/reference/ビジネスアーキテクチャ分析ガイド.md - ビジネスアーキテクチャ分析の進め方
+
+### 2. テンプレート
+
+- @docs/template/ビジネスアーキテクチャ.md - ビジネスアーキテクチャテンプレート（**編集禁止**）
+
+### 3. 入力
+
+- プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）
+- ステークホルダーからのヒアリング情報
+
+### 4. 成果物
+
+- @docs/analysis/business_architecture.md - ビジネスアーキテクチャ分析書
+
+### 5. 作業内容
+
+#### プリンシプルの定義
+
+- ガイディングプリンシプル（ビジョン、ミッション、価値観に基づく方針）の策定
+- ビジネスプリンシプル（ビジネスにおける原則原理）の定義
+
+#### ビジネスモデルの整理
+
+- ビジネスモデルキャンバスの作成
+  - 顧客セグメント、価値提案、チャネル、顧客関係の整理
+  - 主要活動、主要リソース、主要パートナーの特定
+  - 収益源、コスト構造の明確化
+
+#### バリューストリームの設計
+
+- バリュー（価値）の分析
+- バリューストリームマップの作成
+- 各ステージでの価値増加の可視化
+
+#### ビジネスケイパビリティモデルの構築
+
+- ビジネスケイパビリティの特定（戦略・コア・サポート）
+- ケイパビリティの階層化とレベリング
+- ヒートマッピングによる成熟度評価
+- ケイパビリティとバリューストリームのマッピング
+
+#### 組織マップの作成
+
+- 部門・組織構造の整理
+- 組織とケイパビリティの対応付け
+
+#### 情報マップの作成
+
+- ビジネスエンティティの特定
+- エンティティ間のリレーション整理
+
+#### ビジネスシナリオの策定
+
+- 問題の特定と文書化
+- ビジネス・技術環境のモデル化
+- ゴールと期待する結果の定義
+- ヒューマンアクター・コンピュータアクターの特定
+
+### 6. 注意事項
+
+- **前提条件**: プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）が提供されていること
+- **制限事項**: ビジネスアーキテクチャの決定は ADR で記録すること
+- **推奨事項**: バリューストリームを先に作成し、その後ケイパビリティモデルを構築する
+
+### 7. 記述ルール
+
+タスク項目などは一行開けて記述する。
+
+OK:
+
+```markdown
+**受入条件**:
+
+- [ ] ビジネスモデルキャンバスが作成されている
+- [ ] バリューストリームマップが作成されている
+```
+
+NG:
+
+```markdown
+**受入条件**:
+- [ ] ビジネスモデルキャンバスが作成されている
+- [ ] バリューストリームマップが作成されている
+```
+
+## Examples
+
+### 新規プロジェクトでビジネスアーキテクチャを設計
+
+1. プロジェクトの基本情報とビジネス概要を確認
+2. @docs/reference/ビジネスアーキテクチャ分析ガイド.md に基づいて分析
+3. ビジネスモデルキャンバス → バリューストリーム → ケイパビリティモデルの順に作成
+
+### 既存ビジネスの分析・改善
+
+1. 既存の @docs/design/business_architecture.md を読み込む
+2. ヒートマッピングで成熟度を評価し改善提案を作成
+
+### 関連スキル
+
+- `analyzing-requirements` : 後続の要件定義（本スキルの成果物が入力となる）
+- `analyzing-usecases` : 後続のビジネスユースケース詳細化
+- `analyzing-architecture` : 後続のシステムアーキテクチャ設計への橋渡し