Memo

Memo — 知識倉庫への記録

現在のセッションから「後から振り返る価値のある知識」を抽出し、~/dev/knowledge/notes/ に Markdown で保存する。 このフォルダはユーザーが Obsidian の vault として開くため、Obsidian の流儀（ファイル名 = タイトル、ウィキリンク、frontmatter タグ）に従う。

記録すべきもの

• knowledge: 実装を通して得た学び。ライブラリの非自明な挙動、API の落とし穴、デバッグで判明した原因など
• decision: 設計判断。検討した選択肢、採用した案とその理由、却下した案とその理由
• style: ユーザーのコーディング観・クセ・好み。指示の出し方、レビューコメント、選択の傾向から読み取れたもの
• strength: ユーザーの長所・強み。良い設計判断をした、鋭い指摘をした、リスクに先回りで気づいた、質問の筋が良かった、など上手くいった行動とその理由
• weakness: ユーザーの苦手・つまずき。理解が浅かった概念、繰り返しハマった箇所、質問が多かった領域、後から手戻りになった判断など
• domain: 事業・業務ドメインの理解。業務フロー、用語、システムの背景、仕様の意図など実務固有の知識

style / strength / weakness はこの仕組みの主目的（自己の振り返り）なので、セッション中にユーザーの傾向・良かった行動・つまずきを観測したら積極的に記録する。遠慮して漏らすより、多めに拾う方がよい。特に strength は意識しないと拾い漏れやすいので、「今日ユーザーの判断で上手くいったことは何か」を必ず自問する。お世辞ではなく、根拠のある事実だけを書く。weakness も内容は事実ベースで書き、人格評価はしない。

保存先の振り分け

• 汎用的な内容（knowledge / decision / style / strength / weakness）→ notes/ に保存する。 実務プロジェクト由来でも、社名・案件名・仕様の詳細・コード断片を含めず、一般化した技術知識として書く
• ドメイン知識（domain）→ domain/<プロジェクト名>/ に保存する。実務固有の情報をそのまま書いてよい
• 迷ったら（一般化しきれない・実務の文脈と不可分な内容は）domain/ 側に倒す

記録すべきでないもの

• コードやコミット履歴を見ればわかること
• そのセッション限りの些末な作業ログ
• 一般的すぎてわざわざ記録する価値のない知識（公式ドキュメントの冒頭に書いてあるようなこと）

二段運用 — 逐次1行メモと節目の清書

長いセッションではコンテキスト圧縮で序盤の学びが劣化するため、記録は2段階で行う。

作業の途中（設計判断が確定した・非自明な挙動が判明した・ユーザーの良い判断やつまずきを観測した直後）は、inbox に1行追記するだけで本来の作業に戻る。ノートの清書はしない:

echo "- YYYY-MM-DD (プロジェクト名) [type]: 内容の1行要約" >> ~/dev/knowledge/inbox.md

節目（コミット直後・PR マージ直後・レビュー指摘対応完了直後、またはユーザーが /memo を明示的に呼んだとき）は、下の手順に従って inbox の未処理行とセッションの記憶からノートを清書・統合する。清書し終えた行は inbox.md から削除する。

手順

0. 倉庫が存在しない場合は作成する:

   mkdir -p ~/dev/knowledge/notes ~/dev/knowledge/domain
   

1. ~/dev/knowledge/inbox.md があれば読み、未処理行をトピック候補に含める。 あわせてセッションを振り返り、記録価値のあるトピックを抽出する（0件なら何もせず終了する）。 knowledge / decision だけでなく、「ユーザーは今日どこでつまずいたか」「どんな判断の傾向を見せたか」「どの判断・行動が良かったか」を必ず自問する

2. 各トピックについて、既存ノートを検索する（notes/ と domain/ の両方）:

   ls ~/dev/knowledge/notes/ ~/dev/knowledge/domain/*/
   grep -ril "<キーワード>" ~/dev/knowledge/notes/ ~/dev/knowledge/domain/
   

   同じトピックの既存ノートがあれば新規作成せず追記・更新する。 特に style / strength / weakness は既存ノートへの事例の追記が基本形（傾向は積み重ねで初めて見えるため）

3. 新規の場合、ファイル名は内容がひと目でわかる簡潔な日本語タイトルにする。 style / strength / weakness は傾向そのものをタイトルにする（例: 早期リターンを好む.md、エッジケースへの嗅覚が鋭い.md、非同期処理の考慮漏れが多い.md）。 日付プレフィックスは付けない（Obsidian のリンクとグラフビューはファイル名ベースのため）

4. 以下の形式で書く:

   ---
   date: YYYY-MM-DD          # 初回記録日。事例追記時は last_seen を更新する
   last_seen: YYYY-MM-DD     # style / strength / weakness のみ。最後に観測した日
   project: プロジェクト名（横断的なものは general）
   type: knowledge | decision | style | strength | weakness | domain
   tags: [具体的な技術名やテーマ]
   ---
   
   本文
   

   • knowledge は「何が起きたか」「何がわかったか」を含める
   • decision は「検討した選択肢」「採用理由」「却下理由」を含める
   • style / strength / weakness は「どういう傾向か」の要約に続けて、必ず ## 事例 セクションを設け、 観測するたびに - YYYY-MM-DD (プロジェクト名): 何があったか を1行追記する。 strength は「なぜそれが効いたか」も事例に添える（再現可能にするため）。 weakness は可能なら ## 対策 セクションに改善のヒントも書く
   • domain は「業務がどう動くか」「なぜその仕様なのか」を、コードを知らない未来の自分にも わかる形で書く
   • 本文は通常の文体（ずんだもん口調にしない）で、簡潔に書く

5. 関連する既存ノートには本文中に [[ノート名]] でウィキリンクを張る（手順2の検索結果を活用する）。 逆方向のリンクが自然な場合は、既存ノート側にも [[新ノート名]] を追記してよい

6. 記録内容の報告はしない。実装作業の流れで自動記録した場合は、記録に一切言及せず本来の作業の報告だけを行う （ユーザーが意識しなくても知識が蓄積されていくのがこの仕組みの意図）。 ユーザーが明示的に /memo を呼んだ場合のみ、記録したファイル名を1行で伝える