thinking-out-loud

考えを声に出す

10分間、思いつくままに話すだけで、人が入力するどんなプロンプトよりも多くのコンテキストが伝わり、モデルはそのような話をうまく再構成できます。失敗はその後に起こり、しかも目に見えません。モデルは話のあらゆる隙間を、自信たっぷりに埋めてしまいます。「いつものモデル」が、いつの間にか特定のモデルを指すことになります。「標準サイズ」が、特定のビューポートを指すことになります。話の途中でユーザーが撤回した立場が、事実として残ってしまいます。こうしたことは、内側からは不確かさとして認識されないため、確認の質問にもなりません。モデルは完全に正しいと信じ込んだ誤読に基づいて行動し、ユーザーは生成された成果物ができてから1時間後にそれを発見します。

このスキルは、その問題を解決します。思いつくままに話した内容に基づいて行動する前に、エコーを作成します。エコーとは、取り込んだ内容をすべて短く構造化して点検するもので、モデル自身が付け加えた内容はユーザーの言葉から分けて扱います。ユーザーは、完成した成果物のデバッグをする代わりに、3行を修正するだけで済みます。

追加の質問ではなく、エコーを使う理由

確認の質問をするのは有効で、以下の聞き取りでも行います。しかし、質問だけでは、思いつくままに話した内容を確実に捉えることはできません。構造上、理由は2つあります。

• 質問で確かめるのは、モデルが疑っていることです。エコーで確かめるのは、モデルが信じていることです。 確認の質問には、本人が感じる不確かさが必要です。自信に満ちた誤読は、知識のように感じられます。エコーは、不確かだと感じたかどうかにかかわらず、すべての推論や補完を明らかにします。
• 質問は一部を確かめ、エコーは全体を点検します。 長い話には、数十もの事実や、決めかけの事柄が含まれます。適切な質問でも掘り下げられるのは3、4点ほどで、モデルが理解した残りは、確認されないまま行動に反映されます。エコーは、伝わった内容全体を一覧にします。また、思い出して答えるのではなく、見て認識する形で機能します。ユーザーは内容を読んで間違いを見つけるだけでよく、答えを考えて出すよりずっと簡単です。思いつくままに話す人は、間違った推測が文章になって初めて、自分の答えに気づくこともよくあります。

基本方針

1. 何にも着手しません。 エコーが承認されるまでは、ファイルの編集も、コードの作成も、計画も、断片的な内容への解決策の提示もしません。まず再構成します。
2. 追加した内容にはすべてラベルを付けます。 推論や推測は専用のセクションに記載し、ユーザー自身の内容とは分けます。推測をユーザーの言葉として提示してはいけません。
3. 立場の撤回はすべて明示します。 後の立場を採用しますが、変更があったことも示します。黙って中間を取ったり、どちらかを選んだりしてはいけません。
4. 何も失いません。 脱線した内容は削除せず、別に残します。
5. 音声入力の乱れには決して言及しません。 文脈から、誤字、同音異義語、つなぎ言葉、言い直しを黙って解決します。ユーザー独自の語彙やプロジェクト名はそのまま保ちます。
6. 保存する前に確認します。 承認された概要の保存先は提案しますが、確認なしに保存してはいけません。

使用する場合

• 途切れやつなぎ言葉、話の途中での撤回（「やっぱり違う、それはなしで」）を含む、長く句読点の少ない思考の流れのようなメッセージ
• 音声入力を使っていることを前置きするメッセージ（「音声認識に切り替えます。誤字があったらすみません」「音声入力です」など）
• 思いつくままに話したい、または考えを声に出して整理したいとユーザーが述べている場合
• あいまいな考えを整理するため、聞き取りをしてほしいとユーザーが求めている場合

使用しない場合

• すでに明確な短い依頼
• ユーザーが逐語的な書き起こし、議事録、または正確な言葉を保ったまま音声入力を整えることを求めている場合
• 貼り付けられた仕様書や文書など、すでに構造化された長文
• ユーザーが直接的な質問をしていて、直接的な回答を求めている場合

エコー

構造化された返信を1つ返します。情報密度が高く、ざっと読みやすい、短い形式です。ユーザーが数秒でエラーを見つけて修正できるようにします。記入例付きの完全なテンプレートは references/echo-format.mdにあります。

1. 目的：ユーザーが実際に達成しようとしていることを1文で示します。多くの場合、最初にユーザーが話した内容とは異なりますが、問題ありません。
2. 確定事項：ユーザーの決定事項と制約を1つのリストにまとめます。最優先事項として挙げられたものには印を付けます。
3. 未解決事項：話が広がる中で浮かんだものの、答えが出ていない質問です。
4. 記録：変更（両方の立場を1行にまとめ、後の立場を採用）と、保留した脱線事項（それぞれ1行）を記します。
5. こちらからの追加事項：解釈に関する指摘はここだけに記します。「推測」（強く示唆されているものの、明言はされていない事項）と「仮定」（不足を補った事項）です。まずこれらを修正するようユーザーに伝えます。

圧縮ルール。必ず守ってください。

• 同じ内容を2回書きません。 すべての事実は、いずれか1つのセクションだけに記載します。
• 「あなたが言ったこと」の振り返りはしません。 「こちらからの追加事項」以外はすべて、定義上、ユーザー自身の内容です。明示するのはモデルが追加した内容だけです。
• 箇条書きは1項目につき1行です。 2行必要な項目は、2つに分けるか、冗長な部分を削ります。
• 曖昧な量や時期を、明示せずに確定してはいけません。 「いつものモデル」「標準サイズ」「すぐ」などは、確定事項に指定済みであるかのように含めず、未解決事項または仮定に記載します。

最後に、訂正を促し、インタビューもできると伝えます。

インタビュー（任意）

フォローアップ質問は、監査の後に行うものであり、監査の代わりではありません。ユーザーが提案を受け入れた場合、または最初からインタビューを求めた場合に限り行います。

• 「未解決事項」または「仮定」に挙げた項目だけを質問します。
• 1回のメッセージにつき質問は1つとし、最も多くの情報が得られる質問から行います。
• 各質問では、重要である理由を1つの節で述べます。
• 質問は最大5つまでとし、回答によって概要が変わらなくなった時点で終了します。
• インタビュー後は、変更があったエコーのセクションだけを改めて提示します。

キャプチャモード（複数メッセージにわたる話）

話の内容が1つのメッセージで届くディクテーションツールでは不要です。ユーザーが話し始める前にこのスキルを呼び出し、その後、長時間にわたって複数のメッセージで考えを追加していく場合に使います。

• 短い一言で一度だけ応答します（「どうぞ、聞いています。エコーを返してほしいときは「完了」と言ってください。」）。
• その後のすべてのメッセージには、最小限の一言だけで返答します（「聞いています。」）。機械的な印象にならないよう、少し変化をつけます。
• 途中で問題を解決したり、褒めたり、要約したり、分析したり、質問したりしてはいけません。
• 話の途中で直接質問された場合は、2文以内で答えてから、再び聞き役に戻ります。
• 「完了」「エコー」「エコーして」「以上です」「どう理解しましたか」など、明確に同等の表現を受け取ったら終了し、エコーを提示します。

永続化

ユーザーがエコーを承認した後、次の3つの選択肢を必ず提示します。

1. 今後のセッションにも引き継がれるよう、概要をCLAUDE.mdに追記する
2. 概要をdocs/rambles/YYYY-MM-DD-<topic>.mdに保存する
3. この会話内だけで使う

承認された概要は、その後のセッション全体に適用します。決定事項と制約を守り、再度質問しないでください。