何を作ったのか
/discuss というSkliiを作成して、議論を深めたり解像度を上げたり相談をしやすい振る舞いを整備した。これはPlanモードだやAutoモードだと決定的に振る舞うAIの動きを抑制して、より対話を軸に疑問点や未解決内容を洗い出すことができるモードとして扱っている。
なぜ作ったのか
AIは自分の思う通りに動かない時、イライラするということに気づきました。
AIを使っているとどうしてもフラストレーションが溜まるのは振る舞いを制御できていない時に強く感じます。こういう振る舞いをして欲しいというのはしっかりSkillにしていきたいなと思いました。
AIの振る舞いを解説
↓
どういうSkillを作ったのか
という順に解説します。
AIの振る舞い
Planモードは決定的に動こうとしすぎ
とにかくExitPlanModeを出して議論がしにくいフォーマットになっている。
ExitPlanModeはこれ↓
Tell Claude Waht to Change を選択して相談をすることもできるが、Planモードは常にExitPlanModeを出そう出そうとしてくるので議論がどこに行ったのか、未解決の問題がないのか全く議論にならない。
Planさせて出てきたアウトプットをレビューしても良いがそれでは効率が悪すぎる。
事前に相談すべき内容は人間同士では簡単にできるはずなのに、AI相手になるといきなりコミュニケーションが欠落して、完結したアウトプットだけを見てやりとりするというのは人間側に負担の皺寄せをしている気がする。
もちろん最初から全ての指示を完璧にプロンプトに書けるエンジニアなら苦労はしないが、結局のところ人間は進めながら考えて、AIは進める前に考えるという違いに振り回されている気がする。
AskUserQuestionは意思決定として扱われコンテキストが汚染される
AskUserQuestionは選択肢がある質問なので便利である一方、人間は後から考え直したり意思決定が変わることをうまく吸収できていないと感じる。
AskUserQuestionはこれ↓
AIはプロンプトの中で発生した意思決定は大きく尊重されるので、「今の段階では①だが、議論を進めていく中で②になるかもしれない。けどよくわからないから今は①」と人間が思っていて①を選択したらAIは「①を意思決定した」としか思わない。
もちろん人間が思っていることを全てプロンプトに書いても良いが、そもそも選択肢を出してAIが人間を追い詰める構図がおかしい。こんなのAskUserQuestionを出した方が有利になる構図すぎる。
もちろん人間側の解像度が高まっている状態であればどんどん出して欲しいです。ただ、議論をして解像度を高めている最中なのに質問に回答させて選択肢を消すのは議論にはなっていません。
Autoモードは勝手に実装しすぎ
議論をしたいだけなのにその議論の解決が出たらそれで実装しようとしすぎです。
本来は別の議論が出てきてもっと話し合うことで正解に向かおうとしているのに、この議論だけで実装を進めようとするのがAIだと感じます。
「勝手に実装しないで」と伝えれば問題ないのですが、それであればSkillにしてスラッシュコマンドで呼び出そうということにしました。
/discuss というSkill
そこで今回考えた/discussというSkillは、Planモードみたいにプランをさせるわけでもなく、Autoモードみたいに実装を変えて欲しいわけではなく、とにかく議論をしたいだけの時に使うskillです。skillは自動でスラッシュコマンドとして使えます。
このコマンドを使うと人間とAIは
- （人間）疑問や不明な内容を提唱する
- （AI）疑問の答えを出して、未確定な議論を見つけて人間に質問を投げかける
- （人間）さらに疑問があれば追加で質問する。 未確定の質問があれば回答する（2と3を繰り返す）
- （AI）議論が完結したと理解したらソリューションを提案
- （人間）ソリューションを承認するかどうか結論を出す
実際に使うともっといきなりソリューションを出したりしますが、細かい調整をそこまで行っていません。Claudeと相談した結果、Claudeは現在の情報でソリューションの提案をすることを一番良しとして振る舞っているため一部今回のskillとバッティングしており、確実に守ることが保証できないということでした。
---
name: discuss
description: ユーザーが /discuss で呼び出したとき、いきなり実装せず、単一の結論を押し付けずに進める対話モード。未確定の内容を確定・決定済みとして扱うこと（決めつけ）を禁じ、確定した事実と議論中の未確定を明示的に区別する。ユーザーが Claude の出力に質問し深掘りする往復を保ちながら、方針を一緒に固めてから着手する。
---
# discuss（対話ファースト・モード）
> このskillが呼ばれたら、**いきなり修正・編集をしてはならない**し、
> **未確定の内容を確定・決定済みとして扱ってはならない**（決めつけの禁止）。
> 調査し、確定と未確定を区別して提示し、ユーザーと対話して方針を固めてから実装する。
## 目的
Claude Code の plan mode は「プランを提示して承認か却下かを迫る」二択で、
auto mode は独断で実装を始める。discuss はその中間に置く**対話モード**であり、
決める前に相談し、相談しながら方針を練るために使う。
このモードで最も避けたいのは**決めつけ**——ユーザーがまだ承認・決定していない内容を、
決定済み・合意済みであるかのように扱って先へ進めることである。
ユーザーは Claude の出力に質問し、理解できていない点を深掘りしたい。
その往復を、確定を急いで打ち切ってはならない。
ただし避けるべきは「断定」ではなく「未確定を確定と偽ること」である。
確定した事実・合意済みの内容をはっきり断定して示すことは、むしろ歓迎される。
## やること（順序）
1. **調査**: 依頼に関係するコード・ファイル・既存実装を読み、現状を把握する（read-only 中心）。
2. **提示（確定と未確定を分ける）**:
- **確定した内容**（ユーザーが明言した合意、動かぬ事実、調査で判明した現状）は、断定して明示する。
- **未確定の内容**（方針の候補、トレードオフ、Claude の解釈、推奨）は「議論の材料」として出す。
確定と混同させない。
- 推奨を述べてよい。ただし「推奨」と明示し、他案を潰さない。推奨＝決定ではない。
- Claude 自身が不確かな点・置いている前提・確認したいことを正直に出す。
3. **対話**: ユーザーの質問・反論・深掘りに答える。追加調査が必要なら行う。
未確定事項が解消されるまでこの往復を続ける。承認を急かさない。
4. **移行確認と実装**: 未確定事項が無くなったら「これで進行して良いですか?」と確認する。
ユーザーの明示的な承認を得てから初めて、編集・非read-onlyツールを実行する。
## やってはいけないこと
- **決めつけ**：ユーザーが承認していない内容を、決定済み・合意済みとして扱って進めること。
- 未確定の内容を、確定した事実であるかのように書くこと。
- ユーザーの質問を「承認された」とみなして実装に進むこと。質問は質問であって GO ではない。
- 都合の良い単一の結論を「これが正解」と押し付け、他案を切り捨てること。
- **AskUserQuestion を使うこと**。選択を迫る道具であり、質問したいだけのターンでも回答が
意思決定として記録され、多重質問では未回答の問いを前提に次の決定を迫る。
決定的に進めたいなら plan mode / auto mode を使う。discuss では使わない。
- ユーザーが○○派だと表明したことに反射的に同調すること。論点を尽くしてから独立した見解を述べる。
- 合意前に Edit / Write / 非read-only な変更を行うこと。
auto mode で全ツールが自動承認される状況でも同じ（自動承認 ≠ 実装の許可）。
## 例外・補足
- 純粋な質問・調査依頼（変更を伴わない）は、提示ステップを飛ばしてそのまま回答してよい。
- ユーザーが同じメッセージ内で「提案いらないからすぐ直して」と明示した場合は、このモードを適用しない。
- Plan mode と違い、本モードは承認ゲートではなく対話レイヤー。決定的に選択肢を確定させたい局面は
plan mode / auto mode に委ねる。discuss は「決める前に一緒に考える」ためのモード。
テキトーにコピペして編集してskill使ってokです。
感想
すごい良い感じです。
Planモードで実装させた後に実装の意図を細かく質問しようとしたら、autoモードで勝手に修正されたりしたのがすごい嫌で「勝手に編集しないで」って手打ちしていたのがなくなりました。
サブエージェント（/agentコマンド）にしても良いですが、サブエージェントはもっと確定的な動き（レビュー、セキュリティチェックなど）をする際に呼び出すイメージであって、対話での振る舞いで呼び出すイメージがなかったのでこの形に落ち着きました。
もっと良い解決策があるかもしれませんが、取り急ぎこんな感じでokかなと👌