decide-about-disagreements

意見の相違について判断する

モデルを選ぶ前に、分岐先を決めます。この判断支援は、現在のコーディネーターと直接ツールを使って実行されます。ワーカーには処理を割り当てません。

models-consensus が、共通の立場がないトピックを少なくとも1つ返した後に、このスキルを使います。これは判断支援であり、2回目の協議ではありません。スキルによって協議会の成果物が編集されたり、ユーザーの選択が実装されたりすることはありません。

結果の概要

1. 結果： 未解決のトピックごとに、簡潔な判断パケットを作成します。各パケットには、中立的なトピック、記録されたすべての参加者の意見、分析、異なる選択肢すべて、1つの推奨案、ユーザーの選択を含めます。
2. 次の担当者： ユーザーは、トピックごとに1つずつ選択肢を選びます。
3. 完了： 重要な未解決トピックがすべて、決定済み、明示的に保留、または awaiting_human のいずれかになっていること。トピックを黙って飛ばしてはいけません。
4. 境界： models-consensus を再実行したり、そのレポートや状態を変更したり、実装を開始したりしないでください。

作業中は意見の調査ではなく、推奨案を提示します。ユーザーは選択肢一式を求めているので、すべてを示したうえで、各パケットの最後に、選択の決め手となるトレードオフを添えて、明確な案を1つ提示します。

結果を読む

呼び出し元から渡されたインライン結果、またはその結果オブジェクト内にある永続化済みの結果パスのどちらでも受け付けます。どちらもない場合は、ホストのブロッキング質問ツールを使って、レポートまたは状態のパスを尋ねます。ディレクトリ一覧から最新ファイルを推測してはいけません。

1. レポートを主要な説明情報源として使います。モード、ステータス、ラウンド、参加者、有効なプロバイダーとモデル、収束状況、信頼度には状態オブジェクトを使います。
2. レポートと状態に必要な意見や解決内容が含まれていない場合に限り、生のラウンドファイルを読みます。不足を補う最小限のファイルだけを読み込みます。デフォルトでは、トランスクリプト全体を読み込まないでください。
3. 分析の前に、質問、セッション、モード、ステータス、成果物のパスを記録します。ステータスが complete でない場合は、記録されているとおりに、部分的、失敗、人による入力待ち、キャンセル、または上限到達と表示します。部分的な結果は最終的な合意ではありません。mode が欠落している場合、または interactive か autonomous を含む場合は、その値を対話モードとして扱います。利用可能なフィールドとレポートの見出しから協議会モードを導き出します。contradictions と material_gaps は poll、disagreement_points と convergence は debate、固定された協議会の判定見出しは personas を示します。モードを特定できない場合は、未解決と明示された項目だけを使用します。
4. 参加者の記録に忠実にします。 モデルまたはプロバイダーの名前を挙げるのは、結果にその有効な受領が記録されている場合だけです。要求された名前、プロンプト、参加者自身の申告から、有効なモデルを推測してはいけません。受領記録がない場合は、その参加者を未検証と表示し、報告された参加者名をそのまま保持します。
5. 上書きせず、明示します。 少数派の立場、未解決の注意事項、証拠の欠落、不正な参加者、プロバイダーの重複、共通のトランスポートに関する注記を見える状態に保ちます。票数が多くても、異論を消してはいけません。
6. ユーザーの言語に合わせます。英語では ASD-STE100 簡略化技術英語を使用し、ポルトガル語ではブラジルポルトガル語の簡単な表現を使用します。パス、列挙値、モデル名、短い引用証拠は変更しないでください。

意見が一致していないトピックを見つける

未解決の重要なトピックだけを抽出します。評議会が解決した点、すべての席が支持している点、またはユーザーがすでに決定した点については質問しないでください。これらはすでに決定済みの事項です。

以下のモード別フィールドを使用してください。フィールド名は、レポート、状態、またはインラインの結果に含まれる場合があります。

モード	質問する内容	質問しない内容
poll	未解決のcontradictions（C1など）、重要なpartial_coverage（P1など）、未解決のblind_spots（B1など）、および、意見が分かれたままであるか選択を変え得るunique_insights（U1など）。選択を変える未解決の留保事項も含めます。	consensusの論点と、両方の判定者が解決した論点。選択を変えられない付加的な論点は質問ではなく、留保事項です。
debate	範囲、動作、アーキテクチャ、コスト、またはリスクに重要な差があるdisagreement_points、ラウンド上限時のopen divergence、および証拠や前提についてユーザーの選択が必要なblocked_on_context項目。	方向性を変えない詳細の違いに関するfull_agreementおよびconverging。
personas	議長が解決していない「評議会内の対立点」にある重要な項目、およびユーザーの選択を妨げている盲点。	議長がすでに決着させた対立点。ユーザーが最終判断の再検討を明示的に求めていない限り、蒸し返さないでください。

古い形式やカスタム形式の結果については、周囲のテキストで未解決と示されている場合に限り、disagreements、open_points、remaining_objections、open_caveatsを受け入れてください。follow_up_questionsとevidence_gapsは、モデル間の意見の相違ではなく、証拠の不足として扱ってください。カバレッジまたは証拠の不足については、ユーザーの前提が必要な場合、または選択を変え得る場合に質問として含め、それ以外の場合は判断を妨げない留保事項として記載してください。

重要なトピックが残っていない場合は、結論を最初に示します。ユーザーによる選択は不要であると述べ、判断を妨げない留保事項があれば列挙してください。無意味な質問をしないでください。

トピックごとに1つの判断用パケットを作成する

結果の順序どおりにトピックを処理してください。結果で同じ判断事項だと示されていない限り、2つのトピックをまとめないでください。各トピックについて、ユーザーに質問する前に次のパケットを作成してください。

1. 中立的なトピックを示す

評議会の論点IDを使い、争点を1文で述べます。偏った表現は取り除いてください。例：C1: 確実な配信のために共有キューとアウトボックステーブルのどちらを選ぶか。

2. 記録された意見をすべて提示する

そのトピックについて意見を述べた席をすべて列挙します。席ごとに、次の内容を示してください。

1. 記録された席名
2. レシートで確認できる場合は、実際に使用されたプロバイダーとモデル
3. 分かりやすく述べた立場
4. その立場を裏付ける証拠、前提、またはリスク

全席の一覧に参加席が含まれているものの、そのトピックについて立場が記録されていない場合は、立場の記録なしと記載してください。生の出力がない、または不正な形式である場合は、提供された結果では確認できませんと記載し、証拠不足の内容を明示してください。沈黙を同意として扱わないでください。同じ実際のモデルを使用した席であっても、意見は分けて記載してください。多様性を示すため重複を明記しますが、意見の文章は削除しないでください。

3. 意見の相違を分析する

提供された質問とコンテキストを使い、選択を変え得る判断基準に照らして各立場を検討してください。動作、範囲、アーキテクチャ、コスト、運用上のリスク、可逆性、証拠の質、実装の負担など、結果から確認できる基準を優先してください。

次の3つのケースを分けてください。

1. 結論の相違： 席によって異なる方向を選んでいる。
2. 前提の相違： ある事実が分かれば、席の意見が一致する。
3. カバレッジの相違： ある席が追加のリスクや利点を指摘している。

各立場を裏付ける最も強い証拠と、その重要な弱点を示してください。単に多数決の数だけで席を評価しないでください。選択に必要な事実が結果にない場合は、証拠不足であると述べ、証拠を優先する選択肢を含めてください。

4. すべての選択肢を列挙する

番号付きの選択肢リストを作成します。議席、評議会、または元の質問から示された、相異なる方向性をすべて含めます。少数意見であっても、意味のあるものは有力な見解でない場合に残します。表現が重複している場合に限り、削除します。

次に、最善のアプローチが提案を組み合わせたものかどうかを検討します。組み合わせのほうが優れている場合は、Recommended synthesisという名前の新しい選択肢として追加し、どの立場からどの要素を取り入れたかを明記します。推奨は、リストにある選択肢を指さなければなりません。リストにない選択肢を推奨してはいけません。

5. 1つのアプローチを推奨する

次の簡潔な形式を使用します。

I recommend option <id>, because <decisive evidence and trade>. The strongest alternative is option <id>, but it costs <material cost or risk>.

これは推奨であり、意見調査ではありません。推奨は分析上の判断であり、多数派が正しいという主張ではありません。証拠が不十分な場合は、defer and collect <specific evidence>を推奨してもかまいません。推奨を覆すのに必要な最小限の証拠を明記します。

6. ユーザーに尋ねる

まず、ホストのブロッキング型対話質問機能を使います。Codex では、利用可能な場合は request_user_input を使用します。Claude Code では AskUserQuestion を使用します。それ以外の場合は、ホストの同等機能を使います。対話ツールがない場合、またはツール呼び出しに失敗した場合に限り、プレーンテキストを使います。

質問は1つのトピックに絞ります。推奨する選択肢を先に示します。質問は Which approach should we adopt for C1? のように、1文にします。

質問の前に、選択肢リスト全体を提示します。ツールが2つまたは3つの選択肢にしか対応していない場合は、推奨案と最有力の代替案を選択肢として提示し、それ以外のリスト内の選択肢や組み合わせはすべて、ツールの自由記述式の Other で受け付けます。物語部分で選択肢を隠してはいけません。ツールがすべての選択肢に対応している場合は、すべて含めます。

ユーザーが Other を選んだ場合は、入力されたテキストをそのまま記録し、リスト内の選択肢または新しい組み合わせに対応付けます。そのテキストが実行可能な内容でない場合は、焦点を絞った確認質問を1つ行います。ツールから回答が返されない場合は、推奨案をデフォルトで選択してはいけません。awaiting_human として停止し、対象のトピックを明示します。

続行と完了

回答を受け取るたびに、次の手順を行います。

1. ユーザーの選択を現在の応答コンテキストに記録します。ユーザーから別途、意思決定記録の作成を求められない限り、評議会レポートや状態には書き込みません。
2. ユーザーが別の選択肢を選んだ場合は、再度議論せず、その変更を明記します。組み合わせを選んだ場合は、その正確な範囲を改めて述べます。
3. 次に未解決のトピックへ進みます。解決済みのトピックを再び質問してはいけません。

最後は結果を先に示す形式で締めくくります。

1. 決定したトピックと、それぞれについてユーザーが選んだ選択肢。
2. 保留中のトピック、または awaiting_human のトピック。
3. ユーザーの選択と異なる場合は、当初の推奨。
4. 証拠の不足、議席への忠実性に関する制約、未解決の異論。
5. 結果またはユーザーの選択から必要性が示された場合に限り、次のステップを1つ。

受け入れ条件は、客観的に確認できます。重要な未解決トピックすべてにパケットがあり、各パケットに記録されたすべての意見と相異なる選択肢が示され、各パケットに推奨が1つあり、質問した各トピックについてユーザーの回答が記録されるか、明示的に awaiting_human とされ、ソース評議会の成果物が変更されていないことです。

注意点

1. 多数派であることは証明になりません。証拠と意思決定基準を使います。
2. 出力がないことは観察可能な不具合であり、合意ではありません。問題を明示し、安全な判断を妨げる場合は、まず証拠の収集を選びます。
3. 盲点があるからといって、必ず意見の相違があるとは限りません。意思決定を左右する場合、またはユーザーの前提を必要とする場合に限り、質問します。
4. モデルの正体を推測してはいけません。すべての帰属に議席への忠実性を用います。
5. 推奨を実装に変えてはいけません。このスキルは、ユーザーが選択、保留、または回答待ちの状態にした時点で終了します。