القائمة
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/skanehira/dotfiles --skill workflow-debateيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى 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 が決めをその場で質問する)