メニュー
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/skanehira/dotfiles --skill workflow-debateコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
実装ループ。/dev-spec が作成した GitHub issue (ゴール / 設計参照 / DoD / 非スコープ / 依存の thin 構成) を入力に、依存順に 1 件ずつ「implementer subagent → 統合レビュー → 修正 ≤2 ラウンド → PR → DoD ローカル実行 → merge → close」で自律実装するオーケストレーター。進捗は issue コメントに残し、詰まった issue は needs-human で駐車して次へ進む。人間の介入はエスカレーション時のみ。issue 作成後にユーザーが直接起動し、エスカレーション回答後の再開も本スキルの再実行で行う。「実装ループを開始」「issue を順に実装して」「残りタスクを自動で実装」などで起動。
設計ループ。ユーザーストーリー → UI スケッチ → ユースケース → 実現可能性検証 → PoC 検証 → 横断設計 (docs/design/DESIGN.md) → 機能設計 (docs/design/features/) → 設計チェック → issue ドラフトチェック → GitHub issue 生成 (親子構造) までを対話的に実行し、人間が issue を確認して実装ループへ引き渡す。 「設計フェーズを開始」「要件を整理したい」「計画を立てたい」「ユーザーストーリーを書きたい」 「技術的に実現できるか確認したい」「機能設計を書きたい」「issue に落としたい」などで起動。 docs/design/ の状態から途中再開・特定フェーズの部分実行も可能。 `cli` / `webapp` のプロダクトモード指定で CLI ツール開発時は UI スケッチ等を軽量化できる。 issue 作成後、/dev-impl がそれを 1 件ずつ実装する。
dev-spec を使わず議論しながら設計を固めるときの進行様式。議論中は決定台帳 (DESIGN_NOTES.md) だけを追記し、節目に dev-spec 互換の DESIGN.md (1 枚) + docs/design/features/ へゼロから落とし込む。「議論しながら設計したい」「設計の壁打ちを文書に残したい」「台帳に記録して」「設計書に落とし込んで」「一旦まとめて」などで起動。
SKILL.md を表示中
| name | workflow-debate |
| description | 複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。 |
複数のサブエージェントに異なる役割（観点）を与えて議論を反復させ、合意できる結論と残るトレードオフを抽出する。
ユーザーから議題と必要なコンテキスト（関連ファイル、前提条件、ゴール）を受け取る。不明確な場合は AskUserQuestion で確認する。
整理する項目:
議題の性質に応じて 2〜3 個のサブエージェントロールを動的に決定する。
| 議題タイプ | ロール候補 |
|---|---|
| 設計の妥当性 | 設計純粋主義 (SOLID/DDD 原理派) / 実用主義 (YAGNI 派) / 運用視点 |
| 実装方針の比較 | シンプル派 / 拡張性派 / 性能派 |
| 原因分析のセカンドオピニオン | 表層分析派 / 根本原因派 / システム全体視点 |
| アイデアの壁打ち | 推進派 / Devil's advocate / ユーザー視点 |
| トレードオフ判断 | 短期視点 / 長期視点 / コスト視点 |
議題が表に当てはまらない場合も、対立軸を明示できる 2〜3 ロールを作る。
ロールを決定したら、ユーザーに以下の形式で提示して承認を得る:
議題: <議題>
提案ロール:
- ロールA: <名前> — <立場と価値観>
- ロールB: <名前> — <立場と価値観>
- ロールC: <名前> — <立場と価値観>
AskUserQuestion で「この構成で議論を開始してよいか / 調整したいか」を確認する。ユーザーがロール変更を求めたら調整してから次へ進む。
各ロールに並列で意見を出してもらう。Agent ツールを subagent_type=general-purpose で複数同時に起動する（並列性を活かす）。
各サブエージェントへのプロンプトテンプレート:
あなたは「<ロール名>」の立場で議論に参加します。
<ロールの説明 — 何を重視し何を懸念するか。価値観を明確に。>
## 議題
<議題>
## 前提・コンテキスト
<フェーズ1で整理した情報、関連ファイルの抜粋、必要な背景>
## 求める出力
1. このロールの立場での主張 (1-3個)
2. 各主張の根拠
3. 想定される反対意見と、それへの応答
4. このロールが特に懸念する点
400字以内で簡潔に。冗長な前置きは不要。markdown 形式。
各サブエージェントの意見を読み、以下を整理する:
整理結果は内部で保持しつつ、ユーザーに簡潔に共有する（任意で追加論点があるか確認）。
各サブエージェントに他のロールの主張をフィードバックして反論・補足・修正を求める。並列起動。
前ラウンドのあなたの主張:
<前回の主張>
他ロールの主張:
- 「<ロールA>」: <主張>
- 「<ロールC>」: <主張>
特に以下の相違点について、あなたの立場から反論・補足してください:
- 論点1: <相違点>
- 論点2: <相違点>
求める出力:
1. 反論または同意/修正
2. 自分の立場を維持するか変更するかの判断
3. 譲歩できる点と譲歩できない点
300字以内。
各ラウンド後にフェーズ4 に戻って相違点を再抽出する。最大 3 ラウンドまで反復する（経験的に 2〜3 ラウンドで価値観の相違は表面化し、それ以上反復しても収束しないことが多いため）。
以下のいずれかで終了:
ユーザーに以下のフォーマットで提示する:
## 議論サマリ
### 議題
<議題>
### ロール構成
- <ロールA>: <立場>
- <ロールB>: <立場>
- <ロールC>: <立場>
### 合意できた点（結論）
- ...
- ...
### 残ったトレードオフ
- 論点: <論点>
- <ロールA> の主張: ...
- <ロールB> の主張: ...
- 判断材料: ...
### 推奨アクション
<議題に対する推奨>
理由: <根拠>
ユーザーが追加で深掘りしたい論点があれば、フェーズ5 から再実行する。
/dev-spec — 議論ではなく設計ループの中で要件を引き出したい場合 (フェーズ 6・7 が決めをその場で質問する)