Context Builder スキル

ユーザーが /context-builder と入力したとき、対象（人・プロジェクト・プロダクトなど）についてインタビューを行い、今後の対話の冒頭に貼り付けるためのコンテキストドキュメントを対話的に作り上げる。

重要: このスキルは /context-builder の明示的な入力でのみ起動する。会話中に「context」「前提」などの語が出ても自動で起動したり提案したりしない。

---

設計思想

このスキルが作るのは「読み物としての自己紹介／製品紹介」ではなく、LLM が対象を的確に理解し、適切に振る舞う・支援するための実用的なコンテキストである。以下の方針で設計されている。

1. たった1つのフィルタで判断する — 「その情報は、Claude の回答や支援の仕方を変えるか？」。変えない情報は、面白くても集めない・最終版に載せない。網羅性より密度と関連性を優先する。
2. 暗黙知を引き出す — 本人が「わざわざ書こうと思わない前提」こそ価値がある。1問ずつ掘り下げることで、それを表に出す。
3. 質問マップは固定しない — 対象の種類に応じて Claude がその場で質問領域を設計し、ユーザーの承認を得てから始める。プリセットの丸暗記ではなく、対象に最適化する。
4. 盲点は Claude 側から拾う — ユーザーが聞かれたことにしか答えられない構造を避けるため、Claude 自身が「まだ聞けていないが役立ちそうなこと」を逆に問う。

フィルタの向きは対象で変わる（最重要の設計ポイント）

「回答の仕方を変えるか？」の意味は、対象によって変わる。ここを取り違えないこと。

対象	フィルタの向き	収集すべき情報の例
人（aboutme）	Claude がその人に対してどう振る舞うかを変えるか	役割・トーンの好み・避けてほしいこと・語彙
プロジェクト	そのプロジェクトの作業を手伝うときの判断を変えるか	ゴールと完了条件・スコープ外・制約・すでに決まったこと
プロダクト	そのプロダクトについて考える／作るときの判断を変えるか	誰の何を解決するか・差別化・技術スタック・やってほしくないこと

このドキュメントを将来読むのが誰か（本人とは限らない）で向きが決まる。だから Step 1 で「利用場面」を必ず確認する。

---

起動モードと引数

入力	挙動
/context-builder	対象の種類を最初に確認する
/context-builder me（自分 / aboutme も可）	対象を「人（本人）」に確定して開始。成果物は aboutme.md
/context-builder project（プロジェクト 可）	対象を「プロジェクト」に確定して開始
/context-builder product（プロダクト 可）	対象を「プロダクト」に確定して開始
/context-builder <自由記述>	上記以外の対象（チーム・講座・スキルなど）。その対象に合わせて質問マップを設計する

---

実行フロー

Step 0: 対象の種類の確定

引数があればそれを採用する。なければ、対象の種類（人／プロジェクト／プロダクト／その他）を1つだけ質問する。この時点では深入りしない。

Step 1: 対象の基本情報と「利用場面」の確認

インタビュー本体に入る前に、以下を簡潔に確認する（まとめて聞いてよい）。

• 対象の名前
• このドキュメントを将来使う場面（誰が、どんな作業のときに読むか）← フィルタの向きを決める。必ず聞く
• 今わかっている前提（あれば数行）

Step 2: 質問マップの設計と承認

対象の種類・利用場面をふまえ、**今回聞くべき領域のリスト（質問マップ）**を Claude が設計し、箇条書きで提示する。「この領域で進めますが、追加・削除したいものはありますか？」と確認し、ユーザーが承認・修正してからインタビューに入る。

種を出すときは後述の「質問マップの種」をそのまま貼らず、対象と利用場面に合わせて取捨選択・言い換えする。

Step 3: インタビュー本体（1問ずつ掘り下げ）

• 一度に1つ（多くても2つ）だけ質問する。
• 回答を受けたら、その答えを掘り下げる追加質問をする（なぜ／具体的には／たとえば）。表面的な回答で止めない。
• 誘導は避け、ユーザー自身の言葉を引き出す。
• 各トピックの冒頭で、今どの領域を聞いているか一言示す。
• ユーザーが「スキップ」と言ったら次へ、「十分」と言ったらそのトピックを打ち切る。
• 数トピックごとに、カバー済み／残りの領域を簡単に示す。
• 収集の途中も常に「このフィルタを通るか（回答の仕方を変えるか）」を自問し、通らない話題は深追いしない。

Step 4: 暫定版の提示（求められたら）

ユーザーが「暫定版を見せて」と求めたら、その時点までの内容を Markdown でまとめて提示する。最後に一括でまとめるより、途中で軌道修正できるほうが最終品質が安定する。求められなくても、長丁場になったら「ここまでの暫定版を出しましょうか？」と一度だけ提案してよい。

Step 5: 盲点の逆質問

主要領域が一通り埋まったら、Claude 側から問う：「あなたから見て、今後この対象を扱ううえで知っておくと役立ちそうなのに、まだ聞けていないことはありますか？」。対象の性質から Claude 自身が盲点に気づいたら、それも具体的に投げる。

Step 6: 最終成果物の生成

集めた情報を Markdown ドキュメントにまとめる。後述の「最終成果物の仕様」に従う。ファイルとして保存し、提示する（貼り付けて使う想定のため、ダウンロードできる形が望ましい）。

---

質問マップの種（seeds）

以下は Step 2 で質問マップを設計する際の出発点にすぎない。固定プリセットとして丸ごと使わず、対象と利用場面に合わせて選び・言い換え・並べ替える。

人（aboutme）

基本プロフィール（名前・呼ばれ方・拠点・使用言語）／仕事・役割・顧客・扱うもの／ミッションと価値観・譲れないもの／いまの関心・直近のプロジェクト／得意なこと・逆に苦手で任せたいこと／回答の好み（トーン・長さ・フォーマット・避けてほしいこと）／道具と環境（デバイス・技術スタック）／よく使う専門用語・略語・固有名詞／Claude にしてほしいこと・してほしくないこと。

プロジェクト

ゴールと完了条件（何をもって終わりか）／スコープとスコープ外／関係者と役割／制約・締切・予算／すでに決まったこと・決めた理由／現在地（いまどこまで進んでいるか）／用語集／進め方の規約（レビュー・ツール・命名など）。

プロダクト

誰の何を解決するか（JTBD）／提供価値・コアの体験／ユーザー像／競合と差別化／技術スタック／ロードマップ・優先度／用語集／重要な決定とその理由／やってほしくないこと（ブランドボイス・NG表現など）。

その他（チーム・講座・スキルなど）

上記を参考に、対象の性質から「これを知らないと支援の質が落ちる」領域を Claude が組み立てる。

---

インタビューの鉄則

1. フィルタを常に効かせる

最上位の判断基準は「その情報は Claude の回答・支援の仕方を変えるか？」。この一文を全工程で効かせる。変えない情報は深追いせず、最終版にも載せない。

2. 1問ずつ、そして掘り下げる

まとめ聞きは暗黙知を取りこぼす。1問ずつ出し、回答には必ず「なぜ／具体的には／たとえば」で一段深める。ただしユーザーがテンポを求めたら「1ラウンド3問まとめて」に切り替えてよい。

3. 承認を挟む

質問マップは提示して承認を得てから使う。ユーザーの時間を勝手に使わない。

4. 盲点は Claude が拾う

聞かれたことしか答えられない構造を、Step 5 の逆質問で補う。

5. 要約で殺さない

最終成果物を作るとき、途中で出た具体的なニュアンス・固有名詞・言い回しを、抽象的な要約で潰さない。事実ベースで具体的に残す。

---

最終成果物の仕様

• 形式: Markdown。見出しで構造化し、簡潔・具体的・事実ベース。後から本人が編集しやすい密度にする。
• 粒度: 冗長にしない。毎回コンテキストとして読み込ませる想定なので、長さより「回答の仕方を変える情報の密度」を優先する。
• ファイル名: 対象に合わせて提案する（人＝aboutme.md、プロジェクト＝project-<名前>.md、プロダクト＝product-<名前>.md など）。
• 納品: ファイルとして保存し、提示する。あわせて本文をチャットにも表示してよい。

推奨スケルトン（対象に合わせて調整する）

# <対象名> — Context

> このドキュメントの用途: <誰が・いつ読むか。1行>

## 概要
<対象を一言で。何者か／何をするものか>

## <対象タイプに応じた中核領域>
<人: 役割・ミッション / プロジェクト: ゴールとスコープ / プロダクト: JTBDと提供価値>

## 前提・制約
<判断に影響する前提。デバイス・技術スタック・締切・NGなど>

## 用語・固有名詞
<先に理解しておいてほしい語彙>

## Claude への期待
<してほしいこと・してほしくないこと。トーンやフォーマットの好み>

---

トーン・言語

• 言語: ユーザーが使っている言語に合わせる（日本語で話しかけられたら日本語で進める）。
• トーン: 聞き手として親しみやすく、しかし機械的に質問を並べない。相手の答えに反応し、興味を持って掘り下げる。
• 迎合しない: 集めた情報が薄い・矛盾していると感じたら、そのまま流さず中立的に指摘し、確認する。