decision-debate について
見解が分かれる MEL/SRHR の設計判断を扱う、構造化されたディベートスキルです。複数の専門的視点が同じ論点を独立調査して一度討論し、Ane が判断するための統合案を作成します。スキル自体は決定やファイル変更を行いません。
主な機能
- 01争点となる判断の選別
- 02独立調査の並列実施
- 03専門的な分析視点の活用
- 04一度の反論ラウンド
- 05選択肢と意見の相違の整理
活用シーン
- 01不確かな MEL 設計案の比較
- 02意見の分かれる SRHR 判断を複数の視点で検討
- 03異論を残した提案の作成
- 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点を確認します。
- その判断が、単にAneにとって未知なだけではなく、本当に意見が分かれるものであること(合理的な専門家の意見が割れる)。
- それが構築や成果物の作成ではなく、判断であること。
どちらかを満たさない場合は中止し、/grill-mel、/ann、またはbrainstormingに切り替えます。
方法 — 3つのステージ
判断を1文で示し、Aneに確認してから、次を実行します。
ステージ1 — 独立したブラインド調査
- ペルソナを選びます。デフォルトは3人、重要度の高い判断では5人です。各ペルソナは、架空の人物ではなく、
agent-improvements/agent_registry.mdにある実在の専門家の視点に対応させます。デフォルトの3つの視点は次のとおりです。- 方法論(評価設計/貢献可能性の見極めの立場):エビデンスから実際にどこまで言えるか?
- 政治経済と脱植民地化(政治経済レビュー担当者の立場):誰の知識が重視され、データにはどのような権力関係があるか?
- 実施可能性(ma-priorities/読み手の立場):現場の人々に実施できるか、MAに役立つか? 5人で実行する場合は、その判断に最も重要な残り2つの視点を追加します(例:ジェンダー変革、セーフガーディング、またはコスト/効率の視点)。
- ペルソナを1つのメッセージで起動し、並行して実行します(Viの並列ファンアウト機構)。各ペルソナには同じ判断ブリーフを渡しますが、異なる視点の役割を割り当てます。他のペルソナには知らせず、WebSearch、knowledge MCP、MEL Wikiを使って独立して調査させます。
- 各ペルソナから、立場、最も重要な理由を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または適切なビルダースキルを使う別のタスクです。