@k2works/claude-code-booster 4.9.0 → 4.11.0

package/lib/assets/.claude/skills/creating-journal/SKILL.md

@@ -1,129 +1,129 @@
----
-name: creating-journal
-description: その日の Skill 実行と意思決定を物語形式で `docs/journal/YYYYMMDD.md` に保存する。git log や diff から自動生成する `gulp journal:generate` とは別物で、こちらは「なぜそうしたか」「どこで詰まったか」「次回どう活かすか」といったコミットメッセージには載らない**判断と学びを残す**ためのスキル。「今日の作業をジャーナルに保存」「ここまでの作業の流れをジャーナルに」「skill の使用記録を残したい」「今日の振り返りを書く」「開発ジャーナルを作成」「セッション内容を記録」のような依頼で必ず発動する。一日の終わり、長いセッションの区切り、リリース直後、IT 完了時など「ここまでをまとめておきたい」場面でも積極的に提案する。
----
-
-# 開発ジャーナル作成
-
-その日のセッションで実行した Skill、対応した指摘、踏んだ落とし穴、得られた学びを `docs/journal/YYYYMMDD.md` として保存する。
-
-ジャーナルの価値は、**git log と CHANGELOG には残らない「判断の経緯」を残す**ことにある。「なぜ lts-24 に上げたか」「HLint の `within` をなぜ撤回したか」「Sprint 0 指摘 42 件をどう優先順位付けしたか」といった、コミットメッセージでは収まらない物語が、未来の自分とチームの意思決定速度を高める。
-
-## ファイル命名
-
-`docs/journal/<YYYYMMDD>.md` (例: `docs/journal/20260626.md`)
-
-セッションをまたぐ場合でも 1 日 1 ファイル。同じ日に追記が発生したら既存ファイルに追記する (上書きしない)。
-
-## 必須セクション (この順序)
-
-```markdown
-# YYYY-MM-DD 開発ジャーナル
-
-(1〜2 文のリード文。今日何をしたかを 1 段落で要約)
-
-## ハイライト
-
-- (最重要の成果 3〜5 個を箇条書き)
-
-## Skill 実行の時系列
-
-### 1. `<skill-name>` — <短い見出し>
-(何を入力し、何を出力したか。主要成果物の表)
-
-### 2. `<skill-name>` — <短い見出し>
-...
-
-## 学び
-
-- (次回再発させたくない発見、再利用したい知見)
-
-## 主要コミット
-
-| ハッシュ | コミット |
-| :--- | :--- |
-| `xxxxxxxx` | <メッセージ 1 行目> |
-```
-
-フェーズが長い場合は「Skill 実行の時系列」を **「分析フェーズ Skill 実行の時系列」「運用フェーズ Skill 実行の時系列」** のように分割する。今回 (2026-06-26) はこの形を採用した。
-
-## 作成手順
-
-### 1. 既存ジャーナルを確認
-
-`docs/journal/<today>.md` が既にあるか確認する。あれば**追記**する (上書き禁止)。なければ新規作成。
-
-### 2. このセッションで使った Skill を時系列で抽出
-
-会話履歴を遡り、`/<skill>` 形式の起動、`Skill` ツール呼び出し、Skill のオーケストレーションを抽出する。連続する関連 Skill は 1 つの節にまとめてよい。
-
-抽出すべきメタ情報:
-
-- 入力 (どの手順書/ドキュメント/与件を参照したか)
-- 主要成果物 (生成 or 更新したファイルパス)
-- 重要な意思決定 (技術選定、優先順位、撤回したルール等)
-- ハマったポイントと対処 (これが将来の検索キーになる)
-
-### 3. ハイライトを抽出
-
-その日の成果のうち **3〜5 個** だけ選ぶ。「重要な決定」「新規導入」「指標の達成」を優先する。コミット数や行数といったプロセス指標ではなく、**読者にとっての意味**で選ぶ。
-
-### 4. 学びを書く
-
-「次回再発させたくない発見」「再利用したい知見」を 3〜7 個。汎化して書く (このプロジェクト固有の話だけにならないように)。
-
-例として今日のジャーナル (`20260626.md`) には以下が記録されている:
-
-- HLint の `within` は直感に反するホワイトリストなので、アーキテクチャ規約は専用ツールに乗せる
-- macOS の BSD `ar` + GHC 9.8 の組み合わせは地雷
-- `stack build --pedantic` はスタブ期間中は不適合
-
-### 5. 主要コミットを git log から抽出
-
-このセッション中のコミットを `git log --oneline` で抽出し、テーブル化する。フェーズ別に分けるとさらに読みやすい。
-
-### 6. コミット
-
-```text
-docs(journal): YYYY-MM-DD のセッション記録を追加
-```
-
-または既存ファイルへの追記の場合は:
-
-```text
-docs(journal): YYYY-MM-DD のジャーナルに <セクション名> を追記
-```
-
-`creating-iteration-report` / `creating-release-report` 等の他レポート系 Skill とは別系統 (それらはフォーマル文書、ジャーナルは作業ログ) なので、コミットスコープも分けて運用する。
-
-## 書き方の指針
-
-### 「物語」として書く
-
-時系列・因果関係を保つ。「指摘 42 件を対応 → ハマった YAML 構文 → 撤回 → IT1 に委譲」のように **何が起きて何をしたか**の流れがわかるようにする。単なる箇条書きの羅列にしない。
-
-### 証拠として残す
-
-ファイルパス・コミットハッシュ・バージョン番号・件数を具体的に書く。「いっぱい修正した」ではなく「16 + 16 + 10 = 42 件対応」と書く。これが将来のジャーナル検索性を決める。
-
-### 「ハマったポイント」を恥ずかしがらずに書く
-
-ジャーナルの価値の半分は失敗の記録にある。「3 回目の修正でようやく CI が安定した」「YAML 構文を間違えていた」を**省略しない**。同じ罠に二度落ちないために残す。
-
-### コミットメッセージとの違いを意識する
-
-コミットメッセージは「この変更は何を達成したか」を書く。ジャーナルは「**なぜそうしたか、何を諦めたか、次回どう活かすか**」を書く。両者は補完関係。
-
-## やらないこと
-
-- **`gulp journal:generate` の置き換えではない** — あちらは git の diff/log から自動生成する補助。こちらは判断の物語を残す手動の作業。両方共存する
-- **CHANGELOG ではない** — ユーザー向けの変更点リストは `CHANGELOG.md` で別管理
-- **イテレーション報告書ではない** — フォーマルな完了報告書は `creating-iteration-report` で別管理
-- **アーカイブのために書かない** — 「未来の誰か (主に自分) が読み返して役立つか」を判定基準にする。役立たない記録は省く
-
-## 関連スキル
-
-- `creating-iteration-report` — イテレーション完了時のフォーマル報告書 (ジャーナルとは別)
-- `creating-release-report` — リリース完了時のフォーマル報告書
-- `tracking-progress` — 進捗の定量分析
-- `operating-docs` — ジャーナル追加後のインデックス更新 (`--update` で `docs/index.md` 同期)
+---
+name: creating-journal
+description: その日の Skill 実行と意思決定を物語形式で `docs/journal/YYYYMMDD.md` に保存する。git log や diff から自動生成する `gulp journal:generate` とは別物で、こちらは「なぜそうしたか」「どこで詰まったか」「次回どう活かすか」といったコミットメッセージには載らない**判断と学びを残す**ためのスキル。「今日の作業をジャーナルに保存」「ここまでの作業の流れをジャーナルに」「skill の使用記録を残したい」「今日の振り返りを書く」「開発ジャーナルを作成」「セッション内容を記録」のような依頼で必ず発動する。一日の終わり、長いセッションの区切り、リリース直後、IT 完了時など「ここまでをまとめておきたい」場面でも積極的に提案する。
+---
+
+# 開発ジャーナル作成
+
+その日のセッションで実行した Skill、対応した指摘、踏んだ落とし穴、得られた学びを `docs/journal/YYYYMMDD.md` として保存する。
+
+ジャーナルの価値は、**git log と CHANGELOG には残らない「判断の経緯」を残す**ことにある。「なぜ lts-24 に上げたか」「HLint の `within` をなぜ撤回したか」「Sprint 0 指摘 42 件をどう優先順位付けしたか」といった、コミットメッセージでは収まらない物語が、未来の自分とチームの意思決定速度を高める。
+
+## ファイル命名
+
+`docs/journal/<YYYYMMDD>.md` (例: `docs/journal/20260626.md`)
+
+セッションをまたぐ場合でも 1 日 1 ファイル。同じ日に追記が発生したら既存ファイルに追記する (上書きしない)。
+
+## 必須セクション (この順序)
+
+```markdown
+# YYYY-MM-DD 開発ジャーナル
+
+(1〜2 文のリード文。今日何をしたかを 1 段落で要約)
+
+## ハイライト
+
+- (最重要の成果 3〜5 個を箇条書き)
+
+## Skill 実行の時系列
+
+### 1. `<skill-name>` — <短い見出し>
+(何を入力し、何を出力したか。主要成果物の表)
+
+### 2. `<skill-name>` — <短い見出し>
+...
+
+## 学び
+
+- (次回再発させたくない発見、再利用したい知見)
+
+## 主要コミット
+
+| ハッシュ | コミット |
+| :--- | :--- |
+| `xxxxxxxx` | <メッセージ 1 行目> |
+```
+
+フェーズが長い場合は「Skill 実行の時系列」を **「分析フェーズ Skill 実行の時系列」「運用フェーズ Skill 実行の時系列」** のように分割する。今回 (2026-06-26) はこの形を採用した。
+
+## 作成手順
+
+### 1. 既存ジャーナルを確認
+
+`docs/journal/<today>.md` が既にあるか確認する。あれば**追記**する (上書き禁止)。なければ新規作成。
+
+### 2. このセッションで使った Skill を時系列で抽出
+
+会話履歴を遡り、`/<skill>` 形式の起動、`Skill` ツール呼び出し、Skill のオーケストレーションを抽出する。連続する関連 Skill は 1 つの節にまとめてよい。
+
+抽出すべきメタ情報:
+
+- 入力 (どの手順書/ドキュメント/与件を参照したか)
+- 主要成果物 (生成 or 更新したファイルパス)
+- 重要な意思決定 (技術選定、優先順位、撤回したルール等)
+- ハマったポイントと対処 (これが将来の検索キーになる)
+
+### 3. ハイライトを抽出
+
+その日の成果のうち **3〜5 個** だけ選ぶ。「重要な決定」「新規導入」「指標の達成」を優先する。コミット数や行数といったプロセス指標ではなく、**読者にとっての意味**で選ぶ。
+
+### 4. 学びを書く
+
+「次回再発させたくない発見」「再利用したい知見」を 3〜7 個。汎化して書く (このプロジェクト固有の話だけにならないように)。
+
+例として今日のジャーナル (`20260626.md`) には以下が記録されている:
+
+- HLint の `within` は直感に反するホワイトリストなので、アーキテクチャ規約は専用ツールに乗せる
+- macOS の BSD `ar` + GHC 9.8 の組み合わせは地雷
+- `stack build --pedantic` はスタブ期間中は不適合
+
+### 5. 主要コミットを git log から抽出
+
+このセッション中のコミットを `git log --oneline` で抽出し、テーブル化する。フェーズ別に分けるとさらに読みやすい。
+
+### 6. コミット
+
+```text
+docs(journal): YYYY-MM-DD のセッション記録を追加
+```
+
+または既存ファイルへの追記の場合は:
+
+```text
+docs(journal): YYYY-MM-DD のジャーナルに <セクション名> を追記
+```
+
+`creating-iteration-report` / `creating-release-report` 等の他レポート系 Skill とは別系統 (それらはフォーマル文書、ジャーナルは作業ログ) なので、コミットスコープも分けて運用する。
+
+## 書き方の指針
+
+### 「物語」として書く
+
+時系列・因果関係を保つ。「指摘 42 件を対応 → ハマった YAML 構文 → 撤回 → IT1 に委譲」のように **何が起きて何をしたか**の流れがわかるようにする。単なる箇条書きの羅列にしない。
+
+### 証拠として残す
+
+ファイルパス・コミットハッシュ・バージョン番号・件数を具体的に書く。「いっぱい修正した」ではなく「16 + 16 + 10 = 42 件対応」と書く。これが将来のジャーナル検索性を決める。
+
+### 「ハマったポイント」を恥ずかしがらずに書く
+
+ジャーナルの価値の半分は失敗の記録にある。「3 回目の修正でようやく CI が安定した」「YAML 構文を間違えていた」を**省略しない**。同じ罠に二度落ちないために残す。
+
+### コミットメッセージとの違いを意識する
+
+コミットメッセージは「この変更は何を達成したか」を書く。ジャーナルは「**なぜそうしたか、何を諦めたか、次回どう活かすか**」を書く。両者は補完関係。
+
+## やらないこと
+
+- **`gulp journal:generate` の置き換えではない** — あちらは git の diff/log から自動生成する補助。こちらは判断の物語を残す手動の作業。両方共存する
+- **CHANGELOG ではない** — ユーザー向けの変更点リストは `CHANGELOG.md` で別管理
+- **イテレーション報告書ではない** — フォーマルな完了報告書は `creating-iteration-report` で別管理
+- **アーカイブのために書かない** — 「未来の誰か (主に自分) が読み返して役立つか」を判定基準にする。役立たない記録は省く
+
+## 関連スキル
+
+- `creating-iteration-report` — イテレーション完了時のフォーマル報告書 (ジャーナルとは別)
+- `creating-release-report` — リリース完了時のフォーマル報告書
+- `tracking-progress` — 進捗の定量分析
+- `operating-docs` — ジャーナル追加後のインデックス更新 (`--update` で `docs/index.md` 同期)

package/lib/assets/.claude/skills/creating-release-report/SKILL.md

@@ -1,161 +1,161 @@
----
-name: creating-release-report
-description: リリース完了報告書を作成。release_plan.md・iteration_report・git log・CHANGELOG・journal からデータを収集し、テンプレートに基づいて報告書を生成する。「リリース完了報告書を作りたい」「リリースレポートを作成して」「v0.1.0 の報告書を作成」「リリースの振り返りをまとめたい」「プロジェクト完了報告書を書きたい」といった場面で発動する。リリースごとの成果を定量的に可視化し、プロジェクトの透明性と説明責任を確保する。
----
-
-# リリース完了報告書の作成
-
-リリース計画と開発ドキュメント群からデータを収集し、テンプレートに基づいてリリース完了報告書を作成する。
-
-報告書の価値は「何を達成したか」を定量的に示すこと。計画と実績の差異分析、品質メトリクス、コミットログ分析を通じて、プロジェクトの透明性を確保し、次のリリースへの知見を蓄積する。
-
-## テンプレート
-
-@docs/template/リリース完了報告書.md
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | 対話的にリリースバージョンを確認して報告書を作成 |
-| `--version <バージョン>` | 指定バージョンのリリース完了報告書を作成 |
-| `--all` | 未作成の全リリースの報告書を一括作成 |
-
-## 前提条件
-
-以下のファイルが存在すること:
-
-- `docs/development/release_plan.md` — リリース計画（Single Source of Truth）
-- `docs/development/iteration_report-{N}.md` — 対象イテレーションの完了報告書
-- `CHANGELOG.md` — 対象バージョンのエントリ
-- git タグ（`v{バージョン}`）が打たれていること
-
-## 作成フロー
-
-```mermaid
-graph TD
-    A[バージョン特定] --> B[データ収集]
-    B --> C[ジャーナル生成]
-    C --> D[報告書作成]
-    D --> E[インデックス更新]
-    E --> F[完了]
-```
-
-### Step 1: バージョン特定
-
-release_plan.md のリリース履歴と git タグから対象バージョンを特定する。
-
-- リリースに含まれるイテレーション範囲を確認
-- 対象ストーリーとフェーズを確認
-
-### Step 2: データ収集
-
-5 つのデータソースから報告書に必要な情報を収集する。
-
-#### 2.1 リリース計画（`docs/development/release_plan.md`）
-
-- プロジェクト情報（名称・目的・チーム規模）
-- フェーズ別ストーリー一覧と SP
-- イテレーション別の計画 SP・実績 SP・達成率
-- 計画スケジュール（ガントチャート用の日付）
-- リリース条件の達成状況
-
-#### 2.2 イテレーション完了報告書（`docs/development/iteration_report-{N}.md`）
-
-- 各イテレーションの日程（計画期間・実績期間・実績日数）
-- テスト結果（Backend / Frontend / E2E のテスト数）
-- テストカバレッジ
-- SonarQube Quality Gate 結果
-- ストーリー別の完了状況
-
-#### 2.3 コミットログ（git）
-
-```bash
-# 対象リリースまでのコミット数
-git log --oneline --no-merges <TAG> | wc -l
-
-# プリフィックス別内訳
-git log --oneline --no-merges <TAG> --format="%s" | sed 's/(.*//' | sed 's/:.*//' | sort | uniq -c | sort -rn
-
-# 開発期間
-git log --oneline --no-merges <TAG> --format="%ai" | tail -1  # 最初のコミット
-git log --oneline --no-merges <TAG> --format="%ai" | head -1  # 最後のコミット
-```
-
-#### 2.4 CHANGELOG（`CHANGELOG.md`）
-
-- 対象バージョンの Features / Bug Fixes / Documentation / Tests の内訳
-
-#### 2.5 ジャーナル（`docs/journal/YYYYMMDD.md`）
-
-- 日付ごとの詳細な作業内容
-
-ジャーナルが未生成の場合は `npm run journal` を実行して生成する。
-
-### Step 3: 報告書作成
-
-テンプレート（`docs/template/リリース完了報告書.md`）を基に、収集データでプレースホルダーを埋める。
-
-**出力ファイル命名規則**:
-
-```
-docs/development/release_report-{バージョン（ドットをアンダースコアに置換）}.md
-```
-
-例: `release_report-0_1_0.md`、`release_report-0_2_0.md`
-
-**各セクションの作成ポイント**:
-
-| セクション | データソース | ポイント |
-|-----------|------------|---------|
-| プロジェクトサマリー | release_plan.md + git log | 総コミット数・テスト数は実測値を使用 |
-| イテレーション別達成状況 | release_plan.md 進捗状況テーブル | 計画 SP と実績 SP をそのまま転記 |
-| 計画日程 vs 実績日数 | iteration_report-*.md | 計画期間と実績期間から短縮率を算出 |
-| コミットログ分析 | git log | プリフィックス別の件数と割合を算出 |
-| 品質メトリクス | iteration_report-*.md | リリース時点（最終 IT）のカバレッジを使用 |
-| ベロシティ | release_plan.md | 平均・最大・最小を算出 |
-| 主要な成果物 | CHANGELOG.md + user_story.md | ストーリー単位で実装内容をまとめる |
-| 作業履歴 | docs/journal/ | 日付ごとの主要な作業を要約 |
-
-**Mermaid チャート**:
-
-- バーンダウンチャート: `xychart-beta` で計画 vs 実績の折れ線
-- ガントチャート: `gantt` で計画 vs 実績のスケジュール比較
-- ベロシティ: `xychart-beta` で棒グラフ + 平均線
-- コミット内訳: `pie showData` でパイチャート
-- テスト推移: `xychart-beta` で棒グラフ
-
-### Step 4: インデックス更新
-
-作成した報告書を以下の 3 ファイルに登録する:
-
-1. `docs/development/index.md` — リリース完了報告書セクションにエントリ追加
-2. `docs/index.md` — 開発セクションにエントリ追加
-3. `mkdocs.yml` — nav の開発セクションにエントリ追加
-
-## 途中から再開
-
-報告書作成の途中から再開する場合は、既存の報告書ファイルを確認する。
-
-**Example:**
-
-```
-ユーザー: 「v0.2.0 のリリース完了報告書を作って」
-回答: docs/development/release_report-0_2_0.md の存在を確認し、
-      なければ release_plan.md から IT4-5 のデータを収集して作成する。
-```
-
-## 注意事項
-
-- release_plan.md を Single Source of Truth として扱い、データの不整合がある場合は release_plan.md を優先する
-- コミット数・テスト数は git log や iteration_report の実測値を使用し、推測値を使わない
-- Mermaid チャートの数値は必ずデータソースと照合する
-- 工期短縮率の算出は「(計画日数 - 実績日数) / 計画日数 × 100」で統一する
-
-## 関連スキル
-
-- `planning-releases` — リリース計画の作成と管理
-- `tracking-progress` — 進捗分析・レポート生成
-- `developing-release` — リリースワークフロー（品質ゲート→バージョンバンプ→タグ）
-- `operating-docs` — ドキュメントインデックス更新
-- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション
+---
+name: creating-release-report
+description: リリース完了報告書を作成。release_plan.md・iteration_report・git log・CHANGELOG・journal からデータを収集し、テンプレートに基づいて報告書を生成する。「リリース完了報告書を作りたい」「リリースレポートを作成して」「v0.1.0 の報告書を作成」「リリースの振り返りをまとめたい」「プロジェクト完了報告書を書きたい」といった場面で発動する。リリースごとの成果を定量的に可視化し、プロジェクトの透明性と説明責任を確保する。
+---
+
+# リリース完了報告書の作成
+
+リリース計画と開発ドキュメント群からデータを収集し、テンプレートに基づいてリリース完了報告書を作成する。
+
+報告書の価値は「何を達成したか」を定量的に示すこと。計画と実績の差異分析、品質メトリクス、コミットログ分析を通じて、プロジェクトの透明性を確保し、次のリリースへの知見を蓄積する。
+
+## テンプレート
+
+@docs/template/リリース完了報告書.md
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | 対話的にリリースバージョンを確認して報告書を作成 |
+| `--version <バージョン>` | 指定バージョンのリリース完了報告書を作成 |
+| `--all` | 未作成の全リリースの報告書を一括作成 |
+
+## 前提条件
+
+以下のファイルが存在すること:
+
+- `docs/development/release_plan.md` — リリース計画（Single Source of Truth）
+- `docs/development/iteration_report-{N}.md` — 対象イテレーションの完了報告書
+- `CHANGELOG.md` — 対象バージョンのエントリ
+- git タグ（`v{バージョン}`）が打たれていること
+
+## 作成フロー
+
+```mermaid
+graph TD
+    A[バージョン特定] --> B[データ収集]
+    B --> C[ジャーナル生成]
+    C --> D[報告書作成]
+    D --> E[インデックス更新]
+    E --> F[完了]
+```
+
+### Step 1: バージョン特定
+
+release_plan.md のリリース履歴と git タグから対象バージョンを特定する。
+
+- リリースに含まれるイテレーション範囲を確認
+- 対象ストーリーとフェーズを確認
+
+### Step 2: データ収集
+
+5 つのデータソースから報告書に必要な情報を収集する。
+
+#### 2.1 リリース計画（`docs/development/release_plan.md`）
+
+- プロジェクト情報（名称・目的・チーム規模）
+- フェーズ別ストーリー一覧と SP
+- イテレーション別の計画 SP・実績 SP・達成率
+- 計画スケジュール（ガントチャート用の日付）
+- リリース条件の達成状況
+
+#### 2.2 イテレーション完了報告書（`docs/development/iteration_report-{N}.md`）
+
+- 各イテレーションの日程（計画期間・実績期間・実績日数）
+- テスト結果（Backend / Frontend / E2E のテスト数）
+- テストカバレッジ
+- SonarQube Quality Gate 結果
+- ストーリー別の完了状況
+
+#### 2.3 コミットログ（git）
+
+```bash
+# 対象リリースまでのコミット数
+git log --oneline --no-merges <TAG> | wc -l
+
+# プリフィックス別内訳
+git log --oneline --no-merges <TAG> --format="%s" | sed 's/(.*//' | sed 's/:.*//' | sort | uniq -c | sort -rn
+
+# 開発期間
+git log --oneline --no-merges <TAG> --format="%ai" | tail -1  # 最初のコミット
+git log --oneline --no-merges <TAG> --format="%ai" | head -1  # 最後のコミット
+```
+
+#### 2.4 CHANGELOG（`CHANGELOG.md`）
+
+- 対象バージョンの Features / Bug Fixes / Documentation / Tests の内訳
+
+#### 2.5 ジャーナル（`docs/journal/YYYYMMDD.md`）
+
+- 日付ごとの詳細な作業内容
+
+ジャーナルが未生成の場合は `npm run journal` を実行して生成する。
+
+### Step 3: 報告書作成
+
+テンプレート（`docs/template/リリース完了報告書.md`）を基に、収集データでプレースホルダーを埋める。
+
+**出力ファイル命名規則**:
+
+```
+docs/development/release_report-{バージョン（ドットをアンダースコアに置換）}.md
+```
+
+例: `release_report-0_1_0.md`、`release_report-0_2_0.md`
+
+**各セクションの作成ポイント**:
+
+| セクション | データソース | ポイント |
+|-----------|------------|---------|
+| プロジェクトサマリー | release_plan.md + git log | 総コミット数・テスト数は実測値を使用 |
+| イテレーション別達成状況 | release_plan.md 進捗状況テーブル | 計画 SP と実績 SP をそのまま転記 |
+| 計画日程 vs 実績日数 | iteration_report-*.md | 計画期間と実績期間から短縮率を算出 |
+| コミットログ分析 | git log | プリフィックス別の件数と割合を算出 |
+| 品質メトリクス | iteration_report-*.md | リリース時点（最終 IT）のカバレッジを使用 |
+| ベロシティ | release_plan.md | 平均・最大・最小を算出 |
+| 主要な成果物 | CHANGELOG.md + user_story.md | ストーリー単位で実装内容をまとめる |
+| 作業履歴 | docs/journal/ | 日付ごとの主要な作業を要約 |
+
+**Mermaid チャート**:
+
+- バーンダウンチャート: `xychart-beta` で計画 vs 実績の折れ線
+- ガントチャート: `gantt` で計画 vs 実績のスケジュール比較
+- ベロシティ: `xychart-beta` で棒グラフ + 平均線
+- コミット内訳: `pie showData` でパイチャート
+- テスト推移: `xychart-beta` で棒グラフ
+
+### Step 4: インデックス更新
+
+作成した報告書を以下の 3 ファイルに登録する:
+
+1. `docs/development/index.md` — リリース完了報告書セクションにエントリ追加
+2. `docs/index.md` — 開発セクションにエントリ追加
+3. `mkdocs.yml` — nav の開発セクションにエントリ追加
+
+## 途中から再開
+
+報告書作成の途中から再開する場合は、既存の報告書ファイルを確認する。
+
+**Example:**
+
+```
+ユーザー: 「v0.2.0 のリリース完了報告書を作って」
+回答: docs/development/release_report-0_2_0.md の存在を確認し、
+      なければ release_plan.md から IT4-5 のデータを収集して作成する。
+```
+
+## 注意事項
+
+- release_plan.md を Single Source of Truth として扱い、データの不整合がある場合は release_plan.md を優先する
+- コミット数・テスト数は git log や iteration_report の実測値を使用し、推測値を使わない
+- Mermaid チャートの数値は必ずデータソースと照合する
+- 工期短縮率の算出は「(計画日数 - 実績日数) / 計画日数 × 100」で統一する
+
+## 関連スキル
+
+- `planning-releases` — リリース計画の作成と管理
+- `tracking-progress` — 進捗分析・レポート生成
+- `developing-release` — リリースワークフロー（品質ゲート→バージョンバンプ→タグ）
+- `operating-docs` — ドキュメントインデックス更新
+- `orchestrating-project` — 計画・進捗管理フェーズ全体のオーケストレーション