readback

作業を始める前に、指示を自分の言葉で言い換え、文脈と照らし合わせて確認します。

目標

誤読した指示に基づいて作業を始める前に、読み違いを見つけます。依頼者の意図する意味を、現在のメッセージ、セッション履歴、プロジェクトの記憶、ディスク上のファイル、確立された慣習と照らし合わせて確認します。文脈から解釈が定まる場合は、質問せずに作業を進めます。複数の解釈が残る場合は、どちらを選ぶかについて具体的な質問を一つだけ依頼者にします。

ワークフロー

1. 兆候を認識します。長い指示や複数の要素を含む指示、対象範囲や指示対象の曖昧さ、意図的に幅を持たせた表現、または誤った推測が実作業につながるほど重要度の高い指示（取り消しにくい作業も含みます）が該当します。
2. 指示を自分の言葉で言い換えます。ユーザーの言葉をそのまま写すだけでは、理解したことにはなりません。
3. その言い換えを、利用可能な文脈（メッセージ、セッション履歴、プロジェクトの記憶、ディスク上のファイル、目標で挙げた慣習）と照らし合わせ、矛盾、先行する指示対象の欠落、または文脈だけでは絞り込めない複数の妥当な解釈がないか確認します。
4. 文脈から解釈が定まる場合は、何も言わずに進めます。文脈によってすでに答えが出ていることについて、依頼者に確認を求めてはいけません。
5. 複数の解釈が残る場合は、言い換えた理解に基づき、選択肢を明示した具体的な確認質問を一つだけします。「これでよいですか？」のような曖昧な質問はしません。依頼者が決めるまで、作業の形を大きく変える作業には着手しません。
6. 本格的な作業に入る前に、確認済みの解釈を記した、understood as: で始まる永続的な行を一つ残します。作業用のプランまたはタスクファイルがすでにある場合はそこに記録し、ない場合は作業を納品するコミットメッセージまたはプルリクエスト本文に記載します。

ルール

• 言い換えは、指示のモデルを組み立てたことを示します。原文の繰り返しでは、ほとんど何も示せません。
• 文脈から解決できる依頼や曖昧でない依頼について確認を求めるのは不備です。何も言わずに進めます。
• 曖昧さは一度に一つだけ、重要度の高いものから確認します。曖昧さのチェックリストを提示してはいけません。
• 作業の形を変える解釈の分岐を、確認せずに黙って決めてはいけません。
• 永続的な解釈記録は、プラン、複数ファイルにわたる変更、取り消せない操作、または新たにレビューする人が監査する必要のある作業について残します。すべてのやり取りについて残す必要はありません。このようなケースに該当する場合、何も言わずに確認を通過した場合でも記録します。
• 関連する別スキルとの境界：readback は意図を確認し、factchk は世界に関する主張が真実かどうかを検証します。関連する別スキルは境界として言及するものであり、呼び出してはいけません。このスキルは他のスキルを呼び出しません。

検証

作業に進む前に、次の点を確認します。

• 言い換えになっていること。
• 確認した解釈の分岐が、利用可能な文脈では本当に解決できないこと。
• 何も言わずに確認を通過するか、解釈の分岐が解決するまでは、本格的な作業を始めていないこと。