--- name: confirmation-and-uwi description: > 操作又は判断の確認要否を判定するとき、UWIへ確認を退避するとき、 回答済みUWIを元の作業へ反映するとき、 又はツール呼び出しが権限設定若しくはauto mode classifierに拒否されたときに起動する。 --- # 確認とUWIの状態遷移 本スキルは、確認要否の判定から回答後の作業再開までを一続きに扱う手順を提供する。 UWIの本文、投入、状態及び依存関係の形式は`agent-toolkit:wi-standards`を起動して適用する。 本スキルの起動契機の全場面で、次の5資料を全文読む。 - `references/judgment.md`: 確認要否の2段階判定、確認を要する事項の列挙、原文からの具体化を要する軸 - `references/main-behavior.md`: メインの未確定判断の保留、暫定判断、事前承認の合意判定、事後承認型UWI - `references/user-utterance.md`: ユーザー発話の解釈の詳細箇条 - `references/conflict-resolution.md`: 規範どうしが矛盾する場合の由来確定 - `references/procedure-conflict.md`: 手順どおりに進められない場合の判定順 ツール呼び出しが権限設定又はauto mode classifierに拒否された場合は、上記に加えて`references/permission-denial.md`を全文読み、同書の手順に従う。 同書は拒否の確認手順、既知の誤拒否パターン、偽陽性と判断できる拒否への対応を扱う。 auto modeのカスタムルールを追加・編集する手順は`agent-toolkit:writing-standards`の`references/auto-mode.md`が定める。 ## 確認要否の判定 確認要否を判定する前に`references/approval-scope.md`を全文読む。 候補ごとに次の順で判定する。 候補には、既存の条件分岐、状態及び手順を維持する案に加えて、元の要求に不要な分岐、条件又は確認を除去して成立する案も含める。 起動中のスキル、規範又はユーザーの指示が、実施する工程と対象集合を既に定めている場合は、その工程を実施するかどうかと対象集合を縮小するかどうかを確認へ送らず、定めのまま実施する。定めを変える必要があると判定した根拠は、実測した事実に限る。 定めの再確認は、ユーザーが既に指示した内容を問い直す往復を生む。 1. ユーザーの指示、成立済み承認及び規範から、操作、対象と副作用が許容されるかを判定する。 2. 許容される候補のうち、依頼された成果に必要な変更だけを残す。 3. 必要な変更の実装品質を比較し、技術資料又は実測で一意に決まる選択を確定する。 確定した候補について、次のいずれかへ分類する。 - 技術判断で確定し、公開インターフェース変更、破壊的操作、第三者又は外部サービスへの影響、ユーザーが直接観測する出力変更のいずれにも当たらない場合は、確認を省いて実施する。 - 同じ操作、対象、影響範囲と成立条件について承認済みの場合は、その承認をそのまま適用する。 - ユーザー要件又は運用方針の選択を伴う可逆な変更で、第三者又は外部サービスへ影響せず、復元に外部操作を要しないものは、最善案を実施して事後承認へ送る。 - ファイル配置、関数分割、内部データ表現、検査手段その他の実装上の技術選択は、前段で自ら確定し、事後承認へ送らない。 - それ以外の承認対象と、技術判断だけでは決まらないユーザーの選好は、実施前の確認へ送る。 確認本文には、判断対象、推奨案、代替案、根拠、影響範囲及び回答後に実施する操作を書く。 選択肢が対処法、操作又は回避手段を示す場合は、その手段が回答者の試みる操作を可能にするかを書く。 可能にしない手段では、達成する別の目的と、元の操作が成立しない条件を併記する。 別目的の手段を成立手段として示すと、回答者は元の操作を完遂できる案として選択する。 確認を発行する応答の地の文へ、確認を発行する旨だけを書かない。推奨案とその根拠の要旨を確認の本文へ同梱し、地の文を置く場合は同じ要旨を含める。 同梱の対象は、確認を発行する応答に加えて、確認経路へ送る論点を宣言する応答も含める。対象となるのは、確認の発行より前に工程、論点又は未確定事項をユーザーへ示す応答とする。 その時点で推奨案を確定できない場合は、推奨を確定するために行う調査と、その完了後に推奨を示す旨を同じ応答へ書く。同梱するのは要旨とし、確認の本文と同じ分量は求めない。 確認の本文は描画されるまで回答者へ到達しないため、先に到達する地の文が判断を委ねるだけの内容であると、回答者が応答を中断して推奨の提示を求める。 ## 確認の選択肢を組む手順 確認が満たす条件は、回答者がその本文だけで判断でき、合意した範囲がそのまま成果物になることとする。 未検証の前提に基づく選択肢ではユーザーが判断できず、誤った前提への合意は合意していない範囲の成果物を確定させる。 ### 根拠の確定 確認本文と選択肢の前提のうち、この確認のために自身が実測していない事実は、現物の実装、規範本文又は実行結果で実測する。 対象には、別主体が述べた事実主張と、既存文書が前提とする経路、対象及び状態の実在を含める。実測により成立しないと判明した事実は確認へ送らず、確定できる範囲を自ら確定する。 根拠として使う実装、実行結果又は一次資料は、主張の対象へ直接対応付ける。 表、脚注や注記を根拠とする場合は、対象行と適用範囲を対応付ける。 委譲報告を根拠とする場合は、採否を左右する項目を現物へ照合し、照合できた項目だけを選択肢へ使う。 完遂の可否と容量の不足は、本文と選択肢の前提から外す。実行環境が会話を自動で圧縮して継続するため、容量を理由に完遂できない状態は生じない。 所要時間とコストの許容範囲も同じく前提から外す。許容範囲を決めるのはユーザーであり、エージェントの判定対象ではない。 確認本文が現況を不整合、欠陥、漏れや未追随として述べる場合は、その現況の由来も実測する。由来がユーザーの選択であると判明した場合と判別できなかった場合は、その現況を維持する案を選択肢へ含める。 問い本文と各選択肢が名指しするコマンド、ツール及び設定項目については、そのセッションで公開契約（ヘルプ出力、入力スキーマ、公式仕様のいずれか）を取得してから選択肢を組む。取得した契約で選択が一意に定まる対象は、確認の対象から除いて自ら確定する。 操作、設定又は回避策を案内する案は、その実行経路が入力補正、既定値又は権限判定を適用した後に到達する状態を確定する。 設計文書の記載は手段の実在を裏付け、手段の効力は前項で確定した到達状態から判定する。 集合の外側に該当が無いことを含意する主張を本文へ書く場合は、母集団の総数、除外した分類ごとの件数と、除外の判定条件を同じ本文へ併記する。 除外の判定条件がユーザーの合意を得ていない技術判断である場合は、その判断そのものを選択肢の論点として示す。 同じ実装構造を共有する対象の一部を範囲から除外する場合は、その構造が生む外部可視の帰結で判定軸を構成する。観測済みの症状が再現しないことだけを除外の根拠とする形は、この判定軸の外に置く。 全ての選択肢が共通して前提とする事項のうち、ユーザーの発言が挙げた語をそのまま写したものは、`references/user-utterance.md`の例示解釈を適用して上位概念を特定し、その水準で成立する案を1件以上載せるか、載せない根拠を書く。 実装方式、アルゴリズム、データ構造など目的を達成する手段の比較を選択肢にする前に、その手段が満たすべき達成目標と受入条件を確定する。確定できない場合は、達成目標と受入条件そのものを確認対象とする。 目標と受入条件が未確定のまま手段を選ばせると、合意した手段の不成立が実装後まで判明しない。 エンドユーザーが観測する表示、通知又は帳票の文面案は、文面が主張する事象を表示実装の判定条件へ照合する。 両者が一致しない場合は、文面、判定条件、あるいは双方のどれを変更するかを同じ回答単位へ含める。 ### 候補の構成 問い及び選択肢の主題は、実装上の具体値と実装手段ではなく、その値と手段を導く方針、基準又は考え方へ置く。方針を主題とする場合は、対象の識別子、方針ごとに変わる外部可視の結果、その方針を採用した場合に実行する操作の要約を確認本文へ示す。実装手段そのものを主題としてよいのは、手段の違いが方針の違いへ写像せず、達成目標と受入条件を確定済みの場合に限る。この場合は、手段の違いが方針の違いへ写像しないと判定した根拠を確認本文へ書く。得た回答はその確認を超えて再利用できる方針として扱い、恒久的な成果物へ残せる粒度の方針を主題に選ぶ。 実装内部の値と手段を選ばせる問いは回答者が判断材料を持たず、恒久化できない粒度では同じ確認を繰り返す。 名称、識別子又は用語を選ぶ確認では、既存成果物が同じ機構へ用いる語を候補の生成元へ含める。 既存の語を候補へ載せない場合は、その理由を確認本文へ書く。 既存成果物と新しい成果物の関係を変える確認では、変更する側と依存の向きを比較軸に含める。 既存側を変更しない案を候補へ含め、成立しない場合はその理由を示す。 当該セッションで人間が確定した再利用可能な判断は、成果物名だけでなく、読み手、公開範囲又は主題などの適用区分へ対応付ける。 同じ適用区分を扱う後続の確認では、先行する確認ラウンドの判断を反映した案を1件以上載せる。 反映できない場合は、その理由を確認本文へ書く。 選択肢は候補を一覧で示し、技術的な最適案を第1選択肢に置く。第1選択肢を決める前に、その変更の想定利用者（エンドユーザー、ユーザー、その他の消費主体のいずれか）を特定し、その利用者にとっての理想的な動作を整理する。区分ごとの前提は`agent-toolkit/rules/01-agent.md`「役割分担」が定める。第1選択肢は、この整理の結論を反映した推奨案とし、確定した達成目標と受入条件を満たす案から選ぶ。選択の判断そのものをユーザーへ委ねる形は、確認の構成の外に置く。特定した想定利用者と、その利用者にとっての理想的な動作を確認本文へ示す。達成目標と受入条件を満たさない案を選択肢へ載せる場合は、満たさない受入条件を説明へ書く。 許容できる不便の範囲は想定利用者の区分で変わるため、区分を示さない選択肢では回答者が判断材料を持たない。要件を満たさない案を推奨すると、ユーザーがその案を選び、確定した受入条件を満たさない成果物が確定する。 ### 影響と回答単位 第1選択肢を決める前に、各案が持つ副次的影響を技術的な比較と並べて評価する。対象は、機密情報が残存する範囲、操作の可逆性、第三者が観測できる範囲、監査記録の残存及び外部通知とする。第1選択肢は、副次的影響の評価を含めて最良と判定した案とし、実装上の即応性だけで決めない。評価した影響が案ごとに異なる場合は、その差を選択肢の本文へ書く。 副次的影響を示さない選択肢では、ユーザーがその影響を知らないまま不可逆な操作等へ合意する。 案ごとに変わる外部可視の差（入出力、応答時間、表示順序、情報量、通知頻度など）を確認本文へ書く。 外部可視の差が本文へ現れないと、ユーザーは案を比較できず、回答後に同じ論点を確認し直す。 各案が変える値、文言又は挙動を保持し、採用後に追随が必要になる成果物を選択肢へ書く。 対象には、設計書、運用手順、ヘルプ、検体及び公開資料などを含める。 追随対象が無い案では、0件であることを明示する。 確認を発行する前に、その論点で確定を要する事項を列挙して回答単位へ含める。回答単位がその事項を欠くと、回答の直後にユーザーがその事項を指示する往復が生じる。 論点が値の保持先を含む場合は、対応する既存の保持機構を列挙して選択肢へ含める。値の指定をユーザーへ委ねる論点では、その値の候補案を1件以上同じ確認へ示す。 いずれの選択肢を選んでも残る外部可視の結果は、本件の範囲で許容するか別の要求単位として扱うかを同じ本文で一意に示す。 複数のユーザー依存事項は、各事項を単独で除外したときに他の事項の技術的成立性が変わるかを確認する。成立性が変わらない事項は別の質問又は選択欄へ分け、各事項への合意は個別の回答で判定する。提案全体への肯定は、各事項への個別合意の判定材料の外に置く。相互依存する事項は同じ確認単位に保ち、追加機構を用いない既存動作だけの案も同じ階層で比較する。 確認の発行前に、問い本文と各選択肢に現れる名詞が、ユーザーの発言に現れた語、一般に意味が一意な語又は同じ本文で説明した語のいずれかであることを確認する。該当しない語は説明するか置き換える。問い本文では、対象、機能及び検証手段の有無を別の事実として書き分ける。基準は`${CLAUDE_PLUGIN_ROOT}/share/rules-main.md`「ユーザー向け発話ルール」とする。 ## 確認経路 Codexで構造化質問を利用できない場合は、`references/codex-format.md`を全文読み、同書の固定形式で提示する。 ユーザーへ直接質問できるメインは、実行環境の構造化質問を使う。同一セッションで同期的なユーザー確認が回答なしで終わったことを観測した後は、同じセッションの以降の確認を`agent-toolkit:wi-standards`が定めるUWIへ記録し、その回答を得るまで進められない元項目だけを`atk wi hold`で保留する。実行環境の待機上限による回答なしをこの切替条件として扱うのは自律実行に限り、協調実行ではユーザーの後続発話を待つ。 委譲先は、必要な調査と検討を終えて確認事項又は事後承認の対象を確定した時点で、自身のturnの終端を待たず呼び出し元へ通知する。 通知には、判断対象、推奨案、代替案、根拠、影響範囲及びユーザーが観測する結果を含める。 `agents_server`の委譲先は本文をUTF-8ファイルへ保存して`atk agents notify --body-file=<絶対パス>`で送り、Claude Codeの`Agent`ツールの委譲先は`SendMessage`の`to: "main"`で送る。 通知後も回答に依存しない担当工程を続け、質問とUWI投入は呼び出し元へ委ねる。 呼び出し元は、通知が`${CLAUDE_PLUGIN_ROOT}/share/rules-main.md`「ユーザー向け発話ルール」の粒度を満たすかを検査し、不足時は同じ委譲先へ不足項目を返してから発行する。 確認を発行した主体は、ユーザーがその確認を棄却したこと又は承認要求を取り下げたことを観測した場合、同じ論点を`## 確認要否の判定`で判定し直す。ユーザーの選好に依存する場合は、その論点の解決を要する元項目を`hold`で保留したまま事前承認型UWIへ記録し、確認を要しない範囲に収まる場合は自ら確定して続行する。棄却と取り下げの観測は回答なしに当たらないため、以降の確認を同期的に発行しない切替の条件からは外れる。 事後承認では実施した変更をそのまま保ち、実施内容・根拠・影響・復元方法を確認本文へ書く。自律実行では事後承認型UWIを投入し、元の作業を継続する。 起動中のスキル・適用中の規範・ユーザー指示・承認済み計画が工程・対象集合・副作用を定める場合は、その範囲の実施を事後承認型UWIへ記録せず、通常の完了報告で実施結果を伝える。 定められた工程の内側で、規範から一意に導けない判断、ユーザーの選好に依存する代替、定められた範囲を変える操作を追加した場合は、その追加部分だけを本スキルの確認要否判定へ送る。 ## 回答後の状態遷移 回答の到達は、投入済みで未回答のUWIを保持している間、`agent-toolkit:delegation`の`references/waiting-and-monitoring.md`が定める経過時間起動の各回で`atk wi`により確認する。この確認も本節の起点とする。 回答済み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へ回答を配送して再開する。保持していない場合は、計画又は引き継ぎ記録から未完了工程だけを再開する。 状態変更コマンドの成功報告と警告の不在を各遷移の完了根拠とする。途中で失敗した場合は、成功済みの状態をそのまま残し、未完了の遷移から再開する。