--- name: user-confirmation-and-report user-invocable: false description: > 本スキルの内容が文脈に無い状態でユーザー発話（自動的なプロンプトを除く）を受けたとき、 応答を始める前に必ず起動する。セッションの最初の発話と、会話圧縮の後に最初に受けた発話がこれに当たる。 操作または判断の確認要否を判定するとき、ユーザー確認またはユーザーへの報告の手段を選ぶとき、UWIへ確認を退避するとき、 回答済みUWIを元の作業へ反映するとき、Claude Codeメインが利用上限の猶予通知を受けたとき、 またはツール呼び出しが権限設定もしくはauto mode classifierに拒否されたとき、委譲先の返却がその拒否を報告したときにも起動する。 --- # ユーザー確認とユーザーへの報告 本スキルは確認要否の判定から手段の選択、回答後の作業再開までを一続きに扱う手順を提供する。 UWIの本文、投入、状態および依存関係の形式は`agent-toolkit:wi-standards`を起動して適用する。 ## 起動契機 起動契機はfrontmatterの`description`が定める。同所が起動契機から除く自動的なプロンプトは、機械が生成してユーザー入力欄へ入る本文とする。 `atk wi process-loop`が子セッションの最初の入力として渡す起動時プロンプトと、モデルの可用性を確認するプロンプトがこれに当たる。 生成側は新しい本文を`atk-auto`要素で囲む。受領側は現行の`atk-auto`と旧`agent-toolkit-auto-inserted`の両要素を機械生成の境界として判別する。両要素で囲まれた本文は自動挿入として扱う。ユーザー発話の証拠は内側の`forwarded-user-input`だけとする。 委譲先として起動されたターンも、受け取る委譲プロンプトがユーザーの発話ではないため対象から外す。 Claude Codeメインが利用上限の猶予通知を受けた場合は、ユーザー発話への応答とは別の起動契機として本スキルを起動し、`references/main-behavior.md`「利用上限の猶予通知を受けたときの続行と再開」へ進む。 本スキルを起動したら次の2資料を全文読む。ユーザー発話を受領した場面では、発話の解釈の細則として`references/user-utterance.md`も全文読む。取得済みの本文の再利用と会話圧縮後の読み直しは`agent-toolkit/rules/02-agent-operations.md`「ツール・コマンド運用」に従う。 - `references/judgment.md`: 確認要否の判定の細則、認可を要する操作、確認を要する事項の例、原文からの具体化を要する軸 - `references/main-behavior.md`: メインの未確定判断の保留、暫定判断、事前承認の合意判定、回答の受領、利用上限の猶予通知後の続行と再開 次の場面では、その場面が生じた時点で対応する資料を全文読み、読む前にその場面の判断へ着手しない。いずれも該当する場面でだけ適用するため、起動のたびに読むと費用だけが増える。 - 規範どうしが矛盾する場合: `references/conflict-resolution.md`（由来確定） - 手順どおりに進められない場合: `references/procedure-conflict.md`（判定順） ツール呼び出しが権限設定またはauto mode classifierに拒否された場合と、委譲先の返却がその拒否を報告した場合は、上記に加えて`references/permission-denial.md`を全文読み、同書の手順に従う。 同書は拒否の確認手順、既知の誤拒否パターン、偽陽性と判断できる拒否への対応を扱う。 ## 確認要否の判定 確認要否を判定する前に`references/approval-scope.md`を全文読む。 判定の前に、選択肢を依頼の目的と要件、そのセッションでユーザーが示した判断基準、`agent-toolkit/rules/01-agent.md`「QCDと3段判定」、明文化された方針の順で順位付ける。明文化された方針はQCDを達成するための手段であり、QCDが明らかに悪化する場面での扱いは同節に従う。ユーザーが示した判断基準には、その場で示した手段と作業の進め方への指示を含めず、それらは`agent-toolkit/rules/01-agent.md`「方針が衝突する場合の優先順位」に従って扱う。 そのうえで、確認を発行するかは目的・期待結果・認可の確定と、その範囲内の手段の選択を分けて判定する。 1. 依頼の目的、期待結果と認可が確定しているかを判定する。ユーザーがその結果で何を判断し何を行うかを利用場面から導き、明示された要件に加えて、利用場面で必要な表現されていない要求も目的の評価へ含める。既存仕様と整合することや算術・実装として正しいことは、目的への適合とは別に判定する。目的への適合と認可の確定は、推奨案を持てることとは別に確かめる。 2. 不確実性が残る場合は、先に手元の情報で解消を試みる。調査、現物の観測、公式資料、明文化された方針、成立済みの承認、そのセッションでのユーザー発話と、起動中のスキル・規範・ユーザー指示が定めた工程と対象集合は、手元の情報に含める。定めを変える根拠は、現物を観測して得た事実に限る。調べれば確定できる未知は調べて確定し、調べていない未知は確認不要と判定する前に調べる。 3. 調べた後も、目的や期待結果を重要に変える解釈の相違か、ユーザーだけが持つ値（選好、認可、外部の状態、手元に無い資料）の不足が残る場合は確認を発行する。各質問の本文へ、解釈や値ごとに変わる外部可視の結果、根拠と推奨案を書く。推奨案を持つ場合も同じく確認する。成立済みの認可は再利用する。所要時間と費用の許容範囲もユーザーだけが持つ値に含める。費用と所要時間の見込みは観測から求めて案の影響として書き、許容するかは自ら決めない。ユーザーが範囲語か開放列挙で求めた対象（ツールや手順、確認の工程など）を費用や所要時間、手間を理由に省く判断は、対象集合の縮小に当たる。任意にする判断と求められた場合だけ実施する判断も同じく縮小に当たり、いずれも4の技術手段の選択としてではなく`references/judgment.md`「原文からの具体化を要する軸」に従って確認する。 4. 目的と認可が確定し、その範囲の内側の技術手段だけが残る場合は、自ら確定して実施する。別の合理的な実装者なら異なる判断をし得るものは、完了報告へ`references/grilling.md`「終了時報告」の形式（決定・理由・最有力の対案）で書く。先行発話や定めから確定した事項は、根拠となった発話または定めを理由へ書く。 目的に適した実装を選ぶための推論は、目的と認可の範囲の内側の選択へ作用させる。明示された要件の上書き、未合意の目的側の変更、依頼に無い挙動や機能の追加は推論だけで確定せず、3に当たるものとして確認する。 委譲先から差し戻された論点と、委譲先へ調査や選択を回そうとする技術的な選択肢にも同じ判定を適用する。手元の情報で決まる選択は、委譲の前に確定して委譲先へ渡す。 他の規範が用いる「認識の違いで要件や結果が変わる未確定事項」は、この判定の3で確認を要する事項を指す。 - 認可または選好がユーザーだけが持つ値に当たる操作と、その事前承認・事後承認の区分は`references/judgment.md`「認可を要する操作」と`references/approval-scope.md`が定める。この区分は推奨の順位にかかわらず適用する。 - 規範・文書・設定の記述を置くファイルと節、関数分割、内部データ表現、検証手段その他の技術選択は、目的と認可が確定していれば手元の情報で決まる事項として自ら確定し、事後承認の対象から外す。依頼がもともと求める変更の実施方法、範囲語が定める対象集合の適用、仕組みの要否も同じく自ら確定する。 ユーザーが適用する水準や分類を示した場合も、その記述を必要とする工程で各候補が読まれるかを、読込を定めるスキルや規範の現行条文で確かめて配置先を決める。 問いに次のような表面属性が当てはまっても、確認の要否は前段の判定で決める。 <例> 複数案がある 既存の規範や仕組みを変える 範囲が広い 他の画面や工程へ波及する エンドユーザーの観測結果が変わる 設計書や規範に明示の記述が無い 質問の件数と回数、推奨案の有無および規範上の自律度は、この判定の入力から外す。確認を要する問いは件数にかかわらず発行し、要しない問いは件数にかかわらず自ら確定する。必要な確認は意図と異なる成果物と是正の介入を防ぐ正常な協働であり、自律遂行と質問の削減は目的・要件とQCDを守るための手段である。 技術的に決まる事項を確認へ送ると、判断材料の無いユーザーから「技術的に正しいようにやって」と差し戻される。目的が確定していないまま推奨案で進めると、意図と異なる成果物をユーザーが是正することになる。 ユーザーの判断を求める確認本文と、委譲先が委譲元へ送る確認通知が含む項目を「確認提示項目」と呼ぶ。確認提示項目は判断対象、推奨案、代替案、根拠、影響範囲およびユーザーが観測する結果とし、協調モードの確認本文では回答後に実施する操作を加える。 選択肢が対処法、操作または回避手段を示す場合は、その手段が回答者の試みる操作を可能にするかを書く。 可能にしない手段では、達成する別の目的と、元の操作が成立しない条件を併記する。 別目的の手段を成立手段として示すと、回答者は元の操作を完遂できる案として選択する。 確認を発行する応答の地の文へ、確認を発行することだけを書かない。推奨案とその根拠の要旨を確認の本文へ同梱し、地の文を置く場合は同じ要旨を含める。 確認を発行しない応答で未確定の選択肢を示す場合と、推奨案を確定できない場合の扱いは`${CLAUDE_PLUGIN_ROOT}/share/rules-main.md`「ユーザー向け発話ルール」の推奨案の箇条に従う。同梱するのは要旨とし、確認の本文と同じ分量は求めない。 確認の本文は描画されるまで回答者へ到達しないため、先に到達する地の文が判断を委ねるだけの内容であると、回答者が応答を中断して推奨の提示を求める。 ## 確認の選択肢を組む手順 確認が満たす条件は、回答者がその本文だけで判断でき、合意した範囲がそのまま成果物になることとする。 未検証の前提に基づく選択肢ではユーザーが判断できず、誤った前提への合意は合意していない範囲の成果物を確定させる。 ### 根拠の確定 確認本文と選択肢の前提および各案の影響・副作用は、「可能性がある」と推測として書くものも含め、現物の実装、規範本文または実行結果で影響へ至る処理を確かめる。確かめていない影響は確かめてから書くか、確認本文から外す。多数の対象へ同時に作用する共通の機構の動作を変える案では、手元のデータでの実行結果を影響の確認の全てとしない。変更前の動作を前提として書かれた既存の指定を`agent-toolkit:plan-mode`の`references/plan-file-standards.md`「要件・外部仕様」の参照元の範囲に従って列挙し、各指定で変わる結果を書く。「再現していない」「未確認」と添える場合も、影響へ至る処理を確かめる。 対象には別主体が述べた事実主張、既存文書が前提とする手順・対象・状態の実在を含める。実際の確認により成立しないと判明した事実は確認へ送らず、確定できる範囲を自ら確定する。 根拠として使う実装、実行結果または一次資料は、主張の対象へ直接対応付ける。 表、脚注や注記を根拠とする場合は、対象行と適用範囲を対応付ける。 委譲報告を根拠とする場合は、採否を左右する項目を現物と比べ、一致を確認できた項目だけを選択肢へ使う。 完遂の可否と容量の不足は、本文と選択肢の前提から外す。実行環境が会話を自動で圧縮して継続するため、容量を理由に完遂できない状態は生じない。 所要時間とコストの許容範囲も同じく前提から外し、その扱いは「確認要否の判定」の3に従う。 確認本文が現況を不整合、欠陥、不足や未追随として述べる場合は、その現況の由来も実際に確かめる。由来がユーザーの選択であると判明した場合と判別できなかった場合は、その現況を維持する案を選択肢へ含める。 問い本文と各選択肢が名指しするコマンド、ツールおよび設定項目については、そのセッションで公開契約（ヘルプ出力、入力スキーマ、公式仕様のいずれか）を取得してから選択肢を組む。取得した契約で選択が一意に定まる対象は、確認の対象から除いて自ら確定する。 操作、設定または回避策を案内する案は、その実行処理が入力補正、省略時の値または権限判定を適用した後に到達する状態を確定する。 設計文書の記載は手段の実在を裏付け、手段の効力は前項で確定した到達状態から判定する。 集合の外側に該当が無いことを含意する主張を本文へ書く場合は、母集団の総数、除外した分類ごとの件数と、除外の判定条件を同じ本文へ併記する。 同じ関数、設定、正規化のいずれかを使う処理や呼び出し元を「次の処理でも使う」「影響を受けるのは次の箇所」のように列挙する本文も、この主張に当たる。列挙の前に、検索の各一致をその行を含む関数や画面などの識別子へ対応付け、対応付けた結果から列挙を書く。一致の件数と列挙の件数が異なる場合は、除いた一致とその理由を同じ本文へ書く。行番号やファイル名だけを返す検索結果から記憶で列挙すると、影響を受ける処理の一部を列挙できない。 除外の判定条件がユーザーの合意を得ていない技術判断である場合は、その判断そのものを選択肢の論点として示す。 同じ実装構造を共有する対象の一部を範囲から除外する場合は、その構造が生む外部可視の結果で判定軸を構成する。観測済みの症状が再現しないことだけを除外の根拠とする形は、この判定軸に含めない。 対象を含める条件を選択肢にする場合は、選択肢ごとに扱いが分かれる実データの行と各案での扱いを表で示す。 行の状態はその状態が生じる処理を挙げ、出力行と参照元の全行を比べて確定する。空欄や欠損は、状態を推定する根拠から外す。 全案で扱いが同じ行だけを例示すると回答者が条件の差を判断できないため、差分行を確認本文へ含める。 実装方式、アルゴリズム、データ構造など目的を達成する手段の比較を選択肢にする前に、その手段が満たすべき達成目標と受入条件を確定する。確定できない場合は、達成目標と受入条件そのものを確認対象とする。 目標と受入条件が未確定のまま手段を選ばせると、合意した手段の不成立が実装後まで判明しない。 エンドユーザーが観測する表示、通知または帳票の文面案は、文面が主張する事象を表示実装の判定条件と比べる。 両者が一致しない場合は、文面、判定条件、あるいは双方のどれを変更するかを同じ回答単位へ含める。 観測した問題への対処を選ばせる確認では、確認を起草する主体が選択肢を組む前に`agent-toolkit:bugfix`を起動し、「初動と拡張原因分析の判定」に従って直接的原因を観測で確定する。 方針や初期設定の変更の認可、適用範囲の選択など、対処を別の形で問う確認も、その確認の動機が観測した問題の解消であれば本段落の対象とする。 委譲先が直接的原因を確定して返した場合は、返却が示す観測を現物と比べて一致を確かめたうえで、確定済みの原因として扱える。 原因の機構を持つ製品やツールについては、その機構を止めるか変える設定と公開機能を公式資料で調べる。そのうえで確定した原因へ作用する対策を列挙してから、症状の側を変える案（上限や閾値の緩和、保証範囲の縮小、対象の廃止、実行頻度の変更など）を同じ階層へ並べる。 既知の制約、追加操作、取りこぼしまたは状態不一致を残す案では、`agent-toolkit:writing-standards`の`references/design-heuristics.md`「案の採否と実施順の判定」に従い、その不都合を生む構造を除く案も比較する。成立する構造側の案を同じ確認の選択肢へ含め、成立しない場合は確認本文へ観測根拠を書く。例えば、通常の保存では届かない専用登録APIを維持する案では、保存処理へ登録処理を統合する案を比較する。 原因へ作用する対策を確認本文へ載せない場合は、その対策が成立しない根拠を観測結果で示す。 原因を実際に確かめられない場合は、対処の選択ではなく、原因の確定に必要な調査と、その調査を実施する条件を確認の主題にする。 症状の側を変える案だけを並べると、回答者が原因側の対策を自ら挙げ直すことになり、確認の往復がその分だけ増える。 ### 候補の構成 候補構成の冒頭で、人が決める方針・基準・考え方と、その結果からエージェントが決める技術的詳細を分ける。質問本文は判断を変える前提、外部可視の差、推奨理由に限定する。技術的に一意な値は質問へ移さず、実行主体が確定する。 各質問について共通前提を検討し、本文へ`共通前提:`で始まる1行を置く。全ての選択肢が共有する前提と、その前提を外した案を選択肢へ含めたことまたは含めない根拠を書く。選択肢の評価が依存する技術的事実（対象の成果物を作成する主体、その時点でそろっている情報や状態など、エージェントが観測で確定した事実を含む）も同じ行へ書く。合意済みの前提だけを書くと、回答者は主体や時機を誤解したまま選択肢を読み、事実を問い返す往復が生じる。共有する前提も技術的事実も無い場合は、行を省かず`共通前提: なし`と書くことを推奨する。行を省いても判断は誤らないが、検討を済ませたことが回答者に伝わる。 前提を外した案、既存の名称や語を使う案、既存側を変更しない案、先行する人間の判断を反映する案を選択肢へ載せる。実装量、工数、変更範囲の大きさおよび所要時間は案の影響として書く。所要時間とコストの許容範囲の扱いは「確認要否の判定」の3に従う。技術的な不成立や規範・安全制約との衝突など、別の根拠は現物から判断する。 判断の時機、実施の主体、対象の範囲、工程の順序、工程の終端と結果の届け方、論点に関わる既存の機能・手段・分岐・設定の存続、論点の場合を別扱いにしている既存の規則（例外、条件分岐、登録数の制限など）、ユーザーの発言から写した語を、共通前提と前段の技術的事実を探す軸として確かめる。ユーザーの発言から写した語には範囲語（「全体的に」「全部」など）と例示（「例えば〜」）を含め、ユーザーが述べた語でも選択肢へ写した場合は前提として`共通前提:`行へ列挙する。 既存の対象を残す前提を外した案には、元の要求に不要な分岐、条件、確認や対象そのものを撤去して目的が成立する案を含める。 名称・識別子・用語を選ぶ場合は、同じ機構に既存成果物が使う語を候補の生成元へ含め、載せない場合は理由を確認本文へ書く。既存成果物との関係を変える場合は、既存側を変更しない案を含め、成立しない場合は理由を示す。同じ適用区分の先行する人間の判断は後続の案へ1件以上反映し、反映できない場合は理由を確認本文へ書く。そのセッションのユーザーの発言（先行する発話を含む）が挙げた例示も、ユーザーが候補の提示を求めた場合を含めて候補へ含め、含めない場合は理由を確認本文へ書く。 工程を後続のセッション、`atk wi process-loop`か別の担当へ移す場合は、移した工程の終端を依頼の目的が完了する状態から決め、結果がユーザーへ届く報告先、粒度と時機を同じ案へ書く。届け方は「手段の選択」のユーザーへの報告に従う。現行の工程が生成する成果物や報告方法を暗黙に引き継ぐと、推奨案を選んだユーザーが終端と報告の要求を補うことになる。 全ての選択肢が共通して前提とする事項は、由来（ユーザーの発言の語、工程の順序と段取り、現行規範、現状の要件など）を問わず、その前提で達成しようとした上位の目的の水準で前提を外した案を1件以上載せるか、載せない根拠を書く。 手元で観測した結果からその目的の前提がすでに満たされていると分かる場合は、後段の工程を前倒しする案を載せるか、載せない根拠を書く。 <例> 「小さいリポジトリで試してから全体へ広げたい」と述べた後、試行の結果が出た時点で質問する: 同じ回で全体へ展開する案も並べる。 新しい方針を、既存の規則が別扱いにしている場合へ広げるかを問う: 規則を残す案と規則の内側で新しい方針を当てはめる案に加えて、その場合を別扱いにしている規則そのものを外す案を載せる。載せない場合は根拠を`共通前提:`行へ書く。 依頼が範囲語で対象を定めながら、例示や問いで特定の対象を知りたい目的を示している場合に対象を問う: 範囲語どおりの案に加えて、例示と問いが示す目的の対象へ限定する案を載せる。 推奨案と前提を共有する案だけを並べると、回答者が欠けた案を自ら挙げ直し、確認の往復がその分だけ増える。 問いおよび選択肢の主題は、実装上の具体値と実装手段ではなく、その値と手段を導く方針、基準または考え方へ置く。方針を主題とする場合は、対象の識別子、方針ごとに変わる外部可視の結果、その方針を採用した場合に実行する操作の要約を確認本文へ示す。実装手段そのものを主題としてよいのは、手段の違いが方針の違いへ写像せず、達成目標と受入条件を確定済みの場合に限る。この場合は手段の違いが方針の違いへ写像しないと判定した根拠を確認本文へ書く。得た回答はその確認を超えて再利用できる方針として扱い、恒久的な成果物へ残せる粒度の方針を主題に選ぶ。 実装内部の値と手段を選ばせる問いは回答者が判断材料を持たず、恒久化できない粒度では同じ確認を繰り返す。 既存成果物と新しい成果物の関係を変える確認では、変更する側と依存の向きを比較軸に含める。 そのセッションで人間が確定した再利用可能な判断は、成果物名だけでなく、読み手、公開範囲または主題などの適用区分へ対応付ける。 選択肢は候補を一覧で示し、技術的な最適案を第1選択肢に置く。第1選択肢を決める前に、その変更の消費主体（変更後の成果物を使う人とその役割、または人以外の消費主体）を特定し、その消費主体にとっての理想的な動作を整理する。人の役割の定義は`agent-toolkit/rules/01-agent.md`「役割分担」が定め、ユーザーはエンドユーザーに含まれ、1人が複数の役割を兼ねられる。第1選択肢はこの整理の結論を反映した推奨案とし、確定した達成目標と受入条件を満たす案から選ぶ。受入条件を満たす案が複数ある場合は、追加する仕組み（上限、分岐、集約、専用の状態、書込主体や不変条件の変更など）が最も少ない案を第1選択肢とする。確認を発行する前に、第1選択肢より仕組みの少ない各案について満たさない受入条件を説明へ書けるかを確かめ、書けない案があればその案を第1選択肢へ替える。仕組みを加える案を第1選択肢にするのは、それが無いと満たせない要件を観測事象で示せる場合に限り、その観測事象を選択肢の説明へ書く。判断の根拠は`agent-toolkit/rules/01-agent.md`「QCDと3段判定」に従う。仕組みを加えない案の説明に書く影響も、「根拠の確定」と同じく影響へ至る処理を確かめて書く。選択の判断そのものをユーザーへ委ねる形は、確認の構成に含めない。特定した消費主体と、その消費主体にとっての理想的な動作を確認本文へ示す。達成目標と受入条件を満たさない案を選択肢へ載せる場合は、満たさない受入条件を説明へ書く。 許容できる不便の範囲は消費主体とその役割で変わるため、それを示さない選択肢では回答者が判断材料を持たない。要件を満たさない案を推奨すると、ユーザーがその案を選び、確定した受入条件を満たさない成果物が確定する。理想的な動作を仕組みで保証する案を観測事象なしに推奨し、仕組みを加えない案の影響を確かめずに重く書くと、回答が過剰な設計へ誘導される。 ### 影響と回答単位 第1選択肢を決める前に、各案が持つ副次的影響を技術的な比較と並べて評価する。対象は案を実施した後に残り、回答者が気付きにくいか取り消しにくい結果とする。第1選択肢は副次的影響の評価を含めて最良と判定した案とし、実装上の即応性だけで決めない。評価した影響が案ごとに異なる場合は、その差を選択肢の本文へ書く。推奨案の根拠は、推奨案の利点だけでなく、他の案が持つ利点（性能、発生頻度など）と並べて書く。 副次的影響を示さない選択肢では、ユーザーがその影響を知らないまま不可逆な操作等へ合意する。 <例> 機密情報が残存する範囲 操作の可逆性 第三者が観測できる範囲 監査記録の残存 外部通知 管理元の外に置いた複製やリンクが、管理元の更新や別の方法で行う操作によって管理元の内容と一致しなくなる範囲 案ごとに変わる外部可視の差（入出力、応答時間、表示順序、情報量、通知頻度など）を確認本文へ書く。 外部可視の差が本文へ現れないと、ユーザーは案を比較できず、回答後に同じ論点を確認し直す。 各案が変える値、文言または挙動を保持し、採用後に追随が必要になる成果物を選択肢へ書く。 対象には設計書、運用手順、ヘルプ、テストおよび公開資料などを含める。 追随対象が無い案では、0件であることを明示する（努力目標。追随の検討を済ませたことを回答者が判別しやすくするため）。 確認を発行する前に、その論点で確定を要する事項を列挙して回答単位へ含める。回答単位がその事項を欠くと、回答の直後にユーザーがその事項を指示する往復が生じる。 論点が値の保持先を含む場合は、対応する既存の保持機構を列挙して選択肢へ含める。回答の結果として保持先の値の登録、保存、作成、変更を伴う問いは、主題が実施の主体や手順、時機であっても保持先の論点を含む。この場合は保持先に登録済みの項目を実物（保持先の一覧取得など）で列挙し、流用する項目と新設する項目の数と形を選択肢の説明か`共通前提:`行へ書く。値の指定をユーザーへ委ねる論点では、その値の候補案を1件以上同じ確認へ示す。 既存のフラグ、列、設定項目または状態の値を変える論点では、その値を読む箇所を列挙し、各箇所での意味と変更後の値の両立を確認本文と計画へ書く。当座の要件が値の定義上の意味と一致するかも判定する。読取側との結合を示すと、回答者は値の変更と結合の解消を比較できる。 いずれの選択肢を選んでも残る外部可視の結果は、本件の範囲で許容するか別の要求単位として扱うかを同じ本文で一意に示す。 複数のユーザー依存事項は、各事項を単独で除外したときに他の事項の技術的成立性が変わるかを確認する。成立性が変わらない事項は別の質問に分け（同じ呼び出しへ複数の質問として並べてよい）、各事項への合意は個別の回答で判定する。提案全体への肯定は、各事項への個別合意の判定材料に含めない。相互依存する事項は同じ確認単位に保ち、追加機構を用いない既存動作だけの案も同じ階層で比較する。 確認の発行前に、問い本文と各選択肢に現れる名詞が、ユーザーの発言に現れた語、一般に意味が一意な語または同じ本文で説明した語のいずれかであることを確認する。該当しない語は説明するか置き換える。問い本文では、対象、機能および検証手段の有無を別の事実として書き分ける。基準は`${CLAUDE_PLUGIN_ROOT}/share/rules-main.md`「ユーザー向け発話ルール」とする。 ## 手段の選択 両工程の定義は`agent-toolkit/rules/01-agent.md`「役割分担」が定め、手段は次の表で選ぶ。 ユーザーへの報告では、発話本文と報告用UWIのどちらでも、作業の結果を都合の悪い結果も含めて正直に報告する。 | 工程 | 協調モード | 自律モード | | --- | --- | --- | | ユーザー確認（事前承認） | 実行環境の構造化質問。Claude Codeは`AskUserQuestion`（制約は`agent-toolkit/share/rules-main.claude-code.md`）、Codexは`agent-toolkit/share/rules-main.codex.md`の手段を使い、適合するものが無ければ`references/codex-format.md`の固定形式で提示する | 実行環境が実際に働く回答期限を持ち、ホスト契約に適合する構造化質問を発行できるメインだけが、その場で質問する。期限を超えて回答が無い場合は`references/main-behavior.md`「未確定判断の保留と暫定判断」へ進む。期限が無い実行環境と、期限の設定値があっても期限を無効化する条件が成立する実行環境では、質問を発行せず最初から事前承認型UWIへ記録し、回答を要する元項目だけを保留する。回答期限を持たないCodex Default modeは`agent-toolkit/share/rules-main.codex.md`の例外に従い、同じ結果になる | | ユーザー確認（事前承認以外の、回答を待つ通常の確認） | 事前承認の行と同じ手段を使う | 回答期限の有無によらずその場の質問を発行せず、事前承認型UWIへ記録して`references/main-behavior.md`「未確定判断の保留と暫定判断」に従う | | ユーザー確認（事後承認） | その場で構造化質問を使う | 回答を待たずに事後承認型UWIへ記録し、元の作業を続ける | | ユーザーへの報告 | 発話本文。作業完了報告は`agent-toolkit:completion-report`の書式に従う | `agent-toolkit:completion-report`の報告用UWI（セッションに1件） | 自律モードで実際に働く回答期限を持つのは、`atk wi process-loop`のように起動時に有限の期限を与える実行環境である。回答期限を無期限とする設定で起動したセッションは、期限を持たない実行環境として扱う。 `agent-toolkit:realign-with-user`の認識合わせの質問は本表の対象外とする。自律モードでの発行、回答期限と回答が無い場合の扱いは同スキルが実行環境ごとに定める。 回答なしで終わった確認のUWIへの切替は`references/main-behavior.md`「未確定判断の保留と暫定判断」が定める。 有効な回答期限の超過、回答なしで終了した後の同一セッションの確認、事前承認を要する元項目の保留は同節へ接続する。 実際の回答を得た場合は、その合意に沿って続行する。ユーザー接点を持たない委譲先は、後段の確認通知の手段で委譲元へ返す。 次の場合はモードによらず個別のUWIを使う。 - ユーザーが指定した手段と明らかに異なる手段を採用した記録は、事後承認型UWIで確認する - 成果の適否をユーザーだけが観測できる変更は、元の要求を終端して事後承認型UWIで適否を問う - 再発防止策なしで終えた判断は事後承認型UWIで確認する。`agent-toolkit:session-review`が扱う問題では振り返り結果報告が兼ねる - AWIの`## ユーザーコメント`またはUWIの`## 回答`へ直接記入された質問への回答は、ユーザーへの報告として個別のUWIで届ける 自律モードでは次の実施を個別の事後承認型UWIにせず、報告用UWIへ含める。事前承認の対象は事前承認のまま扱う。 - 起動中のスキル、適用中の規範、ユーザー指示または計画が記録した回答が工程・対象集合・副作用を定めた範囲の実施 - 曖昧な要求を解釈して実施した記録 事後承認は実施した対応の可否がユーザーだけが持つ情報（選好、認可、成果の見え方）で決まる場合にその可否を問う。 ユーザーへの報告は判断を求めない内容を届ける。 報告用UWIが事後承認型UWIの2択書式を使うのは是正を返せる回答欄を置くためで、工程はユーザーへの報告のままとする。 非同期の構造化質問では、発行の成功と初期選択を回答または承認として扱わない。後続の実回答を元の質問へ対応付け、その回答に依存する操作は受領まで確定しない。 委譲先が委譲元へ確認事項を通知する場合、`agents_server`の委譲先は本文をUTF-8ファイルへ保存して`atk agents notify --body-file=<絶対パス>`で送り、Claude Codeの`Agent`ツールの委譲先は`SendMessage`の`to: "main"`で送る。 確認を発行した主体は、ユーザーがその確認を棄却したか、承認要求を取り下げたことを観測した場合、同じ論点を`## 確認要否の判定`で判定し直す。認識の違いで要件や結果が変わる未確定事項が残る場合は、その論点の解決を要する元項目を`hold`で保留したまま事前承認型UWIへ記録し、確認を要しない範囲に収まる場合は自ら確定して続行する。棄却と取り下げの観測は回答なしに当たらないため、以降の確認を同期的に発行しない切替の条件からは外れる。 事後承認の確認本文と記録する範囲は`references/approval-scope.md`の事前・事後承認の区分に従う。 ## 回答後の状態遷移 回答の到達は、投入済みで未回答のUWIを保持している間、`agent-toolkit:delegation`の`references/waiting-and-monitoring.md`が定める経過時間起動の各回で`atk wi`により確認する。この確認も本節の起点とする。 `agent-toolkit:process-wi`の起動中は`agent-toolkit:wi-standards`「状態と依存」の手順を適用する。それ以外で回答済みUWIの通知を受け取った主体は、自セッション（委譲先を含む）が投入したUWIだけについて、次を同じ作業の連続した工程として完了する。他のセッションが投入したUWIは読まずに無視し、投入したprocess-wiの実行かその次の実行の選定工程に任せる。 標準2択の事後承認型UWIへの肯定回答後の遷移は`agent-toolkit:wi-standards`「状態と依存」に従う。この分岐では回答を読み取って了承済みの判断を確認し、同じUWIへの再度の`adopt`や是正処理を実行しない。問題を示す回答と事前承認型UWIは、以下の手順で元の作業へ反映する。 1. `atk wi show `で質問と回答を読み、暫定判断との差分を確定する。 2. 回答を元の作業へ反映する。回答済みUWIはUWIのまま扱い、別の作業要求が明示された場合だけ独立したAWIの要否を判定する。 3. 反映が成立したUWIを`atk wi adopt `で終端する。回答が質問を退けた場合は`reject`を使い、理由を回答と対応付ける。 4. そのUWIの本文が指す保留中の元項目を`atk wi unhold <元項目ファイル名>`で`inbox`へ戻し、回答待ち以外の続行できない理由が無ければ元の処理を再開する。 5. 元の`agents_server` sessionを保持している場合は同じsessionへ回答を配送して再開する。保持していない場合は、計画または引き継ぎ記録から未完了工程だけを再開する。 状態変更コマンドの成功報告と警告の不在を各遷移の完了根拠とする。途中で失敗した場合は、成功済みの状態をそのまま残し、未完了の遷移から再開する。