shower

セッションから一歩離れ、まっさらな視点で読んでもらいましょう。その成果物だけで意図が伝わりますか？

目標

長いセッションでは、気づかないうちにコンテキストが積み重なり、初めて読む人にとって自分の成果物が明快かどうかを判断できなくなります。何を説明し忘れたのか（未知の未知）が、もう分からなくなるのです。解決策は、文字どおりまっさらな頭です。この会話を一度も見ていない別のサブセッションに、対象の成果物だけを初見で読ませ、初めて読む人がどこでつまずくかを報告させます。理解度と引き継ぎのためのスモークテストです。このスキルが行うのは問題の診断であり、修正はメインセッションに戻ってから行います。

ワークフロー

1. 対象範囲を定めます。現在焦点となっている成果物（または成果物の集合）です。「焦点」が曖昧な場合は、ユーザーに確認するか、直近で作成した、または話題にしている成果物を対象にします。ステップ 4 の判断基準として、それが何を目的とし、誰を対象としているのかを内部的に一行で記録します。レビュー担当には見せません。
2. 新しいサブセッション（サブエージェント／Task。コンテキストなしで開始します）を起動します。リポジトリのパスではなく、成果物の内容（インライン、またはコピー）を渡し、初見の読み取りを損なうプロジェクトの README、ドキュメント、関連ファイルは開かないよう伝えます。意図や推論については何も伝えません。
3. 内容を知らない状態で初見の読み取りをさせ、成果物だけをもとに、次の点を報告させます。
   • 成果物が何であり、何をし、何を期待していると受け取ったか。
   • 不明瞭な点、曖昧な点、暗黙の前提になっている点。
   • 自信を持って行動するために必要な情報と、推測せざるを得なかったこと。
4. ステップ 1 で記録した意図（レビュー担当には見せていません）と、初見の理解を比較します。食い違いはすべて、読者の誤りではなく成果物の欠陥です。
5. 欠陥と具体的な修正案を、初めて読む人の理解を妨げる度合いが大きい順に報告します。

ルール

• 読み取りは、必ず独立したコンテキストなしのサブセッションで行わなければなりません。コンテキストを忘れることはできない（それこそがこの手法の要点です）ため、このセッション内で自己評価してはいけません。
• 渡すのは成果物の内容であり、意図ではありません。
• 「〜と仮定せざるを得なかった」という報告は、読者の失敗ではなく、発見事項です。
• 媒体を問いません。成果物に応じて、初見の読み取りで確認する質問を調整してください。
• 初見の読み取りは一度きりのサンプルであり、リスクの高い場面では確信を持っていても間違っている可能性があります。一度の読み取りは標準であって、十分な注意の上限ではありません。リスクに見合う場合は、独立した複数の読み取りにエスカレーションしてください。
• 読み通し、走査だけで済ませないこと。 初見の読み取りは最初から最後まで読むことであり、パターン検索ではありません。走査だけでは既知のパターンしか見つからず、古い参照先、リンク切れ、事実のずれ、気づかれない編集ミスを見逃します。実際にどこまで読んだかを記録し、grep だけで「問題なし」と報告してはいけません。

検証

完了する前に、次の点を確認します。

1. 意図を知らない新しいサブセッションで読み取りを行ったこと。
2. 評価結果（そのまま通用する／軽微な不足がある／修正が必要）を報告し、修正案をメインセッションに渡すこと。