change-quiz

変更内容クイズ

長いセッションの後では、エージェントがユーザーの認識以上の変更を加えていることがよくあります。差分で見えるのは表面だけです。変更の挙動は、既存のコードパスとどう連携するかによって決まります。ユーザーがマージするのは、クイズに答えられる変更だけにしてください。

手順

1. まず、レポートを4つの短いセクションにまとめます。
   • コンテキスト — このセッションで解決しようとした問題。
   • 変更内容 — ファイルごとではなく、意図（機能追加、修正、リファクタリング）ごとにまとめます。
   • 連携の仕組み — 変更が関わる既存のコードパスと、差分に表示されないファイルでも挙動がどう変わるか。
   • 直感 — ユーザーが身につけるべき2～3個のメンタルモデルの更新（「Xなので、リトライは冪等になった」など）。
2. 長いセッションでは、クイズを末尾に置いた、単独で完結するHTMLページとしてレポートを提示します。Markdownが延々と続くより読みやすくなります。
3. 続いてクイズを出します。認識不足のメンテナーがつまずきそうな点を狙った質問を5～8問用意します。
   • 想起問題（「デプロイ時に処理中のジョブはどうなりますか？」）と予測問題（「古いトークンを使って誰かがXを呼び出した場合、何が表示されますか？」）を組み合わせます。
   • 名前の知識ではなく、従来との違い、エッジケース、相互作用に重点を置きます。
4. 1回ずつ、正直に採点します。間違いがあれば、正解を説明したうえで、その間違いがユーザーの理解不足を示すのか、変更が複雑すぎることを示すのかを明確にします。
5. 合格ならマージ可能です。不合格なら、読み直すべきレポートの具体的なセクションを示し、新しいバリエーションのクイズを出します。基準を甘くしないでください。読まれていない変更を出荷しないことが、すべての目的です。

ガードレール

• クイズでは、一般知識ではなく、変更内容とその波及範囲を扱います。
• 2回挑戦しても合格できない場合は、クイズを続けるのではなく、変更を簡素化するか分割するよう勧めます。
• 礼儀として正解扱いしてはいけません。誤った合格判定は、このスキルの目的を損ないます。