Growth Log スキル
問題: ほとんどの人は「Xでバグを修正した」と学習ログに書きます。それは日記であり、学習成果物ではありません。本当の成長ログはパターンを抽出し、次回認識できるようにします。
このスキルが教えること: セッションを超えて累積する学習エントリの書き方。Markdownファイル、Notion、Obsidian、プレーンテキストなど、あらゆるノートシステムで動作します。テンプレートは汎用的で、自分の環境に合わせて調整できます。
いつアクティブにするか
- 複雑なタスク（複数ファイル、新機能、アーキテクチャ変更）を完了した後
- 失敗、ミス、または「思ったより大変だった」という瞬間の後
- 一定期間の学習内容を振り返りたいとき
アクティブにしない場合: 些細な変更（タイプミスの修正、1行の調整、デバッグのない設定値の変更）。しきい値: このタスクにはデバッグ、やり直し、ロールバック、または明白でない判断が含まれていたか？ はい → エントリを書く。いいえ → スキップ。
3つのルール
ルール 1: 失敗は成果よりも価値がある
失敗は成功よりも栄養密度が高い。見つけるのに2時間かかったバグ1つは、初回でうまくいった3つの機能よりも多くのことを教えてくれます。
悪い例: 「ログインフローを正常に実装しました。」
良い例（Web開発）: 「ログインフロー: Chrome 128+ でクッキーの SameSite のデフォルトが Lax になったため、セッショントークンが保持されていなかった。パターン: クロスオリジンのときは常に SameSite=None; Secure を明示的に設定する。認識するシグナル: ブラウザアップグレード後、またはオリジン境界をまたぐときに認証が壊れる。」
良い例（データパイプライン）: 「CSVインポートが空行で静かに失敗した。理由は pandas.read_csv(dropna=False) がゼロ幅の行を保持し、len() がそれを有効とカウントするため。パターン: 行数バリデーションの前に必ず df.dropna(how='all', inplace=True) を実行する。」
ルール 2: ボレ原則（伯乐原则）
新しいエントリを書く前に自問する: 「これは既に記録したものと根本的に同じではないか？」
同じ根本原因で異なる症状 → マージし、重複させない。新しい根本原因 → 新しいエントリ。
確認方法: エントリを書く前に、根本原因のキーワードで既存のエントリを検索する。一致するものが見つかったら、新しい症状を既存のエントリに追加の例として加え、重複を作成しない。
例: 「ファイル作成後に出力インデックスを更新し忘れた」と「タスク後にスキルレーティングを更新し忘れた」— 同じ根本原因（自動取得トリガーがない）。「タスク後の取得漏れ」に関する1つのエントリにマージする。
ルール 3: 転移可能でなければならない
すべてのエントリは次の問いに答えなければならない: 「次に同じような状況に直面したら、私は何を違うようにするか？」
その文が書けないなら、まだパターンを抽出できていない。
具体的な出来事からパターンを抽出する方法:
- 何が起こったかを一文で述べる
- 根本原因に達するまで「なぜ？」を繰り返す（通常3〜5回）
- 一般化する: 「これはどのクラスの問題か？」（「Chrome 128のバグ」ではなく「ブラウザのデフォルト変更が既存の動作を壊す」）
- 「次に[シグナル]を見たら、私は[アクション]を取る」と定式化する
- シグナルに名前を付ける: どの具体的な観測可能な事象がこのパターンの発動を示すか？
エントリテンプレート
範囲: 根本原因ごとに1エントリ。標準的な長さ: 4〜8文。書くのに2分以上かかる場合は、出来事を語っているだけ。30秒未満なら、深掘りが足りない。
## [タイトル: 出来事ではなくパターン]
### コンテキスト
- 何をしようとしていたか？
- 何がうまくいかなかったか / 驚くほどうまくいったか？
### 根本原因 / 核心的洞察
- 症状ではなく、その背後にあるメカニズム
### パターン（転移可能）
- 次に[同様の状況]では、私は[具体的なアクション]を取る。
- 認識するシグナル: [このパターンが発動していることを示す観測可能な事象は？]
### 関連
- [エントリ名](../path/to/related-entry.md)
エントリタイプ
4つのタイプはすべて上記のテンプレートを使用します。タイプによって、どのセクションに重点を置くかが決まります。
| タイプ | 使用するタイミング | 強調するセクション | 例のタイトル |
|---|---|---|---|
| 失敗 | 何かが壊れた、デバッグが必要だった、または手直しが必要だった | 根本原因 | 「設定の継承 ≠ 動作の継承（セッション間）」 |
| 方法論 | 作業から反復可能なプロセスが生まれた | コンテキスト / パターン | 「PPT → オープンブック試験対策ガイド: 3層構造」 |
| パターン発見 | ツール、システム、思考に関する再利用可能な洞察 | パターンセクション | 「PR説明テンプレート: 機能ではなくギャップを説明する」 |
| 能力変化 | 測定可能なスキル向上 | コンテキスト（前 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 の停止フックは、ファイルシステムのタイムスタンプを介して学習ファイルが今日変更されたかをチェックします。このスキルは何を書くかを教えるため、delivery-gateがチェックするファイルに実際に有用なパターンが含まれ、空のタイムスタンプではないことを保証します。
タスク完了 → delivery-gateチェック: 学習ファイルは今日触られたか？
→ 古い（ファイル未変更）: ブロック — 「何を学びましたか？」
→ 新しい（ファイルが触られた）: 通過 — このスキルが内容を有用に保つ
強制力がなければ方法論だけでは空のエントリが生まれます。方法論がなければ強制力だけでは学びの記録は忘れられます。それぞれ独立して有用ですが、一緒に使うことでループを閉じます。