matome

name	matome
description	今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
argument-hint	[トピック]についてまとめて

matome

今のセッションの会話 log を素材に、ユーザーが学んだことを「個人用の公開メモ」1枚にまとめてチャットに返す。

普通に「〇〇について解説して」と頼むと、Claudeは一般論を一から書く。だがこのスキルが作るのは違う。この会話の中で実際に出てきて、ユーザーにとって新しかったことを、抜け漏れなく1枚に畳み込む。会話で芋づる式にたどり着いた知識ほど、本人にとって価値が高く、後で思い出したいものだからだ。

このスキルが解く問題

会話はこう進む:

Aについて聞く → B, C, D が出てくる → B を掘ると E が出てくる → E を掘ると…

ここで「Aについてまとめて」と素朴に頼むと、会話の出発点Aの一般論しか出てこず、会話の途中で出会った E が落ちる。でも E こそ、ユーザーがこの会話で初めて知った・一番面白かった部分かもしれない。

だから matome は:

1. 会話の連鎖を全部たどって A〜E を候補として拾う
2. ただし拾いすぎると膨らむので、まとめを書く前に「どれを入れるか」をユーザーに選ばせる
3. 選ばれたものを、会話に出てきた順（A→B→…）ではなく、3ヶ月後の自分が読んで自然に理解できる順（例: A→E→D→B→C）に組み直して1枚にする
4. 公開メモなので、社内コード・機密は自動で抽象化する

---

ワークフロー

Step 1: 主題を確定する

引数（/matome 〇〇についてまとめて の「〇〇」）が、まとめの主題になる。引数がなければ「この会話全体で一番の収穫は何だったか」を主題として置き、ユーザーに一言確認する。

主題は「まとめのタイトルになる中心テーマ」であって、含める範囲の制約ではない。主題から芋づるでつながった話題は、主題と違うキーワードでも候補に入れる。

Step 2: 会話ログから話題を抽出する（芋づるをたどる）

今のセッションのこれまでの会話全体を見渡し、主題から連なる話題・キーワードを洗い出す。単語の出現を拾うのではなく、話の連鎖をたどること:

• 主題 A から、会話の中で派生して出てきた話題（B, C, D…）
• さらにそこから掘り下げて出てきた話題（E…）
• それらの間の依存関係（Eを理解するにはBの理解が要る、など）

抽出したら、各キーワードを「ユーザーにとっての新規性」で仕分けする。これが Step 3 の推奨判断になる:

• ★ 新出・深掘り: ユーザーが質問して初めて出てきた、または何度も掘り下げた話題。ユーザーが「なるほど」「知らなかった」と反応したもの。→ 含める推奨
• △ 軽く触れた: 会話に出たが、さらっと流れた話題。→ 任意
• 既知・前提: ユーザーが既に知っている前提で話していたもの。会話の地の文・足場。→ 除外推奨
• 脱線・運用: 本筋から外れた雑談、ツールの操作手順など。→ 除外推奨

なぜ新規性で測るか: このメモは「ユーザーが今回学んだことの記録」だから。ユーザーが元々知っていたことまで全部入れると、メモが教科書的に膨らみ、後で読み返したときに「自分が何を新しく得たか」が埋もれる。

Step 3: 含めるキーワードをユーザーに選ばせる ★対話ポイント

抽出したキーワードを、仕分け結果つきで一覧提示する。フォーマット例:

この会話から拾った話題です。まとめに含めるものを選んでください。

含める推奨（この会話で深掘りした / 新しく出てきた）:
  1. ★ A（主題）
  2. ★ E ── Bを掘った先で出てきた。今回の一番の収穫っぽい
  3. ★ D

任意（軽く触れた）:
  4. △ B
  5. △ C

除外推奨（既知 / 脱線）:
  6. F（最初から前提にしていた）
  7. G（ツールの操作の話）

「1,2,3,4 でいい」「5も足して」「Cは要らない」のように教えてください。
このままでよければ「OK」。

• デフォルト（ユーザーが「OK」やそれに類する返事をした場合）は ★ の含める推奨を採用する。
• 候補が4〜5個と少なく選択肢が明確なら、AskUserQuestion（multiSelect）でチェックボックス的に選ばせてもよい。多い場合は上記のテキスト一覧のほうが見やすい。
• このステップを飛ばしてまとめを書き始めないこと。 キーワードの取捨選択がこのスキルの肝。

Step 4: 抽象化（社内コード・機密の除去）

選ばれたキーワードについてまとめを書く際、公開しても問題ない形に自動で変換する:

• 社内固有名詞（社名・プロダクト名・社内システム名・チーム名・人名）→ 一般化する。例: 「自社ATSの求人テーブル」→「あるSaaSのデータモデル」
• 実コード・実スキーマ・実データ → 構造や考え方は残し、中身を一般的な例に置き換える。「具体例はあったほうがよいが、本物の社内コードは載せない」を徹底する。
• 社内固有の事情・数値 → 一般論として言い換えるか、ぼかす。

判断に迷う固有名詞は、安全側（抽象化する）に倒す。まとめの末尾に「抽象化/除外したもの」を数行で注記し、ユーザーが安心して公開できるようにする(Step 5の末尾参照)。

毎回いちいち確認はしない。テンポを優先し、自動で抽象化して最後にまとめて報告する方針。

Step 5: 順序を再構成して1枚にまとめる

選ばれたキーワードを、会話の登場順ではなく、読んで理解しやすい順に組み直す。並べ替えの基準:

• 依存順: 前提となる概念を先に。Eの理解にBが要るならB→Eの順（会話ではE→Bの順に出ていても入れ替える）。
• 読み物としての自然さ: 3ヶ月後の自分が、前提知識ゼロで頭から読んで詰まらないか。
• 必ずしも主題Aが冒頭とは限らない。導入として別の話題から入ったほうが分かりやすいならそうする。

出力フォーマット

チャットにmarkdownで返す（ファイルは作らない）。箇条書きの羅列ではなく、地の文で説明する読み物にすること。これが一番大事。

各セクションは「見出し → まず数文の地の文で説明 → 必要に応じてコード例・図・表・箇条書きで補強」という流れで書く。骨子:

# {主題のタイトル}

> {この1枚が何の話か、1〜2行の要約。3ヶ月後の自分への道しるべ}

## {概念1とは何か}

{まず主語・述語のある文章で説明する。「Xとは〜です」「なぜなら〜」と、読んで流れる地の文。}

{構造を見せたいならツリー図やコードブロック、対比なら表を挟む}

```nix
# 使い方が伝わる短いコード例（抽象化済み）
```

## なぜ{概念2}が要るのか

{問いを見出しにすると読みやすい。理由・背景を文章で残す ── 3ヶ月後の自分は「結論」より「なぜそうなるか」を忘れている}

## まとめ

- {全体を数項目に圧縮した要点}

---
※ 公開用に抽象化: {社名X→「あるSaaS」、実コード→一般化した例、など。なければこの行は省く}

文体ルール（イマイチな出力を避けるための肝）:

• 地の文で書く。説明を箇条書きに刻まない。 各概念にはまず文章で説明を置き、箇条書き・コード・図はその補助。電報体（体言止めの断片の羅列）にしない。
• 箇条書きは向いている場面だけに使う ── 要点の列挙、対比、手順。説明そのものを箇条書きで分解すると、今回ダメ出しされた「細切れ」な見た目になる。
• コード例・擬似コード・ASCII図・表を積極的に使う。 概念の構造は図や表で、使い方はコードで見せる。会話で出たコードは抽象化したうえで活かす。
• セクションを細かく切りすぎない。 意味的なまとまりで区切る。数行のセクションを乱立させない。「〜とは何か」「なぜ〜か」と問いを見出しにすると流れができる。
• このセッション単体で読めるようにする。 「前回の話」「さっき出た」のような他の文脈への参照を残さない。必要なら前提もこの1枚に書く。
• 一般論の水増しをしない。この会話で出たことに絞る。会話で触れていない補足を足したくなったら、足す前に一言ことわる。

Step 6: 確認

まとめを返したあと、「含めたい話題が抜けていないか」「抽象化しすぎて意味が通らない箇所はないか」を一言確認する。修正依頼があれば反映する。

---

やってはいけないこと

• 主題の一般論を一から書くこと。それは concept-researcher の仕事。matome は「この会話で得たこと」に閉じる。
• キーワード選択（Step 3）を飛ばすこと。膨らみ防止の要。
• 会話の登場順そのままで並べること。理解しやすい順に組み直す。
• 社内固有名詞・実コードをそのまま載せること。公開メモなので厳禁。

入出力の例（イメージ）

Input: TypeScriptの型の絞り込みについて聞き、会話の中で discriminated union → never型による網羅性チェック → satisfies 演算子、と話が広がったセッションで /matome 型の絞り込みについてまとめて

Step 3で提示: 「絞り込み(★主題) / 網羅性チェック(★深掘りした) / satisfies(★新しく出た) / discriminated union(△) / そもそもの型注釈(既知・除外推奨)」

Output: 「型の絞り込み」を主題に、discriminated union（前提）→ 絞り込み → never による網羅性チェック → satisfies の順（＝理解しやすい依存順）で再構成した1枚。社内のコード例は出さず、一般的なミニ例で説明。