菜单
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
実装ループ。承認済みの DESIGN.md + DESIGN_DETAIL_APP.md + DESIGN_DETAIL_INFRA.md + TODO.md を入力に、TODO.md の全フェーズをレビュー・コミット込みで自律実装するオーケストレーター。人間の介入はエスカレ条件 (概要設計の破綻 P3 等) のみ。dev-spec の承認ゲート通過後にユーザーが直接起動する。エスカレーション回答後の再開も本スキルの再実行で行う。「実装ループを開始」「設計済み TODO で実装を自律実行」「残りタスクを自動で実装」などで起動。
設計ループ。ユーザーストーリー → UI スケッチ → ユースケース → 実現可能性検証 → PoC 検証 → DDD モデリング → 概要/詳細設計 (DESIGN.md / DESIGN_DETAIL_APP.md / DESIGN_DETAIL_INFRA.md) → 深掘りインタビュー → 検証手順補完 → TODO.md 生成までを対話的に実行し、承認ゲートで実装ループ (/dev-impl) へ引き渡す。 「設計フェーズを開始」「要件を整理したい」「計画を立てたい」「ユーザーストーリーを書きたい」 「技術的に実現できるか確認したい」「TODO.md を作りたい」「DESIGN.md を深掘りしたい」などで起動。 docs/ の状態から途中再開・特定フェーズの部分実行も可能。
ローカルの git 差分を 3 観点 (TDD / コード品質+ルール準拠+構造 / プロダクト readiness) で並列レビュー。本体ロジックは review-tdd / review-quality / review-product-readiness subagent に委譲し、本 skill はメインセッション向けの薄い orchestrator として「差分検出 → PHASE_CONTEXT 組み立て → subagent 並列起動 → 結果集約・整形表示 → 修正アクション選択」を担当する。セキュリティレビューは security-guidance プラグイン (Stop hook の LLM diff review + Edit 時の pattern 検知) に委譲しており本 skill の対象外。fatal 判定は本 skill では行わず、呼び出し側に任せる。
React 19 + Vite+ + TypeScript + Tailwind v4 のモバイル向け静的 SPA デモサイトを TDD で構築し、Cloudflare Workers へデプロイするワークフロー。localStorage でフロントのみ完結するデモに特化。「デモサイトを作りたい」「モバイル向け静的デモ」「SPA を作って Cloudflare にデプロイ」「静的プロトタイプを公開」「localStorage でフロントだけ完結」などで起動。
ローカルのコミット履歴と差分からDraft PRを作成する。ブランチ未作成・コミット未作成の状態でも、必要に応じてブランチ作成とコミットを行ってからPRを作成する。`.github/` にPRテンプレートがあれば内容を埋めて、なければ作業内容から本文を生成し、`AskUserQuestion`で作成可否を確認してから `gh pr create --draft` を実行する。「PRを出したい」「draft PRを作成」「プルリクを作って」「PR本文を生成」などのリクエストで起動。
Google Docs の読み書き。docs.google.com/document/... のURLが貼られたとき、「Googleドキュメントに書いて」「ドキュメントを読んで」「gws」などのリクエストで起動。
| 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 (フェーズ 8 深掘りインタビュー) — 議論ではなくインタビュー形式で要件を引き出したい場合