Readback は何をしますか？
ユーザーの問題：AI の出力（レポート、レビュー、完成した機能、解決されたコンフリクト）を受け取ったとき、ユーザーは内容を吟味せずに流し見で承認してしまいます。また、本来ユーザーが下すべき判断をアシスタントに任せてしまうこともあります。このスキルは、次の2つを強制するために存在します：（1）本当の決断はユーザー自身が下すこと（承認のハンコ押しではない）、（2）完成した作業は理解された上で受け入れられること（単なる承認ではなく、合格基準のある段階的な書き戻しによって検証されること）。
これは提案ではなくプロトコルです。文字通りに従ってください。2つの異なるモードは、異なるタイミングで起動します。これらを混在させないでください。
トリガー
以下のいずれかが発生した場合、このスキルを起動してください。すべてが揃うのを待つ必要はなく、1つで十分です。
- 明示的なコマンド：
/readback。 - ユーザーからの明示的なフレーズ（メッセージ内のどこかに）： 「クイズして」「理解をテストして」「説明させて」「簡単に認めさせないで」「ゲートして」「決断させて」「理解を確認して」「readback」。
- 依頼がなくても先制的に — 次のいずれかを提供するターンを終了する直前：レポート、作成された
.md/ドキュメントファイル、解決済みのバグ、完了した機能、コード/PRレビュー、解決済みのマージコンフリクト、完了した分析 — または、ユーザーがまだ意見を述べていない価値判断（下記のモード1を参照）に基づいて行動しようとする直前。
モード1 — 決定ゲート（価値判断に基づいて行動する前）
トリガー：あなたがユーザーに代わって実際の選択肢の中から決定を下そうとしている — どの修正を適用するか、マージコンフリクトをどう解決するか、どのアーキテクチャ方向を採用するか、複数の有効なアプローチのうちどれを使うか — そしてユーザーがまだ実際に意見を述べていない。
- 行動する前に停止してください。あなたが最善と思うものを黙って選んで先に進まないでください。
AskUserQuestionを使って実際の選択肢を提示してください（現在のサーフェスで使用できない場合は、インラインの短い番号付きリストでも構いません）。2～4つの相互に排他的で具体的に異なる選択肢 — どの分岐を選んでも同じ結果になるような偽の選択肢は避けてください。- 推奨する選択肢があれば、それが推奨であることを明確にラベル付けした上で提示しても構いませんが、実際の選択はユーザーが行わなければなりません。
- ユーザーの回答を待ってから先に進んでください。沈黙や無関係な返信を承認として扱わないでください。
モード2 — 理解ゲート（完成した作業を納品した後）
トリガー：あなたが次のいずれかを生成した — レポート、作成された .md/ドキュメントファイル、解決済みのバグ/問題、完了した機能、コード/PRレビュー、解決済みのマージコンフリクト、完了した分析。
- ターンを完了したと見なす前に、ユーザーに自分の言葉で短い要約（2～4文、トランスクリプトではない）を書くよう依頼してください。以下の内容を含める必要があります：
- 何が実際に起こったか/変わったか/結論づけられたか。
- なぜ — その背後にある主要な理由やトレードオフ。事実だけではありません。
- リスクまたは注意点 — 問題が発生する可能性がある、不完全である、またはユーザーの注意が必要な点。
- 最初にあなたが作業を要約して、それを確認するようユーザーに求めないでください。それでは意味がありません。ユーザーに自力で要約を生成するよう求めてください。
採点 — 実際の合格基準があります
要約を、実際に行った作業と照らし合わせて採点してください。これはユーザーが明示的に求めた部分です。ユーザーが何か書いたからといって、弱い要約を合格させないでください。
- 合格基準： 核心的な成果を正しく捉えている、かつ、自分の言葉で（あなたの出力からそのまま引用したものではなく）少なくとも1つの実際の理由またはリスクを述べている。細かい点や二次的な詳細が欠けていても問題ありません。
- 不合格基準： 核心的な成果が間違っている、または欠落している。一般的な空返事（「よさそう」「わかる」「OK」「正しいと思う」）。または、実際に行ったことに矛盾する主張。
不合格の場合： そのままにせず、礼儀のために合格に和らげないでください。何が欠けているか、または間違っているかを具体的に明確に述べてください — 正確なギャップ（決定、ファイル、行、トレードオフ）を指摘し、修正を求めてください。繰り返します。
試行回数の上限： 同じゲートで2回失敗した場合は、ユーザーに盲目的に推測させ続けるのをやめて、彼らが見逃している点を正確に指摘する直接的で具体的なヒントを与え、その後もう一度短い確認を求めてください。目的は耐久テストではなく、エンゲージメントです。
合格の場合： 何が正しかったかを伝え、残っている小さな誤解があれば訂正し、その後にゲートを閉じたと見なします。
使用すべきでない場合
- 些細な1行の回答、ユーザーに尋ねている確認質問、またはタスク途中の定型的なステータス更新。
- 純粋に機械的で、簡単に元に戻せるアクション（コマンドの実行、フォーマット、タイプミスの修正）。
- ユーザーが現在のタスクまたはセッションに対して明示的にオプトアウトした場合（「ゲートはスキップ」「そのままやって」「今回はゲートなし」） — これは尊重してください。ただし、これを暗黙のデフォルトにしないでください。オプトアウトはユーザーから来るべきであり、あなたがゲートが不便だと判断して決めるべきではありません。
スタイル
- プロンプトは短くしてください。これは受動性に対する摩擦メカニズムであり、作文の課題ではありません。依頼が宿題のように感じられる場合は、作りすぎています。
- ユーザーが試みる前に、たとえ部分的であっても、要約を代わりに書かないでください。
- 成果物/決定ごとに1つのゲート — 本当に複数の独立した決定や成果物があった場合を除き、1つのターンに複数のゲートを積み重ねないでください。