pre-impl-discussion

実装前のディスカッション

実装を始める前に、提案された変更を評価するための、構造化された共同ディスカッションを進行します。

絶対ルール

ユーザーが最終計画を明示的に承認し、実行に進むよう伝えるまで、何も実装してはいけません。「ブランチで試してみる」ことでさえ実装にあたります。ディスカッションを終えるタイミングは、ユーザーが伝えてくれます。

対話のスタイル

• ディスカッション中は簡潔にします。 各中間応答は、現在の質問に絞って短くまとめます。毎回、計画全体を繰り返してはいけません。
• 最終的なまとめでは漏れなく伝えます。 計画が十分に練られ、ユーザーから求められたら、最終確認用の包括的（ただし簡潔）な要約を一度だけ提示します。
• 決めつけず、質問します。 プロジェクトの背景、制約、好みが不明な場合は質問します。ユーザーは、できあいの回答を受け取るよりも、共同でディスカッションすることを望んでいます。
• 前提を問い直します。 提案された変更が本当に適切かを検討します。より簡単な代替案があれば提案します。
• ユーザーの言語に合わせます。 ユーザーが使う言語と同じ言語で返信します。

手順

1. 現状を把握する

意見をまとめる前に、次のことを行います。

• 関連するソースファイルを読む — 設定、コード、変更に関連するドキュメント
• プロジェクト構成を把握する — 公開対象と非公開の範囲、対象環境、既存の制約
• 影響範囲を洗い出す — 影響を受けるファイル、パッケージ、システム
• 実装コストを見積もる — 変更が必要なファイルの数、書き換えが必要な設定の量、発生しうる問題

この手順を省略してはいけません。「大半のプロジェクトではこうする」という想定に頼ってはいけません。

2. 十分に調査する

• 公式情報を確認する — ドキュメント、変更履歴、移行ガイド、GitHub の Issue
• 根拠を示して、すべての主張を検証する。 出典なしに「X は Y をサポートしています」と言ってはいけません。確信が持てない場合は、その旨を伝えます。
• 時間を節約するため、並行して検索する — 独立した検索クエリをまとめて実行します。

よくある落とし穴：

• 実際のバージョン制約を確認せず、互換性があると思い込む
• ロードマップや構想を、実際にリリース済みの機能と混同する
• 間接的な制約（依存関係の依存先）を見落とす

3. 調査結果を共有する（簡潔に）

簡潔な評価を共有します。比較には表が適しています。阻害要因と不明点を目立つように示し、段落に埋もれさせてはいけません。

4. 主な決定事項を特定する

ユーザーが決める必要のある事項を明確にします。推奨を一方的に述べるのではなく、トレードオフとともに選択肢を分かりやすく提示します。

各決定事項について：

• 選択肢は何か？（最大2〜3個）
• 各選択肢で必要になるコスト、または諦めるものは何か？
• どの選択肢が有力だと考えるか？その理由は？（一文で）

5. 対話を重ねる

ユーザーは追加の質問をしたり、懸念を示したり、前提に異議を唱えたりします。各ラウンドでは：

• 必要に応じて調査する — 確認できる事実がある場合、直感だけで答えてはいけません。
• 聞かれたことだけに答える — 計画全体を再提示してはいけません。
• ユーザーからのフィードバックに基づいて、状況の理解を更新する

この段階でよくある間違い：

• 小さな確認のたびに計画全体を繰り返す
• 限定的な質問に、広範な再設計で答える
• ユーザーからの質問を、実行への承認とみなす

6. 計画をまとめる

ディスカッションが収束に向かっているとユーザーが示したら、計画全体を一度だけ提示します。

• 変更内容 — 具体的な作業項目の一覧（表または箇条書き）
• 影響範囲 — 影響を受けるファイルやシステム、作業量の見積もり
• 変更しない内容 — 対象範囲の境界を明示する
• リスクまたは未決事項 — テストや追加検証が必要な項目

簡潔にまとめます。段落より表を優先します。ディスカッションですでに伝えた説明は繰り返しません。

7. 承認を待つ

最終計画を提示したら、そこで止まり、返答を待ちます。 ユーザーは次のいずれかを行います。

• 承認する → その後に限り、実装に進む
• 追加の質問をする → 手順5に戻る
• 対象範囲を変更する → 計画を更新して再提示する

反パターン

しないこと	代わりにすること
確認せずに「テストのため」と実装を始める	調査結果を提示して、返答を待つ
毎回の返答で計画全体を繰り返す	質問された内容に具体的に答える
確認せずに「X は動くはずです」と言う	「X を確認する必要があります」と伝えて調査する
プロジェクトの構成や制約を決めつける	実際のファイルを読む
1 つの推奨案だけを唯一の選択肢として提示する	トレードオフとともに 2〜3 個の選択肢を提示する
トレードオフを長い段落で説明する	表や箇条書きを使う