find-gaps

ギャップを見つける

リリース後に発覚するバグや緊急対応の多くは、仕様が間違っていたことではなく、そもそも文書に書かれていなかったことが原因です。このスキルでは、修正コストが低い実装前の段階で、そうした抜け漏れを体系的に洗い出します。

ただし、ギャップを見つけることは仕事の半分にすぎません。誰も回答しない未解決の質問のリストは、手間が増えただけの ToDo リストです。重要なギャップがある場合、実際の成果物は更新された成果物です。つまり、ユーザーが決定し、その言葉どおりに記録され、信頼できる唯一の情報源に書き戻されたことで、以前は含まれていなかった決定が盛り込まれた計画、AC セット、またはモック仕様です。確認したセクションと想定外のケースを明記したうえで、問題がないというレビューも有効です。作業したように見せるために、ギャップをでっち上げてはいけません。

このスキルを使う場面

次のような場合に、このスキルを使います。

• ユーザーが「何が足りない？」「ギャップを見つけて」「穴を探して」「何が問題になる？」「これをもっと詰めたい」と尋ねる
• ユーザーが計画、仕様、受け入れ基準、またはデザインモックを共有し、レビューを依頼する
• 実装を始める直前に、事前の健全性チェックをしたい
• 別のチームやエンジニアに作業を引き継ぐため、完全性を確認したい
• プレモーテムを実施する

複数のモックをまとめてレビューするときは、storyboard と組み合わせます。storyboard は全体を1ページで把握できるようにし、このスキルはモック全体を通して何が 不足しているか を見つけます。 ストーリー、計画、仕様、またはバックログ項目が大きすぎる、横断的すぎる、コンポーネントごとに分割されている、あるいは独立して価値のある子ストーリーとしてまだ表現されていない場合は、story-splitting と組み合わせます。 既存コードの動作のうち、誰も文書に書き留めていないものが「ギャップ」である場合は、characterisation-tests と組み合わせます。

関連スキルとの境界

find-gaps では、調査対象となる成果物が必要です。意思決定の全体像をゼロから明らかにすることも、広範な作業を子ストーリーに分割することもしません。

必要なこと	使用するもの	理由
未解決のプロダクトやデザインの決定事項を厳しく検証する	インストール済みなら grill-me、そうでなければ specification または一度に1つの焦点を絞った質問	文書化された成果物をレビューする前に、意思決定の全体像を明確にします
広範な作業を、独立して価値のある子ストーリーに分割する	story-splitting	実装タスクではなく、プロダクトやバックログのストーリーを作成します
文書化されたストーリー、計画、AC セット、またはモック仕様を改善する	find-gaps	不足している状態、エッジケース、役割、制約、検証できない表現を見つけ、確認済みの決定事項を書き戻します
完了した実装が、正式な成果物を満たしているか判断する	acceptance-review	要件を書き換えず、コードを読み取り専用で基準ごとにレビューします
選択した子ストーリーを PR サイズの作業に分割する	planning	実装の分割と TDD の実行計画を担当します

成果物がまだ文書化されていない場合は、利用可能であればインストール済みの grill-me スキルを使います。そうでなければ、一度に1つの焦点を絞った質問をするか、specification を使って成果物を確立します。問題が未解決の意図ではなく作業の規模の大きさにある場合は、story-splitting を使います。このレビューで、成果物が実際には複数のストーリーが絡み合ったものだと判明した場合は、作業を中断し、story-splitting に戻します。成果物が実装に十分なほど明確であれば、planning に進みます。

基本原則

1. 書かれていることより、書かれていないことのほうが危険です。 エラーについて何も書かれていない計画は、エラーを適切に処理できないのではなく、まったく処理できません。測定方法のない受け入れ基準は、曖昧なのではなく検証できません。空の状態がないモックは柔軟なのではなく、新しいユーザーが初めて開いたときに破綻します。沈黙を許可ではなく危険信号として扱います。

2. すべてのギャップはコメントではなく、対話です。 静的なギャップ一覧は報告にすぎません。このスキルが生み出すのは、作業の責任者である人間が決定し、成果物の更新として記録された 意思決定 です。質問し、記録し、書き戻し、確認する。この一連の流れこそが成果物です。

この仕組み

これは対話型ループであり、一度きりのレポートではありません。流れは次のとおりです。

1. 適切なチェックリスト（計画／AC／モック）に照らして成果物を調査します
2. 候補となるギャップを「ブロッカー／対応すべき／あるとよい」に分類します
3. ギャップの数と該当箇所をユーザーに伝えてループを開始します。ギャップがなければ、確認した根拠を報告して終了します
4. ブロッカーから始めて、一度に一つずつ質問します（または密接に関連する質問を二つまとめて尋ねます）
5. 回答を具体的な成果物の更新（新しい AC、計画の段落、名前を付けたモックの状態）として記録します
6. 提案する更新内容をユーザーに提示し、確認します
7. 確認された更新を信頼できる情報源（ファイル、キャンバス、ドキュメント）に書き込みます
8. ギャップを3～5件解消するごとに要約します。これによりユーザーが状況を把握しやすくなり、矛盾も見つけられます
9. すべてのブロッカーと「対応すべき」項目を解消するか、ユーザーが終了を告げた時点で終了します（残りは明示的に保留します）

譲れないルール：一度に一つの質問。 20個の質問をまとめて提示するのはレポートです。20個の質問に一つずつ答えて記録していくことで、成果物が引き締まります。違いは、すべて進行のペースにあります。

ギャップ解消ループ

ステップ 1 — 調査

関連するチェックリスト（下記の「ギャップの発見」を参照）を一通り確認します。候補となるギャップは、まだ提示せずに記録しておきます。

成果物に複数の要素が含まれている場合（モックを埋め込んだ計画、モックを参照する AC など）は、チェックリストが混ざらないよう、セクションごとに確認します。

ステップ 2 — 分類

候補となるギャップを次のように分類します。

• ブロッカー — 判断がなければ実装を進められない、または誤った実装になる（認証モデルがない、エラーの仕様がない、検証できない基準）
• 対応すべき — 未解決のままにすると手戻りやバグの原因になる（空状態がない、成功指標が曖昧）
• あるとよい — 今回の反復を妨げるものではないが、記録しておく価値がある（パイロットでのダークモード、v2 向けの分析イベント）

すべてが「あるとよい」に分類される場合は、見落とした失敗経路や明示されていない前提がないか、反証するつもりで一度確認します。それでも重要なギャップが見つからない場合は、チェックリストの根拠とともにその旨を伝えます。好みの問題を格上げしたり、ブロッカーをでっち上げたりしてはいけません。

ステップ 3 — ループを開始する

最初の質問をする前に、ユーザーに次の内容を伝えます。

• 成果物の種類と確認したセクション
• 重要度ごとの件数（例：「ブロッカー 3 件、対応すべき項目 7 件、あるとよい項目 4 件」）
• ギャップが最も多いセクションまたは画面
• ブロッカーから順に一つずつ確認し、回答をそれぞれ更新内容として記録すること

開始することについて明確な同意を得ます（「支払いエラーから始めましょうか？」や「今すぐ始めますか？」）。ユーザーが最初に全リストを見たい場合は提示します。ただし、その後も質疑応答のループを続けます。

ステップ 4 — 質問し、具体化し、記録する

各ギャップについて、次の手順で進めます。

1. ギャップを一文で述べます。 前置きや正当化は不要です。
2. 具体的な質問をします。 無関係な質問を一つにまとめてはいけません。回答の選択肢が列挙できる場合（失敗時の方針、重要度分類、状態差異の適用範囲、保留の判断など）は、利用可能であればホストの構造化入力機能を使い、現在のスキーマに従います。それ以外の場合は、同じ質問を簡潔な自由記述で尋ねます。判断基準と実例については、下記の構造化して尋ねるを参照してください。
3. 回答が曖昧な場合は、検証可能にするための追加質問をします。 「ユーザーにエラーが表示される」→「どのようなメッセージを表示し、再試行できますか？」文言に関する追加質問は自由記述のままにします。少数の動作から選択肢を絞る追加質問は、構造化します。
4. 具体化した回答を、以下のパターンに沿って成果物の更新に変換します。
5. 提案する更新内容をそのまま提示し、対応している構造化入力、または自由記述での一度の確認を通じて、そのまま書き込む／インラインで編集する／破棄してやり直すのいずれかを選んでもらいます。ホストが並べてプレビューする機能に対応している場合は、実際に比較できる言い回しに限って使用します。
6. 確認されたら、信頼できる情報源に書き込みます。
7. 次に進みます。 その場にとどまりすぎないようにします。

ステップ 5 — 3〜5 個のギャップごとに振り返る

解消済みのもの、重大度別に残っているもの、回答間で気づいた矛盾をまとめます。「エラー画面から購入者は再試行できるが、2 つ前のギャップでは管理者だけが再試行できると言っていた」といった、単一の質問だけでは見えない矛盾に気づくためのステップです。

ステップ 6 — 終了する

次のいずれかに該当したら終了します。

• すべての Blocker と Should-address が解消されている（望ましい終了）
• ユーザーが時間切れを伝えた場合（「今はこれで十分です」など）— 未解決のギャップと担当者を明記した保留リストを作成し、漏れがないようにします
• ユーザーに決定権のない判断が必要なギャップに行き当たった場合 — 実際の担当者を明示してそのギャップを保留し、ほかのギャップへの対応を続けます

Q&A では対応できないほど大幅な書き直しが成果物に必要だとわかった場合（たとえば、AC セットに 3 つの異なる機能が絡み合って記述されている場合）は、その旨を明確に伝え、ユーザーにその成果物の作業を最初からやり直すよう提案してください。

---

ギャップの発見 — チェックリスト

成果物ごとに、以下を最初から最後まで確認してください。「おそらく該当しない」と判断してカテゴリを飛ばさないでください。確認のコストは 1 行ですが、見落とした場合はサービス停止につながります。

計画

• スコープと意図： 対象外の範囲は明記されていますか？ 問題を 1 文で説明していますか？ 成功指標とベースラインはありますか？ 何もしない場合のコストは何ですか？
• 前提条件と依存関係： すでに存在している必要があるもの、または満たされている必要がある条件は何ですか？ 先にリリースする必要があるほかのチームはありますか？ 横断的な移行はありますか？
• 順序と段階的な価値： 分割してリリースできますか？ 最小で価値のある最初の段階は何ですか？ 段階ごとのロールバック手段はありますか？ ダークローンチ／フィーチャーフラグ／カナリアリリースはありますか？ story-splitting に戻して確認すべき、データベースのみ／API のみ／UI のみのコンポーネント分割はありますか？
• 障害と復旧： 本番環境で起こりうる上位 3 件の障害モードは何ですか？ 各モードを検出する名前付きダッシュボード／アラートはありますか？ 復旧手段（ランブック、自動再試行、ロールバック）はありますか？ データ損失の影響範囲はどの程度ですか？
• 状態とデータ： エンティティごとの有限状態モデルはありますか？ 同時変更への対処は定義されていますか？ 冪等性はありますか？ バックフィル／移行計画はありますか？ 保持／削除／GDPR への対応はありますか？
• オブザーバビリティと運用： 本番環境で正常に動作していることを確認するために、何をログに記録／出力しますか？ オンコール担当者は誰ですか？ ランブックへのリンクはありますか？ SLO／エラーバジェットはありますか？
• セキュリティとコンプライアンス： 認証／認可のマトリクスはありますか？ PII とシークレットはどのように扱いますか？ 最も可能性の高い攻撃ベクトルの脅威モデルはありますか？
• テスト： 各レイヤー（単体／統合／E2E）のテスト戦略はありますか？ 明示的にテストしない項目は何ですか？ なぜ問題ないのですか？
• 明文化されていない暗黙知： 新しいエンジニアがこの計画だけを読んだ場合、どのような誤解をするでしょうか？

受け入れ基準

• 測定可能性： 機械またはテストで検証できますか？ 曖昧な表現のリスト：速い、直感的、シームレス、モダン、クリーン、レスポンシブ、うまく動作する、そのまま使える、堅牢 — それぞれに数値または具体的な動作が必要です。
• 事前条件／トリガー／結果の原則： すべての基準に事前条件、トリガー、観測可能な結果がありますか？ いずれかが欠けている場合、それは希望にすぎません。
• 異常系： 成功パスごとに、失敗パス（タイムアウト、バリデーションエラー、同時編集、権限拒否、クォータ超過、オフライン、古いデータ）もありますか？
• 入力のエッジケース： 空／null／未指定のオプション値、最小値／最大値／境界値、非常に長い文字列、非 ASCII 文字、絵文字、RTL、結合文字、重複、大文字小文字の違い、空白、数値のゼロ／負数／極大値／通貨の精度。
• 時間とロケール： タイムゾーン（ユーザー／サーバー／ストレージ）、DST の移行、i18n によるテキストの伸長、複数形、日付形式の曖昧さ。
• アクターとロール： 各基準はどのロールに適用されますか — 匿名ユーザー／認証済みユーザー／管理者／サービス／なりすましユーザー？ セッション中に権限が変更された場合はどうなりますか？
• 非機能要件： パフォーマンス目標（p50/p95 とワークロード）、アクセシビリティ（WCAG レベル、キーボード、スクリーンリーダー）、セキュリティ（認証、レート制限、監査ログ）、プライバシー（PII の可視性）。
• オブザーバビリティの基準： テストだけでなく、本番環境で基準を満たしたことを証明するイベント／メトリクスは何ですか？
• 完了条件： 「完了」とは何を意味しますか — マージ済み、デプロイ済み、100% への段階的展開済み、または N 人のユーザーで動作を確認済みですか？

デザインモック

• UI の状態: ローディング / スケルトン、空（初回利用）、部分、エラー（ネットワーク、バリデーション、404、403、500、タイムアウト）、成功 / 確認、無効、読み取り専用（権限なし）、オフライン、レート制限、古い / 要更新。
• コンテンツのばらつき: 最短（1 文字、1 項目）、最長（最大長、1 万件のリスト）、ゼロ / 1 件 / 多数。アバター欠落、画像リンク切れ。Unicode（絵文字、RTL、CJK の折り返し、結合文字）。数値（0、負数、大きな値、通貨、パーセント）。日付（今日、相対、遠い過去、遠い未来）。
• インタラクションの状態: ホバー、フォーカス（キーボード！）、アクティブ、選択済み、無効、ドラッグ中、非同期保留中 vs 楽観的更新。
• レスポンシブ & 密度: 360px 以下のモバイル、タブレット縦 / 横、デスクトップ、ウルトラワイド / 狭苦しい、ブラウザズーム 200%。
• アクセシビリティ: 色のみによるシグナル伝達、インタラクティブ要素のコントラスト、フォーカスリング + 順序、スクリーンリーダーのラベル / aria / alt、タッチ領域 44×44 以上、視覚効果を抑える設定への代替、フォームのラベル + エラーの関連付け。
• テーマ / プラットフォーム: ライト / ダーク / システム / ハイコントラスト、モーションの低減、戻る / 進む / 更新 / ディープリンク、モバイル Web vs ネイティブ。
• 権限 & ロール: 匿名での閲覧、閲覧のみ、編集、管理者、セッション途中でのロール変更。
• データライフサイクル: 作成 / 編集 / 削除のフロー + 元に戻す + 確認。基になるレコードが他の誰かによって削除された場合の挙動。
• 国際化: テキストの伸長（ドイツ語で +40%）、短縮（CJK）、RTL のミラーリング（テキストだけでなくレイアウト）、ロケールに応じた数値 / 日付 / 通貨の書式。

---

ギャップの解消 — 回答を成果物の更新につなげる

解消されたギャップはすべて、成果物内のテキストとして終わります。ここでは、その変換パターンを 3 つ示します。

回答 → 受け入れ基準

各基準は 前提条件 → トリガー → 観察可能な結果 として書き、基準ごとに観察可能な結果は 1 つにします。アクター、状態、具体的な UI / データの挙動、そしてユーザーが実際に確認した発行イベントを含めます。（これは基準のための構造的な規律であり、Gherkin シナリオや given/when/then のテスト DSL を書くよう指示するものではありません。テストは testing スキルに従い、挙動駆動のままです。）

• ギャップ: 「重複したワークスペース招待に関する仕様がない。」
• 質問: 「招待 API がこのメールアドレスはすでに招待済みだと報告したとき、オーナーには何が見えるべきか？」
• 曖昧な回答: 「ユーザーに伝える。」
• 追加の質問: 「正確にはどんなメッセージが、どこに表示されるのか？」
• 洗練された回答: 「メールフィールドのエラースロットに『このユーザーはすでに保留中の招待があります。』と表示する。」
• 追加する AC:

AC-14: 認証済みのワークスペースオーナーが招待フォームにいる状態で、招待 API が already-invited を返したとき、UI はメールフィールドのエラースロットに*「このユーザーはすでに保留中の招待があります。」*と表示する。

テスト: QA エンジニアは、追加の質問を一切することなくこの基準を実行できるべきです。質問する必要があるなら、その基準は完成していません — 洗練を続けてください。

回答 → プラン更新

著者がそのことを思いついていたならプランにあったはずの文（または段落）を書きます。セクションを示し、トレードオフを示し、失敗モードを示します。

• ギャップ: 「マイグレーションのロールバック戦略がない。」
• 質問: 「マイグレーションが途中で失敗した場合、どうやって動作する状態に戻すのか？」
• 回答: 「各ステップには逆操作があり、逆操作を順番に実行する migrate down がある。」
• プラン更新（新しいセクション）:

ロールバック。 migrations/ 内の各マイグレーションステップは up() と down() を公開しています。失敗時には pnpm migrate down を実行して、完了した各ステップの down() を逆順に再生します。データ損失のリスク: up() の完了から失敗までの間に挿入された行は、down() によって孤立します — これは Redis に保持する migration-in-progress フラグで緩和します。アプリケーション層はこのフラグを読み取り、マイグレーションの間、挿入をショートサーキットします。

回答 → モック状態仕様

見落とした状態ごとに、名前／トリガー／見た目／動作／終了条件を記録し、追加で質問しなくても実装できるようにします。

• 不足点：「連絡先リストに空の状態がありません。」
• 質問：「新しいユーザーが初めて連絡先画面を開いたとき、何を表示しますか？」
• 回答：「親しみやすいメッセージと、CSV をインポートするボタン、または手動で追加するボタンを表示します。」
• 状態仕様：

empty-first-use

• トリガー： 認証済みのユーザーで、アカウント内の連絡先が 0 件
• 見た目： 中央揃えのカラム。イラスト（impeccable tokens の EmptyIllustration を再利用）。H2「連絡先はまだありません」。段落「あなたのネットワークをアプリに取り込みましょう。」。2 つのボタン — プライマリ「CSV をインポート」（インポートシートを開く）、セカンダリ「手動で追加」（連絡先追加フォームを開く）
• 動作： 読み込み時にボタンを有効にし、ほかに利用できる操作はありません
• 終了条件： 連絡先の追加またはインポートが成功すると、リストは populated 状態に遷移します

ユーザーとの作業

ユーザーが答えられることだけを尋ねます。「エラー処理の方針は？」は設計検討事項です。「支払いが拒否されたとき、ユーザーにはどのメッセージを表示しますか？」は決定事項です。

1 回のやり取りにつき質問は 1 つです。ただし、密接に関連する 2 つの質問（「どのようなエラーが発生しますか。また、そこから再試行できますか？」など）は例外です。構造化入力のリクエストでは、ホストの機能がサポートする範囲内に限り、密接に関連する追加質問をまとめられます。無関係な不足点を 1 つのリクエストにまとめると、質問の羅列に戻ってしまいます。「それから」と入力しそうになったら、いったん止めて、最も重要な質問を選びます。

**ユーザーの用語に合わせます。**ユーザーが「購入者」と言った場合、受け入れ条件でも「購入者」を使います。黙って「ユーザー」や「顧客」に置き換えてはいけません。ドメイン用語は重要な要素です。

**決定事項は毎回、目に見える形で記録します。**確認された回答はすべて、次に進む前に成果物へテキストとして反映します。「最後にまとめる」つもりで非公開のリストを作ってはいけません。そのリストは消えてしまいます。

**トレードオフを隠さず、明らかにします。**回答によって後続の問題が生じる場合は、「つまり、匿名ユーザーもフォームを送信できますが、401 が返されます。これは意図した動作ですか。それとも先にサインインへリダイレクトしますか？」のように伝えます。結果がどうなるかをユーザーが把握できるようにします。

**エスカレーションが必要なタイミングを見極めます。**不足点について、ユーザーだけでは決められない場合は、実際の担当者を明示し、質問と担当者を明記して保留にし、作業を続けます。

**トリアージをやり直してはいけません。**各不足点がすでに Blocker／Should-address／Nice-to-have のどれかに決まっています。それぞれについて「対応しますか？」と尋ねず、具体的な質問だけをします。ユーザーが対応したくない場合は「スキップ」と言えます。

---

構造化して質問する

ユーザーに尋ねる質問は、自由記述か、現在のホストが実際に提供している機能を使った構造化入力のどちらかです。プロバイダー固有のツール名、フィールド、制限を決めつけず、その機能のスキーマを確認して従ってください。値がどこにあるかに応じて選びます。

• 選択肢そのものに価値がある場合 → サポートされている構造化入力を使います。選ぶほうが生成するより速く、選択肢を見せることでユーザーの役に立ち、一般的な回答も想定できます。
• ユーザー固有の言葉に価値がある場合 → 自由記述を使います。ドメイン用語、マイクロコピー、新しい決定事項など、成果物へそのまま転記するものが該当します。

向いているケース

ホストが構造化入力に対応しており、回答の選択肢を明確に列挙でき、複数のプロジェクトで繰り返し発生する場合は、構造化入力を使います。

状況	構造化された質問が役立つ理由
失敗時の戦略	再試行／即時失敗／キューイング／フェイルオーバー。それぞれに明確なトレードオフがあり、表面化させる価値があります。
重大度の再トリアージ	ブロッカー／対応必須／できれば対応。トリアージの判断がユーザーと異なる場合に役立ちます。
状態の差異の範囲設定	v1 で重要な状態はどれか。名前付きの選択肢から複数選ぶことで、やり取りを減らせます。
保留の決定	担当者を割り当てて保留／今すぐエスカレーション／作業を継続。対応の空白を埋めるループを完了できます。
書き戻しの確認	そのまま書き戻す／インラインで編集／破棄。更新案を作成した後の典型的な3択です。
バリエーションの比較	2つの AC 案、またはサポートされている並列表示形式での2つの状態仕様。文章で順に説明するより、比較するほうが効果的です。

向いていないケース

適さない場面で構造化入力を無理に使わないでください。

• マイクロコピー — 「どのエラーメッセージを表示すべきか？」には、ユーザーの正確な言葉が必要です。
• 真に自由回答の質問 — 「ここで何を実現しようとしていますか？」選択肢をこちらで作り出すことになります。
• ドメイン専門家向けの質問 — 「価格設定のフローで『確認済み』とは何を意味しますか？」ユーザーはあなたの知らないことを知っています。構造化された選択肢を示すと、ユーザーをあなたの推測に誘導してしまいます。
• 形だけのプロンプト — すでに正解が明らかな場合は、質問しないでください。提案するだけで十分です。

構造化のルール

• 密接に関連する小質問だけをまとめ、ホストがサポートする質問数と選択肢数の上限を守ります。
• ラベル、説明、推奨を示すマーカー、カスタム回答の動作、プレビューについて、確認できたスキーマに従います。サポートされていないフィールドを作らないでください。
• ラベルは短くし、そのフィールドがある場合は、重要なトレードオフを選択肢の説明に記載します。
• ホストがサポートしており、成果物を実際に比較できる場合に限り、並列プレビューを使います。

作成例 — 重複した招待、構造化入力の場合

不足事項：「招待の重複時の動作に関する仕様がありません。」

ホストが2つの質問を含む構造化リクエストに対応している場合は、密接に関連する次の判断をまとめて尋ねます。対応していない場合は、順番に質問します。

1. ユーザーに対する動作：「招待 API が already-invited を返したとき、どうするべきですか？」
   • インラインのフィールドエラー（推奨）： 担当者が画面上の状況を把握したまま、対応が必要なメールアドレスを示せます。
   • ページバナー： より目立ちますが、フィールドとの関連はわかりにくくなります。
   • 保留中の招待を開く： 担当者がそのレコードを閲覧できる場合にのみ役立ちます。
2. テレメトリ：「重複した試行について、テレメトリイベントを出力しますか？」
   • invitation.duplicate_rejected を出力（推奨）： 招待先のメールアドレスを含めずに、不正利用やファネルを分析できます。
   • イベントを出力しない： データ量を減らせます。既存の集計済み拒否メトリクスで質問に答えられる場合に適しています。

ユーザーが選択した後、ユーザーに見える動作について1つの基準を作成し、選択された場合はテレメトリについて別の基準を作成します。前提条件とトリガーは共有できますが、それぞれで個別に判断できる結果を1つずつ定めます。カスタムテキストはそのまま使います。その後、サポートされている構造化入力、または簡潔な自由回答形式の質問で、そのまま書き戻す／インラインで編集／破棄のいずれかを尋ねます。ホストがその表示形式に対応しており、違いが重要な場合に限り、並列表示の案を提示します。

---

出力

主な出力は更新済みの成果物です。信頼できる情報源が置かれている場所に書き込みます。

• 受け入れ基準 → AC リストに、新規または改訂した基準を末尾に追加するか、該当箇所に挿入します
• 計画 → 計画書に、新しい段落またはセクションを追加します
• モック仕様 → 画面ごとに states.md または同等の補足資料を作成します

副次的な出力はセッションの最後に作成する対応ログです。

## Gaps closed — find-gaps session, YYYY-MM-DD

Resolved (12):
  [Blocker   → AC-14]        Duplicate invitation handling
  [Blocker   → Plan §4.2]    Rollback strategy for migration
  [Should    → AC-15]        Empty contacts list state
  [Should    → states.md]    Search results loading/empty/error states
  [Nice      → AC-19]        Dark-mode contrast on error banner
  ...

Parked (2):
  [Blocker] Analytics event schema — owner: @growth-lead (decision pending for v2)
  [Should]  i18n for German — owner: @i18n-team (no locale priority yet)

ログは PR の説明、リリースノート、または作業を追跡している場所に記載します。これにより、決定事項（保留にしたものも含む）が消えてしまうのを防げます。

アンチパターン

• **20 個のギャップを並べて、そのまま立ち去る。**それはレビューではなく報告です。ユーザーは対応しません。ギャップを一つずつ確認しましょう。
• **ギャップごとに「これに対応しますか？」と尋ねる。**すでに優先順位を付けているのですから、ギャップを示し、具体的な質問をして、回答を記録し、次に進みましょう。
• 曖昧な回答を受け入れる。「ユーザーにエラーが表示される」ではテストできません。具体的で観察可能な結果になるまで掘り下げましょう。
• 質問をまとめる。「メッセージは何ですか、いつ表示されますか、再試行できますか、ログに記録されますか？」は、一度に一つずつ、4 回に分けて尋ねましょう。
• **ユーザーの表現を黙って書き換える。**ユーザーが「チェックポイント」と言ったら、「状態を保存」ではなく「チェックポイント」と書きましょう。
• **成果物への反映を省く。**文書に記載されるまでは、ギャップは解消されていません。口頭での合意はセッションをまたぐと消えてしまいます。
• **一つの巨大なギャップにセッションを費やす。**一つのギャップの議論に30分かかる場合は、設計スパイクです。保留にして先に進み、後で戻りましょう。
• **根拠のない数を目標にして打ち切る。**関連するチェックリストを最後まで確認し、関連する成果物にまたがって根拠をたどります。ただし、レビューを入念に見せるためにギャップを捏造してはいけません。根拠に基づいた問題なしという結果も有効です。
• **好みをギャップとして扱う。**文体上の好みはギャップではありません。決定がなされていないことがギャップです。
• **成果物を単独でレビューする。**計画 ↔ AC ↔ モックを相互に照合しましょう。ギャップは一つの成果物にない場合だけでなく、二つの成果物の矛盾として現れることもよくあります。
• **構造化入力を使うためだけに選択肢を捏造する。**実際の選択肢がわからない場合は、自由記述で尋ねましょう。捏造した選択肢はユーザーの回答をこちらの推測に誘導し、実際の答えを隠してしまいます。
• マイクロコピーに構造化された選択肢を使う。「どのエラーメッセージを表示しますか？」は自由記述にしてください。ユーザーの正確な言葉が答えであり、構造化された選択肢ではそれが失われます。
• **無関係なギャップを一つの構造化リクエストにまとめる。**ホストが許す場合、一つのギャップに関する密接に関連した質問を同じリクエストにまとめることはできますが、異なるギャップに関する質問をまとめるのは、ギャップを一括して並べるのと同じです。

クイックリファレンス

成果物	常に確認する上位3つのギャップ
計画	スコープ外の項目が明記されていない · ロールバック手段がない · 可観測性がない
受け入れ基準	測定できない表現 · 失敗時の経路がない · 非機能目標がない
デザインモック	読み込み中／空／エラー状態がない · 長文の変化への対応がない · キーボードフォーカスの扱いがない