discuss

name: discuss description: Multi-expert team discussion mode — no code changes, just analysis. Primary-source research, bias removal, simulation, hypothesis-driven. user-invocable: true argument-hint: '[議題] 議論したいテーマ or 検討事項'

/discuss — 議論モード

ユーザーが「議論したい」「深掘りしたい」「方針を決めたい」「認識合わせしたい」と言った時に呼ばれる、コードを書かずに分析するための統合 Skill。

このスキルが呼ばれる条件

以下のいずれかがユーザー発言に含まれる:

「議論したい」「議論しましょう」「深掘りしたい」
「方針を決めたい」「認識合わせ」「ブラッシュアップ」
「検討したい」「分析したい」「レビューしたい」
「修正はしないで」「コードは変更しないで」「提案のみ」
複数の選択肢を比較したい
そもそもの前提を疑いたい

やってはいけないこと（重要）

コードを書かない（ユーザーが明示的に承認するまで）
1 つの結論に飛びつかない（必ず複数視点を出す）
推測を事実のように書かない（「公式ドキュメント」「過去ログ」等の根拠を明示）
長すぎる前置きを書かない（議論の本題に素早く入る）

議論の進め方（1 つの目的を達成する一連のワークフロー）

ユーザーが提示した議題に対して、以下を この順で 実行する。

Step 0: 議題の理解

ユーザーの発言から「何を決めたいのか」を 1 文で言い換える
曖昧な場合は質問を返す（推測しない）

Step 1: プロジェクト文脈の把握

議題に関連するファイルを読む:

docs/reference/constraints.md（不変条件）
docs/adr/ の関連 ADR
docs/reference/tasks/lessons.md（過去の失敗パターン）
package.json / app.config.ts（技術制約）
docs/explanation/product_strategy.md（ビジネス視点）

Step 2: 1 次情報の調査（AGENTS.md §1.1 に従う）

議題に技術的な側面があれば:

WebSearch / WebFetch で公式ドキュメントを確認
GitHub Issues / Discussions を調査
ブログ記事は 1 次情報で裏取りするまで根拠にしない
「事実」と「推測」を明示的に分ける

Step 3: 6 人専門家チームの視点で分析

以下の 6 名の立場で議論する。ペルソナの差を出す:

#	役割	何を見るか
1	テックリード	技術実現性 / アーキテクチャ整合 / 負債リスク
2	QA エンジニア	テスト容易性 / デグレリスク / エッジケース
3	UX/UI デザイナー	ユーザー体験 / 操作性 / 一貫性
4	プロダクトマネージャー	ビジネス価値 / スコープ / 優先度
5	エンドユーザー代表	「実際使う人は嬉しい？」「不便？」
6	セキュリティ / リスク担当	セキュリティ / 法的 / データ保護

議論のルール:

各専門家は自分の立場で 1〜2 個の意見を述べる（長文禁止）
他の意見に 遠慮なく反論・補足・代替案を提示する
犯人探しではなく仕組みの改善にフォーカス
バイアスを外す: 「自分が推したい案」ではなく「事実から導ける案」

Step 4: 複数アプローチの比較

最低 2 つ、可能なら 3〜4 つのアプローチを出す:

【アプローチ A】: 名前 + 概要
- 実装方法
- 変更するファイル数の目安
- Pro / Con

【アプローチ B】: 名前 + 概要
...

比較表を作る:

評価軸	A	B	C
実装コスト	◎/○/△/×
UX 改善度
リスクの低さ
保守性
既存コードとの整合性
テストのしやすさ

Step 5: リスクアセスメント + なぜなぜ分析 5 段階

最も重大なリスクに対して:

問題: [議題の根本的な問題]
├─ なぜ 1: なぜこの問題が起きているのか？
│  └─ なぜ 2: なぜその状況が生まれたのか？
│     └─ なぜ 3: なぜその状態になっているのか？
│        └─ なぜ 4: なぜ放置されていたのか？
│           └─ なぜ 5: なぜ防ぐ仕組みがなかったのか？
└─ 根本原因: [1 文]
└─ 恒久策: [仕組みとして何を導入するか]

恒久策は mechanism 3 点セットを満たすこと: ①tool (script / hook / テンプレ) ②adoption (どの手順がそれを強制するか) ③auditing (効いたかを何で確認するか)。tool だけの恒久策は good intentions 止まり (Amazon mechanism thinking、Sess103 retro 由来)。

Step 6: シミュレーション

「この案を実装したらどうなるか」を時系列で書く:

Day 1: 何が変わる？
Week 1: どんなフィードバックが来そう？
Month 1: 副作用は？
想定外のケース: 何が壊れる可能性？

Step 7: 表面化していない問題の洗い出し

「ユーザーが言及していないが実は重要な問題」を 3〜5 個挙げる:

前提条件の見落とし
既存機能への影響
保守コスト
リリース後の運用
他のチームメンバー（存在すれば）への影響

Step 8: チーム推薦と質問

6 人の議論結果から 1 つの推薦を出す
反対意見があれば必ず述べる
ユーザーに決めてほしい項目を明示的に質問する
「次のアクション」を 3 つ以内で提示

出力フォーマット（必須）

## 議論: [議題名]

### 前提の確認

- ユーザーの意図: ...
- 関連する不変条件 (constraints): ...
- 関連する過去決定 (ADR): ...

### 1 次情報調査

- 公式ドキュメント: [URL]
  - 重要な事実: ...
- GitHub Issue: [URL]
  - 類似問題あり: ...
- 「事実」として確認できたこと:
  1. ...
  2. ...
- 「推測」として残るもの:
  1. ...

### 6 人チーム議論

**テックリード**: ...
**QA**: ...
**UX**: ...
**PM**: ...
**エンドユーザー**: ...
**セキュリティ**: ...

### アプローチ比較

| 軸  | A   | B   | C   |
| --- | --- | --- | --- |
| ... |     |     |     |

### 根本原因分析

問題: ...
├─ なぜ 1: ...
...
└─ 根本原因: ...
└─ 恒久策: ...

### シミュレーション

- Day 1: ...
- Week 1: ...
- 想定外: ...

### 表面化していない問題（5 つ以内）

1. ...
2. ...
3. ...

### チーム推薦

採用: [A / B / C]
理由: (2〜3 文)
反対意見: ...

### ユーザーへの質問

1. [決めてほしいこと 1]
2. [決めてほしいこと 2]

### 次のアクション候補

1. ...
2. ...
3. ...

終わり方

コードの変更は一切しないで終わる
ユーザーが「上記認識合っています。進めてください」と承認したら、別の Skill（/plan → /implement）に切り替える
承認なしに /plan や /implement へ勝手に進まない

--from-ship 自走モード (ADR-0065)

/ship から --from-ship 付きで呼ばれた場合は終わり方が変わる:

単独起動時: 上記「終わり方」のとおり、議論結果を提示して user 承認待ちで hand-back する。
--from-ship 時: 議論は設計判断のためなので、hand-back せず 結論を /ship の Phase 2 (承認集約 = AskUserQuestion 1 回) にそのまま引き渡す。/discuss 単独では承認を取らない (= 承認は /ship が 1 回に集約する)。次工程 (/plan) へ自動継続する前提で結論を構造化する。
どちらのモードでも コードは書かない (議論のみ) のは不変。