Discuss

• ユーザーの発言から「何を決めたいのか」を 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 個の意見を述べる（長文禁止）
• 他の意見に 遠慮なく反論・補足・代替案を提示する
• 犯人探しではなく仕組みの改善にフォーカス
• バイアスを外す: 「自分が推したい案」ではなく「事実から導ける案」

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

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

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

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

比較表を作る:

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

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

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

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 へ勝手に進まない

関連 Skill

• /plan — 議論で方針が決まったら次はこれ（W-01〜W-05）
• /review-pr — 実装された PR のレビュー（W-10.5）
• /retro — 完了後の振り返り