菜单
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | matome |
| description | 今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。 |
| argument-hint | [トピック]についてまとめて |
今のセッションの会話 log を素材に、ユーザーが学んだことを「個人用の公開メモ」1枚にまとめてチャットに返す。
普通に「〇〇について解説して」と頼むと、Claudeは一般論を一から書く。だがこのスキルが作るのは違う。この会話の中で実際に出てきて、ユーザーにとって新しかったことを、抜け漏れなく1枚に畳み込む。会話で芋づる式にたどり着いた知識ほど、本人にとって価値が高く、後で思い出したいものだからだ。
会話はこう進む:
Aについて聞く → B, C, D が出てくる → B を掘ると E が出てくる → E を掘ると…
ここで「Aについてまとめて」と素朴に頼むと、会話の出発点Aの一般論しか出てこず、会話の途中で出会った E が落ちる。でも E こそ、ユーザーがこの会話で初めて知った・一番面白かった部分かもしれない。
だから matome は:
引数（/matome 〇〇についてまとめて の「〇〇」）が、まとめの主題になる。引数がなければ「この会話全体で一番の収穫は何だったか」を主題として置き、ユーザーに一言確認する。
主題は「まとめのタイトルになる中心テーマ」であって、含める範囲の制約ではない。主題から芋づるでつながった話題は、主題と違うキーワードでも候補に入れる。
今のセッションのこれまでの会話全体を見渡し、主題から連なる話題・キーワードを洗い出す。単語の出現を拾うのではなく、話の連鎖をたどること:
抽出したら、各キーワードを「ユーザーにとっての新規性」で仕分けする。これが Step 3 の推奨判断になる:
なぜ新規性で測るか: このメモは「ユーザーが今回学んだことの記録」だから。ユーザーが元々知っていたことまで全部入れると、メモが教科書的に膨らみ、後で読み返したときに「自分が何を新しく得たか」が埋もれる。
抽出したキーワードを、仕分け結果つきで一覧提示する。フォーマット例:
この会話から拾った話題です。まとめに含めるものを選んでください。
含める推奨（この会話で深掘りした / 新しく出てきた）:
1. ★ A（主題）
2. ★ E ── Bを掘った先で出てきた。今回の一番の収穫っぽい
3. ★ D
任意（軽く触れた）:
4. △ B
5. △ C
除外推奨（既知 / 脱線）:
6. F（最初から前提にしていた）
7. G（ツールの操作の話）
「1,2,3,4 でいい」「5も足して」「Cは要らない」のように教えてください。
このままでよければ「OK」。
AskUserQuestion（multiSelect）でチェックボックス的に選ばせてもよい。多い場合は上記のテキスト一覧のほうが見やすい。選ばれたキーワードについてまとめを書く際、公開しても問題ない形に自動で変換する:
判断に迷う固有名詞は、安全側（抽象化する）に倒す。まとめの末尾に「抽象化/除外したもの」を数行で注記し、ユーザーが安心して公開できるようにする(Step 5の末尾参照)。
毎回いちいち確認はしない。テンポを優先し、自動で抽象化して最後にまとめて報告する方針。
選ばれたキーワードを、会話の登場順ではなく、読んで理解しやすい順に組み直す。並べ替えの基準:
チャットにmarkdownで返す（ファイルは作らない）。箇条書きの羅列ではなく、地の文で説明する読み物にすること。これが一番大事。
各セクションは「見出し → まず数文の地の文で説明 → 必要に応じてコード例・図・表・箇条書きで補強」という流れで書く。骨子:
# {主題のタイトル}
> {この1枚が何の話か、1〜2行の要約。3ヶ月後の自分への道しるべ}
## {概念1とは何か}
{まず主語・述語のある文章で説明する。「Xとは〜です」「なぜなら〜」と、読んで流れる地の文。}
{構造を見せたいならツリー図やコードブロック、対比なら表を挟む}
```nix
# 使い方が伝わる短いコード例（抽象化済み）
```
## なぜ{概念2}が要るのか
{問いを見出しにすると読みやすい。理由・背景を文章で残す ── 3ヶ月後の自分は「結論」より「なぜそうなるか」を忘れている}
## まとめ
- {全体を数項目に圧縮した要点}
---
※ 公開用に抽象化: {社名X→「あるSaaS」、実コード→一般化した例、など。なければこの行は省く}
文体ルール（イマイチな出力を避けるための肝）:
まとめを返したあと、「含めたい話題が抜けていないか」「抽象化しすぎて意味が通らない箇所はないか」を一言確認する。修正依頼があれば反映する。
Input: TypeScriptの型の絞り込みについて聞き、会話の中で discriminated union → never型による網羅性チェック → satisfies 演算子、と話が広がったセッションで /matome 型の絞り込みについてまとめて
Step 3で提示: 「絞り込み(★主題) / 網羅性チェック(★深掘りした) / satisfies(★新しく出た) / discriminated union(△) / そもそもの型注釈(既知・除外推奨)」
Output: 「型の絞り込み」を主題に、discriminated union（前提）→ 絞り込み → never による網羅性チェック → satisfies の順（＝理解しやすい依存順）で再構成した1枚。社内のコード例は出さず、一般的なミニ例で説明。
コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。
課題やソリューションがある程度見えてきたところに、ジョブ理論（Jobs to be Done）のレンズをかぶせて 再整理し、抜けがちな観点（状況／3側面の社会・感情面／無消費を含む競合の広さ／4つの力／ リトル・ハイア／ジョブスペック）を指摘するスキル。ジョブスペック作成の伴走もする。 「ジョブ視点で見直して」「ジョブ理論で再整理」「ジョブスペック作りたい」 「JTBDで」「これ顧客のジョブで言うと？」と言われたら使う。 ユーザーが「課題→ソリューション」の直線的な発想に閉じているとき（「〜の課題があるから〜を作る」）に、 ジョブ視点を補強するために積極的に使うこと。 対象ドメインはプロダクト戦略・新規事業・既存サービスの再定義。 `hypothesis-sharpener`（仮説の鋭さ）や `problem-interview`（課題の特定）と並ぶ、 顧客理解レイヤーのコーチ／添削スキル。