@k2works/claude-code-booster 6.4.0 → 6.6.0

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

@@ -1,140 +1,140 @@
----
-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. OKF バンドルに登録
-
-`docs/` が OKF バンドル（ルート `index.md` に `okf_version` がある）なら、`apply-okf` スキルでジャーナルにフロントマターを付ける。
-
-```bash
-python .claude/skills/apply-okf/scripts/okf_apply.py apply docs docs/journal/<today>.md --by <agent>
-```
-
-ジャーナルは本文をエージェントが書くので `--by` は `claude-code/<model>` のようなエージェント形式。`type` は `journal/` から `Journal` と推定される。追記の場合も本文が変わるので `generated.at` が更新される（これが「最後に書いた日時」を正しく表す）。`journal/index.md` へのエントリ追加と `log.md` への記録はスクリプトが行う。
-
-### 7. コミット
-
-```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` — 進捗の定量分析
-- `apply-okf` — ジャーナルへの OKF フロントマター付与と `journal/index.md`・`log.md` 更新
-- `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. OKF バンドルに登録
+
+`docs/` が OKF バンドル（ルート `index.md` に `okf_version` がある）なら、`apply-okf` スキルでジャーナルにフロントマターを付ける。
+
+```bash
+python .claude/skills/apply-okf/scripts/okf_apply.py apply docs docs/journal/<today>.md --by <agent>
+```
+
+ジャーナルは本文をエージェントが書くので `--by` は `claude-code/<model>` のようなエージェント形式。`type` は `journal/` から `Journal` と推定される。追記の場合も本文が変わるので `generated.at` が更新される（これが「最後に書いた日時」を正しく表す）。`journal/index.md` へのエントリ追加と `log.md` への記録はスクリプトが行う。
+
+### 7. コミット
+
+```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` — 進捗の定量分析
+- `apply-okf` — ジャーナルへの OKF フロントマター付与と `journal/index.md`・`log.md` 更新
+- `operating-docs` — ジャーナル追加後のインデックス更新 (`--update` で `docs/index.md` 同期)