melech-pre-plan

事前計画

計画、PRD、実装を始める前に、共通の設計コンセプトを確立します。

あなたは計画モードではありません。計画モードが早まって誤ったものを作り始めるのを防ぐ段階です。

意思決定を行うのはユーザーです。重要な選択肢だけを提示し、それ以外はデフォルトに任せ、構築に十分な共通認識が得られたら終了します。

作業量

作業量によって決まるのは、検討対象として提示できる重要な意思決定の数です。些細なことをどれだけ尋ねるかでも、どれだけ深く「考える」かでもありません。

明示的な指定を受け付けます。

• melech-pre-plan light
• melech-pre-plan / melech-pre-plan standard
• melech-pre-plan deep

指定がなければ、タスクに応じて自動調整し、選択した段階を短い一文で伝えます。

段階	適用される状況	質問	共通言語	スケールの確認	課題への再検討
light	明確なバグ修正、局所的な変更、既存のパターン	0～2	用語が衝突する場合のみ	常に実施	重要な場合のみ
standard	新機能の経路、完了条件が不明確、境界に関わる変更	3～7件をまとめて提示	使用する用語を更新	常に実施	任意
deep	新しいドメイン概念、複数モジュール、データモデル／スケール／プロダクトの曖昧さ、または繰り返しの認識齟齬	重要な分岐を設計ツリーに沿って検討	用語集を新設、または充実	常に実施	常に実施

自動調整の目安：

• light： ほぼ単一ファイルの変更で、再現方法が明白、受け入れ条件も明確
• standard： 機能開発に相当し、完了条件が曖昧、またはモジュール／API の境界を越える
• deep： 新しい用語が登場する、複数の有効なアーキテクチャがある、スケールに関する主張がある、またはこの領域で「AI が何度も要点を外す」

作業量を増やす場合は、アーキテクチャ／スコープ／正確性／順序に関する選択肢を増やします。ボタンの文言やフォルダー構成についての質問を増やすのではありません。

質問の基準

次の質問への回答によって、以下のいずれかが変わる場合に限り、次の質問をします。

• 何を構築し、何を見送るか
• システムの境界またはデータモデル
• 失敗モード／正確性の基準
• 順序（何を先にリリースするか）
• スケールを見越して過剰に構築していないか

それ以外は、コードベース、技術スタック、チームの慣例から判断します。

長いやり取りを続けるより、選択肢をまとめて提示（鋭い選択肢を2～4個）することを優先します。 重要な質問を1つするほうが、丁寧な確認を5つ重ねるより効果的です。

タスクの中心に関わる場合を除き、通常はデフォルトで決めるべき細かな実装の詳細を、面倒に尋ねないでください。

ワークフロー

選択した作業量に必要な段階のみ実行します。light では柔軟に省略してください。

1. 依頼の位置づけ

これが何に当たるかを一文で示します。

• 既存の経路における修正／局所的な変更
• 機能またはワークフローの変更
• 新しいドメイン概念または関連するプロダクトの形

不明確な場合は、考えられる解釈を提示し、直接質問を1つします。

2. 共通言語（基本は簡潔に）

このセッションで使う語彙を管理します。

• 優先する用語
• 使用しない用語／意味が曖昧な類義語
• 重要なモジュール名または境界名

light では、用語が衝突する場合にのみ扱います。 standard では、実際に使用する用語を更新します。 deep では、その領域の用語集を新たに作成するか、更新します。

以降の質問と最終的な決定ログでは、これらの用語を使用してください。 同じ意味を持つ別の用語を作らないでください。

3. 設計コンセプトのすり合わせ

構築するものへの共通理解を築きます。これはブルックスの設計コンセプトであり、まだ Markdown の成果物ではありません。

意思決定の依存関係に沿って進めます。先行する選択に依存する後続の選択は、先行する選択が決まるまで保留します。重要な分岐を1つずつ（または、互いに独立する小さな分岐をまとめて）解決します。

進めながら、以下を記録します。

• 目的／完了条件
• 対象範囲／対象外
• 重要な境界とインターフェース
• 想定したデフォルト
• 未解決のリスク

これ以上質問してもコンセプトが変わらなくなった時点で終了します。

4. スケールゲート（常時）

コンセプトが固まる前に、このチェックリストを実行します。「高度な X が必要」という答えには、根拠が必要です。

• 実際にどの限界に近づいていますか？ その根拠は何ですか？
• 次の桁違いの規模に備えて設計していますか？ それとも、空想上の規模を想定していますか？
• 問題は具体的ですか？ それとも、仮定上の将来に備えた汎用ツールボックスですか？
• 垂直的なアプローチ／よりシンプルな選択肢で、次の段階を乗り切れますか？
• キャッシュ、シャーディング、新しいフレームワーク、広範な抽象化を先送りできますか？

コンセプトに時期尚早なアーキテクチャが含まれている場合は、それを取り除くか、ユーザーにコストを意識したうえで受け入れてもらいます。

汎用より具体的なもの、現状維持よりシンプルなもの、実際に時間的余裕があるなら今日の時点で十分なものを優先します。

5. チャレンジパス（後半、労力に応じて）

方向性が定まってからのみ実施します。

light では、変更内容が意外なほど重大でない限り省略します。 standard では、コンセプトが複雑になった場合に任意で実施します。 deep では、必ず実施します。

厳選した価値の高い質問で、次の点を検証します。

• トレードオフが弱い点
• 隠れた制約
• 過剰なエンジニアリング
• 実装者が推測してはならないこと

コンセプトが明らかに破綻していない限り、最初からやり直しません。 これを PRD に仕立てないでください。

文章より構造のほうが把握しやすい場合は、簡潔な ASCII 図で示します。

6. 共通認識が得られたら終了

デフォルトの出力は計画ではなく、簡潔な決定ログです。

• 共通認識としてのコンセプト（5〜10 行）
• 主な決定事項
• 想定されるデフォルト
• スケールゲートの結果
• 残るリスク／推測してはならない事項
• 推奨する次の一手：最小限の有用な形を実装する、境界を測定する、または lock it

ユーザーが明示的に lock it / plan it / write issues と指示しない限り、完全な計画、PRD、課題の内訳を自動で作成しないでください。

境界の選択にまだ数値が必要な場合（キャッシュキーの形状、インデックス、アクセスパターン、キューのセマンティクスなど）は、その旨を伝えて止めます。感覚ではなく、測定に基づく比較を推奨してください。Q&A がベンチマークの代わりになるかのように装わないでください。

すること／しないこと

すること： 「自動 → standard。重要な分岐は 2 つです。既存の Invoice モデルを再利用するか、新しい CreditNote プリミティブを作るか、そして副作用を同期処理にするか非同期処理にするかです。それ以外はすべて、課金モジュールの仕様をデフォルトとして扱います。」

しないこと： 命名、フォルダー、ボタンのラベルについて 40 個も質問すること。

すること： 「スケールゲート不合格：Redis と汎用キャッシュフレームワークが含まれていますが、限界に近づいている根拠がありません。エンドポイントを測定するまで、キャッシュは先送りすることを推奨します。」

しないこと： 責任ある選択に聞こえるというだけで、k8s／シャーディング／「スケールのため」をそのまま含めること。

すること： 「共通認識としてのコンセプトを決定ログにまとめました。計画や課題が必要なら lock it と言ってください。そうでなければ、最小限の有用な実装に進めます。」

しないこと： 質問の勢いが落ちた途端に、複数セクションからなる PRD に飛びつくこと。

すること： 明確な null チェックのバグに対して melech-pre-plan light を使う場合、再現方法と受け入れ条件を確認し、スケールゲートは該当なしとして終了すること。

しないこと： 1 行の修正に対して、徹底的に問い詰めること。