@k2works/claude-code-booster 1.4.1 → 1.6.0

package/lib/assets/.claude/README.md

@@ -50,6 +50,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 | :--- | :--- |
 | `developing-backend` | バックエンド開発の TDD ワークフロー。インサイドアウトアプローチ。 |
 | `developing-frontend` | フロントエンド開発の TDD ワークフロー。アウトサイドインアプローチ。 |
+| `developing-release` | リリースワークフロー。品質ゲート、バージョンバンプ、CHANGELOG 生成、git commit + tag。 |
 
 #### 計画・進捗系
 
@@ -130,6 +131,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 │   ├── analyzing-operation/SKILL.md
 │   ├── developing-backend/SKILL.md
 │   ├── developing-frontend/SKILL.md
+│   ├── developing-release/SKILL.md
 │   ├── killing-processes/SKILL.md
 │   ├── managing-operations/
 │   │   ├── SKILL.md

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

@@ -1,4 +1,7 @@
 {
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
+  },
   "permissions": {
     "defaultMode": "plan",
     "allow": [],

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

@@ -65,7 +65,24 @@ cd apps/backend && ./gradlew bootRun
 - [ ] 単一の論理的作業単位を表現
 - [ ] コミットメッセージが変更内容を明確に説明
 
-### 7. 注意事項
+### 7. コンテキスト管理
+
+長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
+- ユーザーストーリー 1 件の実装が完了したとき
+- コミット完了後、次のタスクに着手する前
+- テストスイートの実行と結果確認が完了したとき
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
+2. `/compact` 実施後、次のタスクの作業を継続する
+3. 大規模なユーザーストーリーでは、サブタスクごとに `/compact` を検討する
+
+### 8. 注意事項
 
 - **前提条件**: Java/Gradle のテスト環境が設定済みであること
 - **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）

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

@@ -54,7 +54,24 @@ cd apps/frontend && npm run test:e2e
 - [ ] 単一の論理的作業単位を表現
 - [ ] コミットメッセージが変更内容を明確に説明
 
-### 6. 注意事項
+### 6. コンテキスト管理
+
+長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
+- コンポーネント 1 件の実装が完了したとき
+- コミット完了後、次のタスクに着手する前
+- テストスイートの実行と結果確認が完了したとき
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
+2. `/compact` 実施後、次のタスクの作業を継続する
+3. 大規模なユーザーストーリーでは、サブタスクごとに `/compact` を検討する
+
+### 7. 注意事項
 
 - **前提条件**: Node.js/npm のテスト環境が設定済みであること
 - **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）

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

@@ -0,0 +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` : 開発フェーズ全体のワークフロー（リリースはこのフェーズの最終工程）

package/lib/assets/.claude/skills/managing-docs/SKILL.md

@@ -66,7 +66,7 @@ description: 設計ドキュメントの一覧表示、進捗確認、内容参
 
 ### 4. ドキュメント更新機能
 
-`--update` オプションを使用すると、現在のドキュメント構成に合わせて `docs/index.md` と `mkdocs.yml` を自動更新できます。
+`--update` オプションを使用すると、現在のドキュメント構成に合わせて `docs/index.md` と `mkdocs.yml` と 各ディレクトリの `index.md` を自動更新できます。
 
 **docs/index.md の更新内容**:
 
@@ -80,6 +80,11 @@ description: 設計ドキュメントの一覧表示、進捗確認、内容参
 - 要件定義、設計、開発、運用などのカテゴリで階層化
 - 新しいドキュメントを自動的にナビゲーションに追加
 
+**各ディレクトリの index.md の更新内容**:
+
+- ドキュメント一覧をカテゴリ別に整理
+- 各ドキュメントへのリンクと説明を生成
+
 ### 5. Lint 機能
 
 `--lint` オプションを使用すると、Markdown ドキュメントのフォーマットをチェックし、違反を自動修正できます。

package/lib/assets/.claude/skills/orchestrating-analysis/SKILL.md

@@ -82,13 +82,30 @@ cat README.md
 # 「プロジェクトの現状を踏まえた分析フェーズの進め方を提案」
 ```
 
-### 3. 注意事項
+### 3. コンテキスト管理
+
+長時間の分析セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- 分析工程 1 件（例: 要件定義、ユースケース作成）が完了したとき
+- 設計ドキュメント 1 件の作成・更新が完了したとき
+- 複数の analyzing-* スキルを連続実行する間
+- コミット完了後、次の分析工程に着手する前
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する
+2. `/compact` 実施後、次の工程の作業を継続する
+3. 大規模な分析工程（例: アーキテクチャ設計）では、サブ工程ごとに `/compact` を検討する
+
+### 4. 注意事項
 
 - **前提条件**: プロジェクトの基本的な背景情報の把握が必要
 - **制限事項**: 分析結果は開発フェーズで継続的に見直し・改善が必要
 - **推奨事項**: 各工程の成果物を文書化し、チーム内で共有することを推奨
 
-### 4. ベストプラクティス
+### 5. ベストプラクティス
 
 1. **段階的分析**: 要件定義から始めて段階的に詳細化する
 2. **チーム連携**: 分析結果をチーム全体で共有し、合意形成を行う

package/lib/assets/.claude/skills/orchestrating-development/SKILL.md

@@ -203,13 +203,31 @@ Claude の活動:
 - [ ] ESLint エラーがない
 - [ ] 既存テストが壊れていない
 
-### 9. 注意事項
+### 9. コンテキスト管理
+
+長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- ユーザーストーリー 1 件の実装が完了したとき
+- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
+- Codex への実装指示と受入フェーズの間
+- コミット完了後、次のタスクに着手する前
+- テストスイートの実行と結果確認が完了したとき
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
+2. `/compact` 実施後、次のタスクの作業を継続する
+3. 大規模なユーザーストーリーでは、サブタスクごとに `/compact` を検討する
+
+### 10. 注意事項
 
 - **前提条件**: プロジェクトのテスト環境が設定済みであること
 - **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
 - **推奨事項**: コミット前に必ず品質チェックリストを実行
 
-### 10. ベストプラクティス
+### 11. ベストプラクティス
 
 1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
 2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
@@ -220,5 +238,6 @@ Claude の活動:
 
 - Skill: `developing-backend` : バックエンド開発ガイド
 - Skill: `developing-frontend` : フロントエンド開発ガイド
+- Skill: `developing-release` : リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）
 - @docs/reference/CodexCLIMCPアプリケーション開発フロー.md : アプリケーション開発フロー
 - @docs/reference/CodexCLIMCPサーバー設定手順.md : Codex MCP サーバー設定手順

package/lib/assets/.claude/skills/orchestrating-project/SKILL.md

@@ -152,13 +152,31 @@ GitHub Project
 └─ ベロシティ（前回）: 10SP
 ```
 
-### 9. 注意事項
+### 9. コンテキスト管理
+
+長時間のプロジェクト管理セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+
+**`/compact` を実施するタイミング**:
+
+- リリース計画・イテレーション計画の作成が完了したとき
+- GitHub Project との同期処理が完了したとき
+- 進捗追跡レポートの生成が完了したとき
+- ふりかえり・完了報告書の作成が完了したとき
+- コミット完了後、次の管理タスクに着手する前
+
+**運用ルール**:
+
+1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
+2. `/compact` 実施後、次のタスクの作業を継続する
+3. イテレーションライフサイクル管理では、各フェーズ（開始・実行中・終了）の間に `/compact` を検討する
+
+### 10. 注意事項
 
 - **前提条件**: 要件定義書またはユーザーストーリーが存在すること。`gh` CLI がインストールされ認証済みであること
 - **制限事項**: 初回ベロシティは推測値のため、3 イテレーション後に再調整推奨
 - **推奨事項**: リリース計画を Single Source of Truth として管理し、GitHub への同期を定期的に実施
 
-### 10. ベストプラクティス
+### 11. ベストプラクティス
 
 1. **Single Source of Truth**: `docs/development/release_plan.md` を計画の正とし、GitHub は `--sync` で自動反映
 2. **定期的な同期**: イテレーション開始・終了時に GitHub との同期を実施

package/lib/assets/CLAUDE.md

@@ -24,6 +24,7 @@
 | :--- | :--- |
 | `orchestrating-analysis` | 分析フェーズの全体ワークフロー |
 | `orchestrating-development` | 開発フェーズの TDD ワークフロー・Codex 分業 |
+| `orchestrating-project` | 計画・進捗管理フェーズの全体ワークフロー |
 
 ### 分析
 
@@ -47,6 +48,7 @@
 | :--- | :--- |
 | `developing-backend` | バックエンド TDD（インサイドアウト） |
 | `developing-frontend` | フロントエンド TDD（アウトサイドイン） |
+| `developing-release` | リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG） |
 
 ### 計画・進捗
 

package/lib/assets/README.md

@@ -57,6 +57,7 @@ claude mcp add -s project codex -- npx @openai/codex mcp-server
 | | `analyzing-operation` | 運用要件定義 |
 | **開発** | `developing-backend` | バックエンド TDD（インサイドアウト） |
 | | `developing-frontend` | フロントエンド TDD（アウトサイドイン） |
+| | `developing-release` | リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG） |
 | **計画・進捗** | `planning-releases` | リリース・イテレーション計画 |
 | | `syncing-github-project` | GitHub Project 同期 |
 | | `tracking-progress` | 進捗分析・レポート生成 |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "1.4.1",
+  "version": "1.6.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {