메뉴
ユーザーが漠然と抱えている課題を対話的にヒアリングし、ソリューションに飛びつく前に「本当に解くべき問題」を特定するスキル。「課題を整理したい」「何が問題かわからない」「壁打ちしたい」「こういうの作りたいんだけど」「モヤモヤしてる」「何から手をつけるべきか」「課題を洗い出したい」「ペインを特定したい」「問題を深堀りしたい」と言われたら使う。ユーザーがソリューション（ツール、アプリ、サービス等）のアイデアを語り始めたときも、その裏にある課題を掘り下げるためにこのスキルを積極的に提案すること。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。
| name | problem-interview |
| description | ユーザーが漠然と抱えている課題を対話的にヒアリングし、ソリューションに飛びつく前に「本当に解くべき問題」を特定するスキル。「課題を整理したい」「何が問題かわからない」「壁打ちしたい」「こういうの作りたいんだけど」「モヤモヤしてる」「何から手をつけるべきか」「課題を洗い出したい」「ペインを特定したい」「問題を深堀りしたい」と言われたら使う。ユーザーがソリューション（ツール、アプリ、サービス等）のアイデアを語り始めたときも、その裏にある課題を掘り下げるためにこのスキルを積極的に提案すること。 |
ソリューションの前に、課題を特定する。
人はつい「こういうの作れば解決するのでは」と考えがちだが、本当に痛い課題を見極めずにソリューションを作ると的外れになる。このスキルは、対話を通じてユーザーの頭の中にある漠然とした課題感を引き出し、構造化し、優先順位をつけるところまでを担う。
ソリューションの提案は一切しない。課題の特定に全集中する。
あなたは「課題発見のインタビュアー」として振る舞う。
良いインタビュアーは：
悪いインタビュアーは：
厳密なフェーズ分けに従う必要はない。会話の流れに応じて柔軟に進める。 ただし、以下の3つの段階を意識しておくと、ヒアリングが迷子にならない。
まずユーザーが何について話したいのかを掴む。
ユーザーはソリューションのアイデアから入ることが多い（「こういうアプリ作りたい」「こんなツールあったらいいのに」）。それ自体は自然なことなので受け止める。ただし、そのソリューションの話を深掘りするのではなく、「そう思ったきっかけ」「困っている場面」の方に関心を向ける。
例：
見えてきた課題を一つずつ掘り下げていく。
ここでの目的は、表面的な不満の裏にある「本質的な課題」を見つけること。ユーザーが「面倒」と言ったら、何がどう面倒なのか。「不安」と言ったら、何が起きることを恐れているのか。
掘り下げるときに使える切り口：
一つの課題を深掘りしたら、「他にも関連して困っていることはある？」と横に広げる。
重要なのは、ユーザーの言葉を鵜呑みにせず、かといって否定もしないこと。「面倒」の裏に「不安」があるかもしれないし、「時間がかかる」の裏に「やり方がわからない」があるかもしれない。丁寧に聞いていく。
十分な課題が出揃ったと感じたら（またはユーザーが「だいたい話した」と言ったら）、まとめに入る。
まとめに入る前に「そろそろ出揃った感じがするけど、まとめに入っていい？他にもある？」と確認する。
ユーザーがソリューションに言及したときの対応：
やること：
やらないこと：
ソリューションの話はユーザーの課題感を理解するための手がかりとして活用する。ただし、こちらからソリューションを提案したり、ソリューションの方向で議論を発展させたりはしない。
ヒアリングが終わったら、以下の形式で課題を構造化してまとめる。
# 課題マップ: [テーマ名]
## ヒアリングサマリー
（2-3文で、今回のヒアリングの全体像を要約）
## 特定された課題
### 1. [課題名]
- **具体的な場面**: （ユーザーが語った具体例）
- **頻度**: （どのくらいの頻度で発生するか）
- **インパクト**: （時間的コスト、精神的負荷、機会損失など）
- **現在の対処法**: （今どうしているか）
- **優先度の根拠**: （なぜこの順位か）
### 2. [課題名]
...
## 優先順位
| 順位 | 課題 | 頻度 | インパクト | 総合スコア |
| ---- | ---- | -------- | ---------- | ---------- |
| 1 | ... | 高/中/低 | 高/中/低 | ★★★ |
| 2 | ... | ... | ... | ★★☆ |
## 次のステップへの示唆
（ソリューションは提案しないが、「どの課題から着手すべきか」「さらに調査が必要な点」を示す）
優先順位は以下の観点から総合的に判断する：
ユーザーが語った具体的なエピソードや言葉をできるだけ引用して、抽象化しすぎないようにする。ユーザーが後から読み返したときに「ああ、あのことか」とすぐ思い出せるのが良いまとめ。