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

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

@@ -1,83 +1,83 @@
----
-name: analyzing-architecture
-description: バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成を支援。「アーキテクチャを設計したい」「システム構成を検討したい」「レイヤード/ヘキサゴナル/クリーンどれが適切か」「CQRS を導入すべきか」「フロントエンドのアーキテクチャを決めたい」といった場面で発動する。アーキテクチャを早期に設計することで、開発フェーズでの技術的負債の蓄積を防ぐ。
----
-
-# アーキテクチャ設計
-
-業務領域とデータ構造の複雑さに基づき、バックエンド・フロントエンド・インフラの各アーキテクチャパターンを選択し設計ドキュメントを作成する。
-
-アーキテクチャは後から変えるコストが最も高い設計判断。要件定義の段階で適切なパターンを選定することで、開発全体の方向性を確定し、手戻りを最小化する。
-
-## 参照ドキュメントとテンプレート
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| ガイド | @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 | ユーザーストーリー |
-| 成果物 | `docs/design/architecture_backend.md` | バックエンドアーキテクチャ |
-| 成果物 | `docs/design/architecture_frontend.md` | フロントエンドアーキテクチャ |
-| 成果物 | `docs/design/architecture_infrastructure.md` | インフラストラクチャアーキテクチャ |
-
-## バックエンドアーキテクチャ設計
-
-業務ロジックの複雑さに応じてパターンを選択する。単純な CRUD ならレイヤードで十分だが、ドメインが複雑な場合はヘキサゴナルやクリーンアーキテクチャを採用せよ。
-
-- **アーキテクチャパターンの選択**: レイヤード、ヘキサゴナル、クリーン等から要件に最適なものを選定する
-- **CQRS/イベントソーシングの適用判断**: 読み書きの特性が大きく異なる場合に検討する。過剰適用は複雑さを増すだけなので慎重に判断せよ
-- **API 設計方針**: REST/GraphQL/gRPC の選択基準を明確にする
-
-## フロントエンドアーキテクチャ設計
-
-ユーザー体験とチームのスキルセットを考慮して設計する。フレームワーク選定はプロジェクト全体に影響するため、ADR で判断根拠を残せ。
-
-- **フレームワーク選定**: プロジェクト要件に合ったフレームワークを選択する
-- **状態管理パターン**: アプリケーションの状態の複雑さに応じて適切なパターンを選定する
-- **コンポーネント設計方針**: 再利用性と保守性を両立する設計指針を定める
-
-## インフラストラクチャアーキテクチャ設計
-
-非機能要件（可用性・スケーラビリティ）を実現するインフラ構成を設計する。運用コストとの兼ね合いも考慮せよ。
-
-- **クラウド/オンプレミス選定**: コスト・セキュリティ・運用負荷を総合的に判断する
-- **コンテナ化戦略**: コンテナ化の適用範囲とオーケストレーション方式を決定する
-- **CI/CD パイプライン設計**: ビルド・テスト・デプロイの自動化方針を定める
-
-## 作成の進め方
-
-1. 入力ドキュメント（要件定義、ユースケース、ユーザーストーリー）を確認する。なければ基本情報をヒアリングする
-2. @docs/reference/アーキテクチャ設計ガイド.md を読み込む
-3. バックエンド→フロントエンド→インフラの順に設計する。各アーキテクチャの選定理由を明記せよ
-4. 重要な設計判断は ADR（Architecture Decision Record）で記録する
-
-## 途中から再開する場合
-
-既存の `docs/design/architecture_*.md` がある場合は、まずその内容を確認する。不足している領域や更新が必要な部分のみを修正する。
-
-**Example:**
-
-```
-ユーザー: 「バックエンドはクリーンアーキテクチャで決めた。フロントエンドを設計したい」
-回答: 既存の architecture_backend.md を確認し、
-      バックエンドの API 設計方針を踏まえてフロントエンドアーキテクチャ設計に進む。
-      フレームワーク選定→状態管理→コンポーネント設計の順で作成する。
-```
-
-## 注意事項
-
-- 要件定義とユースケースが完了していることが前提。未完了でもプロジェクト情報から進めて構わない
-- アーキテクチャ決定は必ず ADR で記録する。「なぜその選択をしたか」が後で最も重要になる
-- 業務の複雑さとチームのスキルセットを考慮して選択する。技術的に「正しい」選択よりチームが運用できる選択を優先せよ
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
-- `analyzing-requirements` — 前段の要件定義
-- `analyzing-domain-model` — 後続のドメインモデル設計
-- `analyzing-data-model` — 後続のデータモデル設計
-- `analyzing-tech-stack` — 後続の技術スタック選定
+---
+name: analyzing-architecture
+description: バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成を支援。「アーキテクチャを設計したい」「システム構成を検討したい」「レイヤード/ヘキサゴナル/クリーンどれが適切か」「CQRS を導入すべきか」「フロントエンドのアーキテクチャを決めたい」といった場面で発動する。アーキテクチャを早期に設計することで、開発フェーズでの技術的負債の蓄積を防ぐ。
+---
+
+# アーキテクチャ設計
+
+業務領域とデータ構造の複雑さに基づき、バックエンド・フロントエンド・インフラの各アーキテクチャパターンを選択し設計ドキュメントを作成する。
+
+アーキテクチャは後から変えるコストが最も高い設計判断。要件定義の段階で適切なパターンを選定することで、開発全体の方向性を確定し、手戻りを最小化する。
+
+## 参照ドキュメントとテンプレート
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @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 | ユーザーストーリー |
+| 成果物 | `docs/design/architecture_backend.md` | バックエンドアーキテクチャ |
+| 成果物 | `docs/design/architecture_frontend.md` | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/architecture_infrastructure.md` | インフラストラクチャアーキテクチャ |
+
+## バックエンドアーキテクチャ設計
+
+業務ロジックの複雑さに応じてパターンを選択する。単純な CRUD ならレイヤードで十分だが、ドメインが複雑な場合はヘキサゴナルやクリーンアーキテクチャを採用せよ。
+
+- **アーキテクチャパターンの選択**: レイヤード、ヘキサゴナル、クリーン等から要件に最適なものを選定する
+- **CQRS/イベントソーシングの適用判断**: 読み書きの特性が大きく異なる場合に検討する。過剰適用は複雑さを増すだけなので慎重に判断せよ
+- **API 設計方針**: REST/GraphQL/gRPC の選択基準を明確にする
+
+## フロントエンドアーキテクチャ設計
+
+ユーザー体験とチームのスキルセットを考慮して設計する。フレームワーク選定はプロジェクト全体に影響するため、ADR で判断根拠を残せ。
+
+- **フレームワーク選定**: プロジェクト要件に合ったフレームワークを選択する
+- **状態管理パターン**: アプリケーションの状態の複雑さに応じて適切なパターンを選定する
+- **コンポーネント設計方針**: 再利用性と保守性を両立する設計指針を定める
+
+## インフラストラクチャアーキテクチャ設計
+
+非機能要件（可用性・スケーラビリティ）を実現するインフラ構成を設計する。運用コストとの兼ね合いも考慮せよ。
+
+- **クラウド/オンプレミス選定**: コスト・セキュリティ・運用負荷を総合的に判断する
+- **コンテナ化戦略**: コンテナ化の適用範囲とオーケストレーション方式を決定する
+- **CI/CD パイプライン設計**: ビルド・テスト・デプロイの自動化方針を定める
+
+## 作成の進め方
+
+1. 入力ドキュメント（要件定義、ユースケース、ユーザーストーリー）を確認する。なければ基本情報をヒアリングする
+2. @docs/reference/アーキテクチャ設計ガイド.md を読み込む
+3. バックエンド→フロントエンド→インフラの順に設計する。各アーキテクチャの選定理由を明記せよ
+4. 重要な設計判断は ADR（Architecture Decision Record）で記録する
+
+## 途中から再開する場合
+
+既存の `docs/design/architecture_*.md` がある場合は、まずその内容を確認する。不足している領域や更新が必要な部分のみを修正する。
+
+**Example:**
+
+```
+ユーザー: 「バックエンドはクリーンアーキテクチャで決めた。フロントエンドを設計したい」
+回答: 既存の architecture_backend.md を確認し、
+      バックエンドの API 設計方針を踏まえてフロントエンドアーキテクチャ設計に進む。
+      フレームワーク選定→状態管理→コンポーネント設計の順で作成する。
+```
+
+## 注意事項
+
+- 要件定義とユースケースが完了していることが前提。未完了でもプロジェクト情報から進めて構わない
+- アーキテクチャ決定は必ず ADR で記録する。「なぜその選択をしたか」が後で最も重要になる
+- 業務の複雑さとチームのスキルセットを考慮して選択する。技術的に「正しい」選択よりチームが運用できる選択を優先せよ
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-requirements` — 前段の要件定義
+- `analyzing-domain-model` — 後続のドメインモデル設計
+- `analyzing-data-model` — 後続のデータモデル設計
+- `analyzing-tech-stack` — 後続の技術スタック選定