TIL を再利用可能な知識へ — /til-to-knowledge

どんな問題があったかというと

TIL はどんどん溜まるのに、知識は溜まらないことが多いんです。

なぜだろうと考えてみたのですが、TIL は本質的に「その日そのプロジェクトで起きたこと」の記録ですよね。文脈にがっちり縛られています。だから一か月後に読み返すと当時の状況を思い出せず、どこにも使えません。

/til-to-knowledge はこの隙間を埋めるコマンドです。1 日分の TIL を受け取って、その中にあるどこでも通用する CS・ウェブの概念を取り出し、それぞれを完結した学習ドキュメントとして書いてくれます。

入力 — Obsidian ボルトの wiki/todayILearned/{日付}.md を読みます。日付を省くと最新の TIL です。
抽出 — TIL から学べる主題を取り出します。ここで問いが重要で、「今日このバグを直した」ではなく**「このバグの背後にある一般原理は何か」**を問います。
二重記録 — 同じ知識を二つの形式に変換して書きます。
- ボルト wiki/cs/{ドメイン}/ — 一行定義 / なぜ必要か / 中核概念 / 診断の問い / 処方という構成です。TIL ノートへ wikilink で逆リンクを張ります。
- ブログ content/knowledge/{カテゴリ}/ — Zod スキーマを満たす公開用ドキュメントです。このサイトの Knowledge セクションがまさにこの成果物です。

二つのシステムは形式も分類体系も違うので、コピーではなく変換です。ボルトのドキュメントには frontmatter が一切なく、ブログのドキュメントには ディレクトリ名 === frontmatter の category という決まりがあります。

TIL には会社のプロジェクト名やパス、数値がそのまま入っています。ですが、このコマンドの成果物は公開が前提です。

なので TIL は概念を取り出す入力としてだけ使い、成果物は教科書のように書き直します。成果物だけを見て、どの会社のどのプロジェクトかが分かってはいけません。プロジェクトの逸話や数値は引用せず、例が必要なら foo や example.com のような匿名の例に置き換えます。

もう一つのルールは stub 禁止です。「あとで埋める TODO ドキュメント」は作りません。空の器は知識グラフにおける破られた約束になりますから。そして正直なところ、結局誰も埋めません。

/agent-memory-log が溜めたセッション記録と日次 TIL がこのコマンドの入力で、ここで生まれた knowledge ドキュメントがブログ記事の根拠になります。

[記録 → 知識 → 記事] の中では真ん中の段階です。文脈に縛られた記録を、文脈なしでも読める知識へ昇格させる場所ですね。

知識管理のボトルネックは、収集ではなく変換でした。

記録は熱心に溜まるのに知識が溜まらないなら、記録を汎用概念へ書き直す段階が抜けているんです。ただ、その変換を毎回人の手でやると絶対に続きません。だからルール（機密の除去・stub 禁止・分類の不変条件）をコマンド自体に埋め込んでしまいました。