mcpField
D
decision-debate

decision-debate

github.com/gasserane生産性3357 回インストール1 週間前に更新
リポジトリ

decision-debate について

見解が分かれる MEL/SRHR の設計判断を扱う、構造化されたディベートスキルです。複数の専門的視点が同じ論点を独立調査して一度討論し、Ane が判断するための統合案を作成します。スキル自体は決定やファイル変更を行いません。

主な機能

  1. 01争点となる判断の選別
  2. 02独立調査の並列実施
  3. 03専門的な分析視点の活用
  4. 04一度の反論ラウンド
  5. 05選択肢と意見の相違の整理

活用シーン

  1. 01不確かな MEL 設計案の比較
  2. 02意見の分かれる SRHR 判断を複数の視点で検討
  3. 03異論を残した提案の作成
  4. 04重大な判断で視点を5つに拡張

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/gasserane/personal-skills --skill decision-debate

インストール後、Claude Code で/decision-debateを入力して読み込まれたか確認します。

詳細

Decision-debate (MEL/SRHR)

MEL/SRHRに関する、異論のある設計上の判断について、独立した視点をAneに提示する正式な討論です。CLAUDE.mdの3つの視点のルールを実践します。複数のエージェントが、異なる観点から同じ判断について調査し、1回だけ議論したうえで、Aneが判断できるように結果を統合します。このスキル自体が何かを決定することはありません。

使い分け — このスキルを選ぶ場面

grillファミリーの違いは、テーマではなく方向性です。

  • decision-debate(このスキル):視点をAneに提示します。独立したエージェントが、Ane自身では答えを出していない、異論のある判断について調査し、議論します。答えが本当に不確かで、合理的な専門家の間でも意見が分かれる場合に限って使います。
  • /grill-mel:Aneから答えを引き出します。すでに傾いている設計を明確にするため、一度に1つずつ質問します。
  • brainstorming(superpowers):コード仕様に進む、まったく新しい構築のために使います。

実質的な影響のある、真に異論のある判断に限って使います。構築には決して使いません。答えがすでに分かっている場合は、/grill-melまたは/annを使います。成果物の作成がタスクの場合は、/annを使います。

実行前のゲート

エージェントを起動する前に、トークンを多く消費するため、次の2点を確認します。

  1. その判断が、単にAneにとって未知なだけではなく、本当に意見が分かれるものであること(合理的な専門家の意見が割れる)。
  2. それが構築や成果物の作成ではなく、判断であること。

どちらかを満たさない場合は中止し、/grill-mel、/ann、またはbrainstormingに切り替えます。

方法 — 3つのステージ

判断を1文で示し、Aneに確認してから、次を実行します。

ステージ1 — 独立したブラインド調査
  1. ペルソナを選びます。デフォルトは3人、重要度の高い判断では5人です。各ペルソナは、架空の人物ではなく、agent-improvements/agent_registry.mdにある実在の専門家の視点に対応させます。デフォルトの3つの視点は次のとおりです。
    • 方法論(評価設計/貢献可能性の見極めの立場):エビデンスから実際にどこまで言えるか?
    • 政治経済と脱植民地化(政治経済レビュー担当者の立場):誰の知識が重視され、データにはどのような権力関係があるか?
    • 実施可能性(ma-priorities/読み手の立場):現場の人々に実施できるか、MAに役立つか? 5人で実行する場合は、その判断に最も重要な残り2つの視点を追加します(例:ジェンダー変革、セーフガーディング、またはコスト/効率の視点)。
  2. ペルソナを1つのメッセージで起動し、並行して実行します(Viの並列ファンアウト機構)。各ペルソナには同じ判断ブリーフを渡しますが、異なる視点の役割を割り当てます。他のペルソナには知らせず、WebSearch、knowledge MCP、MEL Wikiを使って独立して調査させます。
  3. 各ペルソナから、立場、最も重要な理由を1つ、その根拠となるエビデンスを提出させます。引用基準を適用します。出典のない事実は作り出さず、⚠️を付けて示します。
ステージ2 — 1回の討論

各ペルソナに、他のペルソナがステージ1で示した立場を共有します。それぞれに、どこに同意し、どこで立場を変えず、その理由は何かを、短い反論として書かせます。討論は1回のみです。延々と応酬を続けてはいけません。

ステージ3 — Aneが判断するための統合

decision-memoの形式に沿って、読みやすいTier 1ブリーフを1つ作成します。

  • 背景 — 判断を1文で示し、なぜ意見が分かれるのかを説明します。
  • 選択肢 — 各選択肢について、ペルソナの見解に基づく最も有力な根拠を示します。
  • 合意点 — ペルソナの意見が一致した点を示します。
  • 真の意見の相違 — 曖昧にせず、見える形で残します。これが討論の価値です。
  • 推奨案 — 推奨する選択肢を示し、反対意見も併記します。
  • リスクと可逆性 — 推奨案に伴うコストと、撤回の難しさを示します。

書き込み禁止ゲート

この討論では何も決定しません。統合ブリーフの最後には、次の行をそのまま記載します。

決定が必要です。これは推奨であり、決定ではありません。

このスキルは、いかなる正規ファイルにも何も書き込みません。Wikiの編集、レジストリの変更、コミットするドキュメントの作成は行いません。Aneにブリーフを返したら終了します。決めるのはAneです。その決定を実行に移すのは、Aneが別の手順として行います。

スケール時のエスカレーション

非常に大規模なディベートで、決定論的なトークン制御が重要な場合は、代わりにWorkflowツールの審査パネル/並列パターンを使って、同じ3つのステージを実行します。ステージ1では複数のペルソナエージェントを並列実行し、その後にディベートステージ、統合ステージを行い、budgetで支出を制限します。Workflow経由の実行には毎回明示的なオプトインが必要です。このスキルがデフォルトのルーティング先です。

締めくくり

統合ブリーフをAneに渡して終了します。推奨案を採用したり、ファイルを編集したり、作成を始めたりしないでください。Aneが判断を下し、その決定の実行を望む場合は、/annまたは適切なビルダースキルを使う別のタスクです。

コメント