메뉴
コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。
課題やソリューションがある程度見えてきたところに、ジョブ理論（Jobs to be Done）のレンズをかぶせて 再整理し、抜けがちな観点（状況／3側面の社会・感情面／無消費を含む競合の広さ／4つの力／ リトル・ハイア／ジョブスペック）を指摘するスキル。ジョブスペック作成の伴走もする。 「ジョブ視点で見直して」「ジョブ理論で再整理」「ジョブスペック作りたい」 「JTBDで」「これ顧客のジョブで言うと？」と言われたら使う。 ユーザーが「課題→ソリューション」の直線的な発想に閉じているとき（「〜の課題があるから〜を作る」）に、 ジョブ視点を補強するために積極的に使うこと。 対象ドメインはプロダクト戦略・新規事業・既存サービスの再定義。 `hypothesis-sharpener`（仮説の鋭さ）や `problem-interview`（課題の特定）と並ぶ、 顧客理解レイヤーのコーチ／添削スキル。
SOC 직업 분류 기준
| name | explain-diff |
| description | コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。 |
| argument-hint | [diff / ブランチ名 / PR番号など解説対象] |
| ref | https://gist.github.com/geoffreylitt/a29df1b5f9865506e8952488eac3d524 |
指定されたコード変更について、リッチでインタラクティブな解説を作る。
以下のセクションを含めること:
Background（背景）: この変更に関連する既存システムを説明する。（そのために周辺コードを広く探索すること。）読者がどれだけ知っているか分からないので、初学者向けの深い背景を含めた上で（既に詳しい読者はスキップできる旨を明記）、続けて変更に直結する狭い背景を説明する。ただし「前提知識のレベル合わせ」でスキルが既知と判断した／ユーザーが既知と答えたキーワードは深掘りを省き、未知のものに紙面を割く。
Intuition（直感）: コード変更のコアな直感を説明する。ここでのフォーカスは細部ではなく本質を伝えること。トイデータを使った具体例を用いる。図やダイアグラムを積極的に使う。
Code（コード）: コードへの変更点を高レベルにウォークスルーする。変更を理解しやすい形にグループ化・順序付けする。
Critique（批評）: PRの方向性や実装が正しいことを前提にせず、率直な批評家として問題点を指摘する。ここまでのセクションが「この変更をどう理解するか」だとすれば、ここは「この変更は本当に良いのか」を問うパート。以下の4観点を必ずカバーする（各観点で指摘がなければ「特になし」と明記し、無理に難癖はつけない）:
批判は必ずコード上の具体的な根拠に紐づける。感想や一般論ではなく「この関数のここがこうだから」という形で書く。ただし解説者はPRの背景・議論・制約をすべて知っているわけではないので、断定できない指摘は確信度と前提を明示する（例:「〜という前提が正しければ、これは問題」）。読者が批評を鵜呑みにせず自分で判断できるようにするのが目的。
Quiz（クイズ）: このPRの理解度を測る問題を5問作る。中難度にすること。実際に内容を理解していないと解けない程度に難しく、ただし引っかけ問題にはしない。目的は読者が本当に理解できたかを確認する手助け。インタラクティブな選択式問題として提示し、クリックすると正誤とフィードバックが表示されるようにする。
読者がどこまで知っているか分からないまま書くと、背景説明が厚すぎたり薄すぎたりする。そこで生成の前に、ユーザーがその場にいれば前提知識を軽くすり合わせ、放置していれば待たずにデフォルトで完成させる。この2モードを待機時間で自動的に切り替える。
手順:
AskUserQuestionは、後述のタイマー自動進行と両立しないので使わない。メッセージには「既に知っている番号だけ返してください。5分以内に返答がなければ、前提ありありのデフォルトで生成して完成させます」という主旨を必ず含める。短く、気軽に番号を返すだけで済む形にする。ScheduleWakeup を delaySeconds: 300 でセットしてターンを閉じる。
CSSとJavaScriptを含む単一の自己完結HTMLファイルを出力する。全体を1本の長いページにし、セクション見出しと目次を付ける。トップレベル構造にタブUIは使わない。スマホで見られる程度の基本的なレスポンシブスタイルもあると良い。ファイルは特に指示がなければコードリポジトリの外のグローバルな場所に置き、ファイル名は必ず今日の日付を YYYY-MM-DD- 形式で先頭に付ける（時系列でソートされ、バージョン管理から外れるため）。例: /tmp/2026-01-12-explanation-<slug>.html
Martin Kleppmann のような明快さと流れで書くこと。読ませる文章、古典的なスタイルで。セクション間の遷移はスムーズに。
図についてのヒント。理想的には、解説全体で使い回せる少数の図のファミリーを選び、様々なケースの説明に再利用する。有用な図の種類:
ASCIIアートの図は使わない。図はシンプルなHTMLで作り、リストはHTMLのリストで作る。
<pre> タグを使う。カスタムスタイルの div を使う場合は、CSSに 必ず white-space: pre-wrap を含めること。含めないとブラウザが改行をすべて1行に潰してしまう。ファイルを保存する前に、HTMLソース内の各コードブロックをスキャンし、CSSに white-space: pre または pre-wrap が含まれていることを確認する。重要な概念や定義、重要なエッジケースなどには callout（囲み）を使う。