@k2works/claude-code-booster 1.10.0 → 1.11.0

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

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

@@ -1,154 +1,154 @@
----
-name: developing-release
-description: アプリケーションのリリースワークフロー。品質ゲート、バージョンバンプ、CHANGELOG 生成、git commit + tag を一貫実行。リリース作業やバージョン管理時に使用。
----
-
-# リリースワークフローガイド
-
-品質ゲート → バージョンバンプ → CHANGELOG 生成 → git commit + tag を一貫して実行するリリースワークフローを支援します。
-
-## Instructions
-
-### 1. 参照ドキュメント
-
-- @docs/reference/リリースガイド.md - リリースワークフロー全体
-
-### 2. リリースフロー
-
-リリースは以下の順序で実行します:
-
-1. **ドライラン**: CHANGELOG プレビューとバージョン計算を確認
-2. **リリース種別選択**: patch / minor / major を選択
-3. **品質ゲート（preflight）**: 全チェックを通過
-4. **リリース実行**: バージョンバンプ → CHANGELOG 生成 → commit + tag
-5. **リモートプッシュ**: コミットとタグをプッシュ
-6. **デプロイ**: 必要に応じて本番デプロイ
-
-### 3. オプション
-
-- なし : ドライランを実行（デフォルト）
-- `--dry-run` : CHANGELOG プレビュー + バージョン計算
-- `--patch` : パッチリリース（バグ修正）
-- `--minor` : マイナーリリース（新機能追加、後方互換あり）
-- `--major` : メジャーリリース（破壊的変更）
-- `--preflight` : 品質ゲートのみ実行
-- `--deploy` : リリース + デプロイ（`--patch` / `--minor` / `--major` と併用）
-
-### 4. 基本例
-
-```bash
-# ドライラン（プレビュー）
-npm run release:dry-run
-
-# パッチリリース
-npm run release:patch
-
-# マイナーリリース
-npm run release:minor
-
-# メジャーリリース
-npm run release:major
-
-# 品質ゲートのみ実行
-npm run release:preflight
-
-# パッチリリース + デプロイ
-npm run release:deploy:patch
-```
-
-### 5. 品質ゲート（preflight）
-
-リリース前に以下のチェックを直列実行します。全チェック通過が必須です:
-
-| チェック | コマンド | 内容 |
-| :--- | :--- | :--- |
-| working tree クリーン | `release:preflight:clean` | 未コミット変更がないこと |
-| 静的解析 | `release:preflight:lint` | lint エラーがないこと |
-| ユニットテスト | `release:preflight:test` | 全テストパス |
-| ビルド確認 | `release:preflight:build` | ビルド成功 |
-| E2E テスト | `release:preflight:e2e` | E2E テスト全パス |
-
-### 6. バージョニング規則
-
-[Semantic Versioning](https://semver.org/) に従います:
-
-| 種類 | 変更例 | バージョン変化 |
-| :--- | :--- | :--- |
-| `patch` | バグ修正、軽微な改善 | `0.1.0` → `0.1.1` |
-| `minor` | 新機能追加（後方互換あり） | `0.1.0` → `0.2.0` |
-| `major` | 破壊的変更 | `0.1.0` → `1.0.0` |
-
-モノレポ構成の場合、全パッケージのバージョンを同期管理します。
-
-### 7. CHANGELOG 生成ルール
-
-[Conventional Commits](https://www.conventionalcommits.org/) に基づいて自動生成:
-
-| prefix | カテゴリ |
-| :--- | :--- |
-| `feat` | Features |
-| `fix` | Bug Fixes |
-| `docs` | Documentation |
-| `refactor` | Refactoring |
-| `test` | Tests |
-| `chore` | Chores |
-| `perf` | Performance |
-| `ci` | CI |
-| `style` | Styles |
-| `build` | Build |
-
-- 直近の git tag から HEAD までのコミットを対象
-- タグが存在しない場合は全コミット履歴を対象
-- `CHANGELOG.md` の先頭に新しいエントリを追加
-
-### 8. リリース実行ステップ
-
-| ステップ | 内容 |
-| :--- | :--- |
-| [1/4] バージョン更新 | 対象パッケージのバージョンをセマンティックバージョニングに従って更新 |
-| [2/4] CHANGELOG 生成 | 直近タグから HEAD までのコミットを分類し CHANGELOG.md を生成 |
-| [3/4] git commit + tag | 変更ファイルをステージング → `release: vX.X.X` でコミット → `vX.X.X` タグ作成 |
-| [4/4] サマリー表示 | バージョン変化、タグ名、次のステップを表示 |
-
-### 9. トラブルシューティング
-
-- **working tree がクリーンでない**: 変更をコミットまたは `git stash` してからリリース再実行
-- **テスト失敗**: テストを修正してからリリースを再実行
-- **リリースを元に戻したい**: リモートプッシュ前なら `git tag -d vX.X.X && git reset --hard HEAD~1`
-
-### 10. コンテキスト管理
-
-長時間のリリースセッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
-
-**`/compact` を実施するタイミング**:
-
-- 品質ゲート（preflight）の実行が完了したとき
-- バージョンバンプと CHANGELOG 生成が完了したとき
-- リリースコミット・タグ作成が完了したとき
-- デプロイ完了後
-
-**運用ルール**:
-
-1. `/compact` 実施前に、現在のリリース状態と次のステップをメモとして出力する
-2. `/compact` 実施後、次のステップの作業を継続する
-
-### 11. 注意事項
-
-- **前提条件**: ビルドツール・パッケージマネージャーがセットアップ済み、依存関係インストール済み
-- **制限事項**: working tree がクリーンでないとリリース不可
-- **推奨事項**: リリース前に必ずドライランで内容を確認
-
-### 12. ベストプラクティス
-
-1. **ドライランファースト**: 必ずドライランで CHANGELOG プレビューを確認してからリリース
-2. **品質ゲート厳守**: preflight の全チェックを通過させてからリリース実行
-3. **セマンティックバージョニング**: 変更内容に応じた適切なバージョン種別を選択
-4. **Conventional Commits**: コミットメッセージを規約に従って記述し CHANGELOG の品質を確保
-5. **段階的デプロイ**: リリースとデプロイを分離し、必要に応じてデプロイを実行
-
-### 関連スキル
-
-- `git-commit` : Conventional Commits 準拠のコミット作成
-- `managing-operations` : デプロイ・運用管理
-- `planning-releases` : リリース・イテレーション計画
-- `orchestrating-development` : 開発フェーズ全体のワークフロー（リリースはこのフェーズの最終工程）
+---
+name: developing-release
+description: アプリケーションのリリースワークフロー。品質ゲート、バージョンバンプ、CHANGELOG 生成、git commit + tag を一貫実行。リリース作業やバージョン管理時に使用。
+---
+
+# リリースワークフローガイド
+
+品質ゲート → バージョンバンプ → CHANGELOG 生成 → git commit + tag を一貫して実行するリリースワークフローを支援します。
+
+## Instructions
+
+### 1. 参照ドキュメント
+
+- @docs/reference/リリースガイド.md - リリースワークフロー全体
+
+### 2. リリースフロー
+
+リリースは以下の順序で実行します:
+
+1. **ドライラン**: CHANGELOG プレビューとバージョン計算を確認
+2. **リリース種別選択**: patch / minor / major を選択
+3. **品質ゲート（preflight）**: 全チェックを通過
+4. **リリース実行**: バージョンバンプ → CHANGELOG 生成 → commit + tag
+5. **リモートプッシュ**: コミットとタグをプッシュ
+6. **デプロイ**: 必要に応じて本番デプロイ
+
+### 3. オプション
+
+- なし : ドライランを実行（デフォルト）
+- `--dry-run` : CHANGELOG プレビュー + バージョン計算
+- `--patch` : パッチリリース（バグ修正）
+- `--minor` : マイナーリリース（新機能追加、後方互換あり）
+- `--major` : メジャーリリース（破壊的変更）
+- `--preflight` : 品質ゲートのみ実行
+- `--deploy` : リリース + デプロイ（`--patch` / `--minor` / `--major` と併用）
+
+### 4. 基本例
+
+```bash
+# ドライラン（プレビュー）
+npm run release:dry-run
+
+# パッチリリース
+npm run release:patch
+
+# マイナーリリース
+npm run release:minor
+
+# メジャーリリース
+npm run release:major
+
+# 品質ゲートのみ実行
+npm run release:preflight
+
+# パッチリリース + デプロイ
+npm run release:deploy:patch
+```
+
+### 5. 品質ゲート（preflight）
+
+リリース前に以下のチェックを直列実行します。全チェック通過が必須です:
+
+| チェック | コマンド | 内容 |
+| :--- | :--- | :--- |
+| working tree クリーン | `release:preflight:clean` | 未コミット変更がないこと |
+| 静的解析 | `release:preflight:lint` | lint エラーがないこと |
+| ユニットテスト | `release:preflight:test` | 全テストパス |
+| ビルド確認 | `release:preflight:build` | ビルド成功 |
+| E2E テスト | `release:preflight:e2e` | E2E テスト全パス |
+
+### 6. バージョニング規則
+
+[Semantic Versioning](https://semver.org/) に従います:
+
+| 種類 | 変更例 | バージョン変化 |
+| :--- | :--- | :--- |
+| `patch` | バグ修正、軽微な改善 | `0.1.0` → `0.1.1` |
+| `minor` | 新機能追加（後方互換あり） | `0.1.0` → `0.2.0` |
+| `major` | 破壊的変更 | `0.1.0` → `1.0.0` |
+
+モノレポ構成の場合、全パッケージのバージョンを同期管理します。
+
+### 7. CHANGELOG 生成ルール
+
+[Conventional Commits](https://www.conventionalcommits.org/) に基づいて自動生成:
+
+| prefix | カテゴリ |
+| :--- | :--- |
+| `feat` | Features |
+| `fix` | Bug Fixes |
+| `docs` | Documentation |
+| `refactor` | Refactoring |
+| `test` | Tests |
+| `chore` | Chores |
+| `perf` | Performance |
+| `ci` | CI |
+| `style` | Styles |
+| `build` | Build |
+
+- 直近の git tag から HEAD までのコミットを対象
+- タグが存在しない場合は全コミット履歴を対象
+- `CHANGELOG.md` の先頭に新しいエントリを追加
+
+### 8. リリース実行ステップ
+
+| ステップ | 内容 |
+| :--- | :--- |
+| [1/4] バージョン更新 | 対象パッケージのバージョンをセマンティックバージョニングに従って更新 |
+| [2/4] CHANGELOG 生成 | 直近タグから HEAD までのコミットを分類し CHANGELOG.md を生成 |
+| [3/4] git commit + tag | 変更ファイルをステージング → `release: vX.X.X` でコミット → `vX.X.X` タグ作成 |
+| [4/4] サマリー表示 | バージョン変化、タグ名、次のステップを表示 |
+
+### 9. トラブルシューティング
+
+- **working tree がクリーンでない**: 変更をコミットまたは `git stash` してからリリース再実行
+- **テスト失敗**: テストを修正してからリリースを再実行
+- **リリースを元に戻したい**: リモートプッシュ前なら `git tag -d vX.X.X && git reset --hard HEAD~1`
+
+### 10. コンテキスト管理
+
+長時間のリリースセッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- 品質ゲート（preflight）の実行が完了したとき
+- バージョンバンプと CHANGELOG 生成が完了したとき
+- リリースコミット・タグ作成が完了したとき
+- デプロイ完了後
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在のリリース状態と次のステップをメモとして出力する
+2. `/compact` 実施後、次のステップの作業を継続する
+
+### 11. 注意事項
+
+- **前提条件**: ビルドツール・パッケージマネージャーがセットアップ済み、依存関係インストール済み
+- **制限事項**: working tree がクリーンでないとリリース不可
+- **推奨事項**: リリース前に必ずドライランで内容を確認
+
+### 12. ベストプラクティス
+
+1. **ドライランファースト**: 必ずドライランで CHANGELOG プレビューを確認してからリリース
+2. **品質ゲート厳守**: preflight の全チェックを通過させてからリリース実行
+3. **セマンティックバージョニング**: 変更内容に応じた適切なバージョン種別を選択
+4. **Conventional Commits**: コミットメッセージを規約に従って記述し CHANGELOG の品質を確保
+5. **段階的デプロイ**: リリースとデプロイを分離し、必要に応じてデプロイを実行
+
+### 関連スキル
+
+- `git-commit` : Conventional Commits 準拠のコミット作成
+- `managing-operations` : デプロイ・運用管理
+- `planning-releases` : リリース・イテレーション計画
+- `orchestrating-development` : 開発フェーズ全体のワークフロー（リリースはこのフェーズの最終工程）