@k2works/claude-code-booster 4.6.0 → 4.7.0

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/creating-iteration-report/SKILL.md

@@ -1,210 +1,210 @@
----
-name: creating-iteration-report
-description: イテレーション完了報告書を作成。iteration_plan・release_plan・git log・テスト結果からデータを収集し、テンプレートに基づいて報告書を生成する。「イテレーション完了報告書を作りたい」「IT3 の報告書を作成して」「イテレーションレポートを書いて」「完了報告書を作成」「イテレーションの結果をまとめたい」といった場面で発動する。planning-releases --report が呼ばれた場合もこのスキルの手順に従う。各イテレーションの成果を定量的に記録し、ベロシティの実績データを蓄積することで計画の精度を高める。
----
-
-# イテレーション完了報告書の作成
-
-イテレーション計画・リリース計画・git log・テスト結果からデータを収集し、公式な完了報告書を作成する。
-
-報告書の価値は「何をどれだけ達成したか」を定量的に記録すること。ベロシティ実績の蓄積はリリース計画の精度を高め、品質メトリクスの推移はプロジェクトの健全性を可視化する。
-
-## テンプレート
-
-@docs/template/イテレーション完了報告書.md
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | 最新のイテレーション番号を推定して報告書を作成 |
-| `<番号>` | 指定番号のイテレーション完了報告書を作成 |
-
-## 前提条件
-
-- `docs/development/iteration_plan-{N}.md` が存在し、タスクの完了状況が更新済みであること
-- `docs/development/release_plan.md` が存在すること
-- 対象イテレーションの開発が完了していること（テスト全パス）
-
-## 作成フロー
-
-```mermaid
-graph TD
-    A[イテレーション番号の特定] --> B[データ収集]
-    B --> C[報告書作成]
-    C --> D[release_plan.md 更新]
-    D --> E[インデックス更新]
-```
-
-### Step 1: イテレーション番号の特定
-
-既存の `iteration_report-*.md` から最新の番号を推定する。指定がある場合はそれを使用する。
-
-### Step 2: データ収集
-
-4 つのデータソースから報告書に必要な情報を収集する。
-
-#### 2.1 イテレーション計画（`docs/development/iteration_plan-{N}.md`）
-
-- イテレーション番号、ゴール
-- 計画期間（計画日付）
-- ストーリー一覧と予定 SP
-- タスクの完了状況
-- 受入条件の達成状況
-
-#### 2.2 リリース計画（`docs/development/release_plan.md`）
-
-- 全体の SP（バーンダウン用）
-- イテレーション別の計画 SP・実績 SP（前イテレーションまで）
-- フェーズ別の進捗状況
-- 計画スケジュール
-
-#### 2.3 テスト結果
-
-テストを実行して最新の結果を取得する。
-
-```bash
-# Backend テスト
-cd apps/backend && npm test 2>&1 | tail -20
-
-# Frontend テスト
-cd apps/frontend && npm test 2>&1 | tail -20
-
-# E2E テスト
-npx playwright test 2>&1 | tail -20
-```
-
-取得する情報:
-
-- テストファイル数、テスト数（Backend / Frontend）
-- E2E シナリオ数
-- カバレッジ（利用可能な場合）
-
-#### 2.4 前イテレーションの報告書（`docs/development/iteration_report-{N-1}.md`）
-
-- 前イテレーションのテスト数（増分計算用）
-- テスト累計推移（累計テーブル用）
-
-### Step 3: 報告書の作成
-
-以下のセクション構成で報告書を作成する。
-
-**出力ファイル**: `docs/development/iteration_report-{N}.md`
-
-#### セクション構成
-
-##### 1. プロジェクト概要
-
-| 項目 | データソース |
-|------|------------|
-| イテレーション番号 | iteration_plan |
-| 計画期間 | release_plan のガントチャート |
-| 実績期間 | git log の実際のコミット日付 |
-| ゴール | iteration_plan |
-| 要員 | 計画日数 5 日、実績日数は実際の作業日数 |
-
-##### 2. 指標
-
-**ベロシティテーブル**:
-
-| 項目 | 値 |
-|------|-----|
-| 計画 SP | iteration_plan から |
-| 実績 SP | 完了ストーリーの SP 合計 |
-| 達成率 | 実績 / 計画 × 100 |
-
-**バーンダウンチャート** (Mermaid `xychart-beta`):
-
-- x 軸: "開始" + 全イテレーション名
-- 計画線: release_plan の計画残 SP
-- 実績線: 当該イテレーションまでの実績残 SP
-
-**ベロシティチャート** (Mermaid `xychart-beta`):
-
-- x 軸: 当該イテレーションまでの IT 名
-- 棒グラフ: 各イテレーションの実績 SP
-- 平均線: 実績 SP の平均値
-
-##### 3. テスト結果
-
-| メトリクス | Backend | Frontend |
-|-----------|---------|----------|
-| テストファイル | X/X 通過 | X/X 通過 |
-| テスト数 | X/X 通過 | X/X 通過 |
-| カバレッジ | X% | X% |
-| E2E テスト | - | X シナリオ全通過 |
-
-**テスト増分テーブル**: 前イテレーションとの比較
-
-**テスト累計推移テーブル**: IT1 からの累計
-
-##### 4. SonarQube Quality Gate（利用可能な場合）
-
-| プロジェクト | カバレッジ | 重複率 | Violations | 結果 |
-|------------|----------|--------|-----------|------|
-
-##### 5. 実施内容と評価
-
-- ストーリー別の完了状況テーブル
-- 各ストーリーの受入条件達成状況（チェックリスト）
-- 実装内容の要約（レイヤー別: ドメイン→アプリケーション→インフラ→プレゼンテーション→フロントエンド）
-
-##### 6. 追加タスク（SP 外）
-
-技術的負債解消、XP レビュー対応、デモ環境同期など。
-
-##### 7. E2E テスト結果
-
-- 新規追加分のシナリオ一覧と結果
-- リグレッションテスト結果
-
-##### 8. フェーズ・累計進捗
-
-- 現在のフェーズの進捗テーブル
-- 全フェーズの累計進捗テーブル
-
-##### 9. ふりかえりへのリンク
-
-```markdown
-詳細は [イテレーション N ふりかえり](./retrospective-N.md) を参照。
-```
-
-##### 10. 更新履歴
-
-### Step 4: release_plan.md の更新
-
-報告書作成後、release_plan.md の進捗状況テーブルを更新する。
-
-- 該当イテレーションの実績 SP・達成率・状態を更新
-- バーンダウンチャートの実績線を更新
-
-### Step 5: インデックス更新
-
-1. `docs/development/index.md` — イテレーション計画テーブルの状態を更新
-2. `docs/index.md` — 開発セクションにエントリ追加（未登録の場合）
-3. `mkdocs.yml` — nav にエントリ追加（未登録の場合）
-
-## 途中から再開
-
-**Example:**
-
-```
-ユーザー: 「IT4 の完了報告書を作って」
-回答: docs/development/iteration_plan-4.md の完了状況を確認し、
-      テストを実行して結果を取得し、
-      前イテレーション（iteration_report-3.md）からテスト推移データを収集して作成する。
-```
-
-## 注意事項
-
-- テスト数・カバレッジは実測値を使用し、推測値を使わない
-- Mermaid チャートの数値は release_plan.md と整合させる
-- 受入条件の達成状況は iteration_plan のチェックリストと一致させる
-- 前イテレーションの報告書がない場合（IT1）は、テスト増分の基準を 0 とする
-
-## 関連スキル
-
-- `planning-releases` — リリース計画・イテレーション計画・ふりかえり
-- `creating-release-report` — リリース完了報告書（複数イテレーションを集約）
-- `tracking-progress` — 進捗分析・レポート生成
-- `operating-docs` — ドキュメントインデックス更新
+---
+name: creating-iteration-report
+description: イテレーション完了報告書を作成。iteration_plan・release_plan・git log・テスト結果からデータを収集し、テンプレートに基づいて報告書を生成する。「イテレーション完了報告書を作りたい」「IT3 の報告書を作成して」「イテレーションレポートを書いて」「完了報告書を作成」「イテレーションの結果をまとめたい」といった場面で発動する。planning-releases --report が呼ばれた場合もこのスキルの手順に従う。各イテレーションの成果を定量的に記録し、ベロシティの実績データを蓄積することで計画の精度を高める。
+---
+
+# イテレーション完了報告書の作成
+
+イテレーション計画・リリース計画・git log・テスト結果からデータを収集し、公式な完了報告書を作成する。
+
+報告書の価値は「何をどれだけ達成したか」を定量的に記録すること。ベロシティ実績の蓄積はリリース計画の精度を高め、品質メトリクスの推移はプロジェクトの健全性を可視化する。
+
+## テンプレート
+
+@docs/template/イテレーション完了報告書.md
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | 最新のイテレーション番号を推定して報告書を作成 |
+| `<番号>` | 指定番号のイテレーション完了報告書を作成 |
+
+## 前提条件
+
+- `docs/development/iteration_plan-{N}.md` が存在し、タスクの完了状況が更新済みであること
+- `docs/development/release_plan.md` が存在すること
+- 対象イテレーションの開発が完了していること（テスト全パス）
+
+## 作成フロー
+
+```mermaid
+graph TD
+    A[イテレーション番号の特定] --> B[データ収集]
+    B --> C[報告書作成]
+    C --> D[release_plan.md 更新]
+    D --> E[インデックス更新]
+```
+
+### Step 1: イテレーション番号の特定
+
+既存の `iteration_report-*.md` から最新の番号を推定する。指定がある場合はそれを使用する。
+
+### Step 2: データ収集
+
+4 つのデータソースから報告書に必要な情報を収集する。
+
+#### 2.1 イテレーション計画（`docs/development/iteration_plan-{N}.md`）
+
+- イテレーション番号、ゴール
+- 計画期間（計画日付）
+- ストーリー一覧と予定 SP
+- タスクの完了状況
+- 受入条件の達成状況
+
+#### 2.2 リリース計画（`docs/development/release_plan.md`）
+
+- 全体の SP（バーンダウン用）
+- イテレーション別の計画 SP・実績 SP（前イテレーションまで）
+- フェーズ別の進捗状況
+- 計画スケジュール
+
+#### 2.3 テスト結果
+
+テストを実行して最新の結果を取得する。
+
+```bash
+# Backend テスト
+cd apps/backend && npm test 2>&1 | tail -20
+
+# Frontend テスト
+cd apps/frontend && npm test 2>&1 | tail -20
+
+# E2E テスト
+npx playwright test 2>&1 | tail -20
+```
+
+取得する情報:
+
+- テストファイル数、テスト数（Backend / Frontend）
+- E2E シナリオ数
+- カバレッジ（利用可能な場合）
+
+#### 2.4 前イテレーションの報告書（`docs/development/iteration_report-{N-1}.md`）
+
+- 前イテレーションのテスト数（増分計算用）
+- テスト累計推移（累計テーブル用）
+
+### Step 3: 報告書の作成
+
+以下のセクション構成で報告書を作成する。
+
+**出力ファイル**: `docs/development/iteration_report-{N}.md`
+
+#### セクション構成
+
+##### 1. プロジェクト概要
+
+| 項目 | データソース |
+|------|------------|
+| イテレーション番号 | iteration_plan |
+| 計画期間 | release_plan のガントチャート |
+| 実績期間 | git log の実際のコミット日付 |
+| ゴール | iteration_plan |
+| 要員 | 計画日数 5 日、実績日数は実際の作業日数 |
+
+##### 2. 指標
+
+**ベロシティテーブル**:
+
+| 項目 | 値 |
+|------|-----|
+| 計画 SP | iteration_plan から |
+| 実績 SP | 完了ストーリーの SP 合計 |
+| 達成率 | 実績 / 計画 × 100 |
+
+**バーンダウンチャート** (Mermaid `xychart-beta`):
+
+- x 軸: "開始" + 全イテレーション名
+- 計画線: release_plan の計画残 SP
+- 実績線: 当該イテレーションまでの実績残 SP
+
+**ベロシティチャート** (Mermaid `xychart-beta`):
+
+- x 軸: 当該イテレーションまでの IT 名
+- 棒グラフ: 各イテレーションの実績 SP
+- 平均線: 実績 SP の平均値
+
+##### 3. テスト結果
+
+| メトリクス | Backend | Frontend |
+|-----------|---------|----------|
+| テストファイル | X/X 通過 | X/X 通過 |
+| テスト数 | X/X 通過 | X/X 通過 |
+| カバレッジ | X% | X% |
+| E2E テスト | - | X シナリオ全通過 |
+
+**テスト増分テーブル**: 前イテレーションとの比較
+
+**テスト累計推移テーブル**: IT1 からの累計
+
+##### 4. SonarQube Quality Gate（利用可能な場合）
+
+| プロジェクト | カバレッジ | 重複率 | Violations | 結果 |
+|------------|----------|--------|-----------|------|
+
+##### 5. 実施内容と評価
+
+- ストーリー別の完了状況テーブル
+- 各ストーリーの受入条件達成状況（チェックリスト）
+- 実装内容の要約（レイヤー別: ドメイン→アプリケーション→インフラ→プレゼンテーション→フロントエンド）
+
+##### 6. 追加タスク（SP 外）
+
+技術的負債解消、XP レビュー対応、デモ環境同期など。
+
+##### 7. E2E テスト結果
+
+- 新規追加分のシナリオ一覧と結果
+- リグレッションテスト結果
+
+##### 8. フェーズ・累計進捗
+
+- 現在のフェーズの進捗テーブル
+- 全フェーズの累計進捗テーブル
+
+##### 9. ふりかえりへのリンク
+
+```markdown
+詳細は [イテレーション N ふりかえり](./retrospective-N.md) を参照。
+```
+
+##### 10. 更新履歴
+
+### Step 4: release_plan.md の更新
+
+報告書作成後、release_plan.md の進捗状況テーブルを更新する。
+
+- 該当イテレーションの実績 SP・達成率・状態を更新
+- バーンダウンチャートの実績線を更新
+
+### Step 5: インデックス更新
+
+1. `docs/development/index.md` — イテレーション計画テーブルの状態を更新
+2. `docs/index.md` — 開発セクションにエントリ追加（未登録の場合）
+3. `mkdocs.yml` — nav にエントリ追加（未登録の場合）
+
+## 途中から再開
+
+**Example:**
+
+```
+ユーザー: 「IT4 の完了報告書を作って」
+回答: docs/development/iteration_plan-4.md の完了状況を確認し、
+      テストを実行して結果を取得し、
+      前イテレーション（iteration_report-3.md）からテスト推移データを収集して作成する。
+```
+
+## 注意事項
+
+- テスト数・カバレッジは実測値を使用し、推測値を使わない
+- Mermaid チャートの数値は release_plan.md と整合させる
+- 受入条件の達成状況は iteration_plan のチェックリストと一致させる
+- 前イテレーションの報告書がない場合（IT1）は、テスト増分の基準を 0 とする
+
+## 関連スキル
+
+- `planning-releases` — リリース計画・イテレーション計画・ふりかえり
+- `creating-release-report` — リリース完了報告書（複数イテレーションを集約）
+- `tracking-progress` — 進捗分析・レポート生成
+- `operating-docs` — ドキュメントインデックス更新