Growth Log スキル
問題点: 多くの人は学習ログとして「Xのバグを修正しました」と書きます。それは日記であって、学習成果物ではありません。真の成長ログはパターンを抽出し、次回同じ状況に遭遇したときに認識できるようにします。
このスキルが教えること: セッションをまたいで学習効果が積み上がるエントリの書き方。Markdownファイル、Notion、Obsidian、プレーンテキストなど、あらゆるノートシステムで動作します。テンプレートは汎用的で、各自の環境に合わせて調整可能です。
起動条件
- 複雑なタスク（複数ファイル、新機能、アーキテクチャ変更など）を完了した後
- 失敗、ミス、または「予想より難しかった」と感じた瞬間の後
- 一定期間の学習内容を振り返りたいとき
起動すべきでない場合: 些細な変更（タイポ修正、1行の調整、デバッグを伴わない設定値の変更）。判断基準: このタスクには、デバッグ、やり直し、ロールバック、または明白でない判断が含まれていたか？ はい → エントリを作成。いいえ → スキップ。
3つのルール
ルール1: 失敗 > 成功
失敗は成功よりも栄養価が高い。発見に2時間かかった1つのバグは、初回でうまくいった3つの機能よりも多くのことを教えてくれます。
悪い例: 「ログインフローを正常に実装しました。」
良い例（Web開発）: 「ログインフロー: Chrome 128+でCookieのSameSiteがデフォルトでLaxになっていたため、セッショントークンが永続化しなかった。パターン: クロスオリジンでは必ずSameSite=None; Secureを明示的に設定する。認識のシグナル: ブラウザアップグレード後、またはオリジン境界を越える際に認証が壊れる。」
良い例（データパイプライン）: 「CSVインポートが空行で静かに失敗した。pandas.read_csv(dropna=False)はゼロ幅行を保持し、len()がそれを有効とカウントするため。パターン: 行数検証の前に必ずdf.dropna(how='all', inplace=True)を実行する。」
ルール2: 伯楽原則（Bole Principle）
新しいエントリを書く前に、自問してください: 「これは既に記録したものと根本的に同じではないか？」
同じ根本原因、異なる症状 → マージ。重複禁止。新しい根本原因 → 新しいエントリ。
確認方法: エントリを書く前に、既存のエントリを根本原因のキーワードで検索する。一致するものがあれば、新しい症状を既存エントリの追記例として追加し、重複エントリを作成しない。
例: 「ファイル作成後に出力インデックスを更新し忘れた」と「タスク後にスキル評価を更新し忘れた」— 同じ根本原因（自動キャプチャトリガーの欠如）。「タスク後キャプチャの抜け漏れ」という1つのエントリにマージする。
ルール3: 転用可能であること
すべてのエントリは次の問いに答えなければなりません: 「次回同様の状況に直面したとき、私は何を異なる方法で行うか？」
その一文が書けないなら、まだパターンを抽出できていません。
具体的な出来事からパターンを抽出する方法:
- 何が起こったかを一文で述べる
- 「なぜ？」を繰り返し、根本原因にたどり着くまで問う（通常3〜5回）
- 一般化する: 「これはどのクラスの問題か？」（「Chrome 128のバグ」ではなく「ブラウザのデフォルト変更が既存動作を壊す」）
- 次のように定式化する: 「次に[シグナル]を見たら、[アクション]を実行する。」
- シグナルに名前を付ける: このパターンがアクティブであることを示す具体的で観察可能な兆候は何か？
エントリテンプレート
スコープ: 1エントリにつき1つの明確な根本原因。標準的な長さ: 4〜8文。2分以上かかるならイベントを物語っている。30秒未満なら深掘りが足りない。
## [タイトル: イベントではなくパターン]
### コンテキスト
- 何をしようとしていたか？
- 何がうまくいかなかったか、または驚くほど上手くいったか？
### 根本原因 / 核となる洞察
- 症状ではなく、根本的なメカニズム
### パターン（転用可能）
- 次に[同様の状況]では、[具体的なアクション]を実行する。
- 認識のシグナル: [このパターンがアクティブであることを示す観測可能な兆候は？]
### 関連エントリ
- [エントリ名](../path/to/related-entry.md)
エントリタイプ
4つのタイプすべてが上記テンプレートを使用します。タイプによって、どのセクションに重点を置くかが決まります:
| タイプ | 使用タイミング | 重点 | タイトル例 |
|---|---|---|---|
| 失敗 (Failure) | 何かが壊れた、デバッグが必要だった、またはリワークが必要だった | 根本原因 | 「設定の継承 ≠ セッションをまたぐ動作の継承」 |
| 方法論 (Methodology) | 作業から反復可能なプロセスが生まれた | コンテキスト / パターン | 「PPT → オープンブック試験勉強ガイド: 3層構造」 |
| パターン発見 (Pattern Discovery) | ツール、システム、思考に関する再利用可能な洞察 | パターンセクション | 「PR説明テンプレート: 機能ではなく、ギャップを説明する」 |
| 能力変化 (Capability Change) | 測定可能なスキル向上 | コンテキスト（ビフォー vs アフター） | 「Git: clone/pushから、12コミットの独立したPRへ」 |
品質チェックリスト
成長ログエントリを確定する前に:
- タイトルはイベントではなくパターンを表しているか？
- 「次回は〜する」という文があるか？
- 「認識のシグナル」は、次回パターンを発動させるのに十分具体的か？
- 書く前に既存エントリを重複検索したか？（伯楽原則）
- 根本原因と症状が区別されているか？
- 関連する記憶が相互リンクされているか？
- エントリは4〜8文か？ 短すぎ＝浅い、長すぎ＝イベントの物語。
アンチパターン
- 避けるべき: 「支払いモジュールのバグを修正」 (イベントであり、パターンではない)
- 避けるべき: gitコミットメッセージをそのままコピーする（コミットは何が変わったかを記述し、ログはなぜ重要かを抽出する）
- 避けるべき: すべてのコミットに対してエントリを書く（パターンが現れたときのみ）
- 避けるべき: 転用可能な一文を省略する（これがないと単なる日記 — これは譲歩できない）
- 避けるべき: 異なるタイトルで同じパターンを重複させる（伯楽原則違反 — 書く前に検索すること）
保存
エントリはノートを保存している場所ならどこでも構いません。よくあるパターン:
growth-log/ディレクトリ内のMarkdownファイル（1日1ファイル:YYYY-MM-DD.md）- Notion、Obsidian、またはノートアプリ内の専用セクション
- 一貫した命名規則を持つプレーンテキストファイル
1つの規則を選んで守りましょう。フォーマットよりも検索しやすさが重要です。
Delivery Gate を使用する場合
delivery-gate のStopフックは、ファイルシステムのタイムスタンプを介して、学習ファイルが今日変更されたかどうかをチェックします。このスキルは何を書くべきかを教えるものです。つまり、delivery-gateがチェックするファイルに、空のタイムスタンプではなく、実際に有用なパターンが含まれるようになります。
タスク完了 → delivery-gateチェック: 学習ファイルは今日変更されたか？
→ 未更新（ファイル変更なし）: ブロック — 「何を学びましたか？」
→ 更新済み（ファイル変更あり）: 通過 — このスキルにより内容が有用であることが保証される
強制力だけあって方法論がないと空のエントリになります。方法論だけあって強制力がないと、学習は忘れ去られます。それぞれ単独でも有用ですが、組み合わせることでループが閉じます。