interview-and-create-plan

インタビューと計画の作成

強力なループは強力な計画によって成り立ちます。Ralph RLM ループは試行ごとに実際の時間とコストを消費し、すべてのワーカーはチャット履歴よりも権威あるものとして PLAN.md を引き継ぎます。このスキルはその計画を生成します。つまり、ループが実行できる、堅牢で容易に従える PLAN.md を、推測ではなくユーザーとともに作成します。

出力は、アクティブな計画ディレクトリ内の作成された PLAN.md です（正確な場所を取得するには opencode-ralph-rlm plan-path を実行してください — 名前付き計画レイアウトでは .ralph-rlm/plans/<active>/PLAN.md、レガシーモードではリポジトリのルートです）。これが存在すると（そしてブートストラップのプレースホルダーを含まなくなると）、start_loop は再ブートストラップをスキップし、それに対して直接試行 1 を開始します。

急いで書き始めないでください。インタビューと設計に関する議論こそが本質です。何かを書く前に、合意されたゴールと合意された形に到達してください。

プロセス

1. 理解する

何が起きているのか、そしてユーザーが実際に何を望んでいるのかを理解していることを確認してください。

• まだ行っていない場合は、リポジトリを探索してコードベースの現在の状態を理解してください。
• プロジェクトにドメインの用語集 / ボキャブラリーがあればそれを使用し、全体を通して使い続けてください。
• 計画または設計について、ユーザーに徹底的にインタビューしてください。ゴールは、コードが書かれる前にアイデアを徹底的に検証することです。

インタビューの戦術

• 用語の以前の使われ方に異議を唱える。 ユーザーが既存の言語と矛盾する用語を使ったときは、すぐに指摘してください。「あなたの用語集では『キャンセル』は X と定義されていますが、あなたは Y を意味しているようです — どちらですか？」
• 曖昧な言語を研ぎ澄ます。 ユーザーが曖昧な、あるいは多義的な用語を使ったときは、正確な正規の用語を提案してください。「あなたは『アカウント』と言っていますが、Customer と User のどちらを意味していますか？ これらは別のものです。」
• 具体的なシナリオを議論する。 ドメインの関係性が出てきたときは、具体的なシナリオで徹底的に検証してください。概念間の境界についてユーザーに precise さを強いるエッジケースを考案してください。
• コードと照合する。 ユーザーが何かがどのように動作するかを述べたときは、コードがそれに一致するか確認してください。矛盾を見つけたら、それを表面化させてください。「あなたのコードは Order 全体をキャンセルしますが、今あなたは部分的なキャンセルが可能だと言いました — どちらが正しいですか？」
• ドメイン自体を議論する — 言葉の根本的な意味、計画に関連する型 / プリミティブ、それらの相互作用、不変条件、および含意。
• 前提を表面化して述べる。 暗黙の前提を明示的にし、確認のためにユーザーに言い返してください — ドメイン、既存のコードの動作、データの形、外部システム、そして「完了」が何を意味するかについて。述べられていない前提は静かなリスクです。ユーザーが何かを見過ごしてうなずいたときは、二人が共有している前提を名指しし、それが成り立つか尋ねてください。どの前提に自信があり、どれが推測かをメモしてください。
• 成功基準について尋ねる。 成功はどのようなものですか？ 究極のゴールは何ですか？ 完了したことをどうやって知りますか？ （これは Definition of Done になります — そしてループの verify.command と整合するべきです。）

2. スケッチする

機能をテストする継ぎ目をスケッチします。

• 新しい継ぎ目よりも既存の継ぎ目を優先してください。可能な限り最も高い継ぎ目を使用してください。
• 新しい継ぎ目が必要な場合は、可能な限り高い位置でそれらを提案してください。
• コードベース全体での継ぎ目は少ないほど良く、理想的な数は 1 つです。

可能なソリューションをユーザーに提示して、レビューとガイダンスを求めてください — 特に、インタラクション、成功、不変条件、特定の重要な技術的決定、および API 設計のセンスに関して。

ゴールと提案するソリューションを明確に述べることができ、ユーザーがそれらについて同意していることを確認してください。

全体的な形 — ソリューション、マイルストーン、決定 — を提示し、ユーザーが理解して同意できるようにしてください。

特定のファイルパスやコードスニペットを含めないでください。 それらはすぐに古くなり、ループが再発見します。行番号ではなく、形と意図を説明してください。

3. 計画

調査と議論の後、計画を書きます。

• まず高レベルの目標とドメイン情報を記載します。
• 続いてステップバイステップの計画を記載します: マイルストーン、未解決の質問、成功基準、不変条件、リソース、ユーザーからの決定事項/引用、ブロッカー、および重要な注意事項/詳細。
• それは鉄壁で、簡単に従える/実装できるものであるべきです。

計画は、ループが PLAN.md を読み込むパスに書き込みます。リポジトリのルートを仮定しないでください — 名前付きプランのレイアウトでは、それは .ralph-rlm/plans/<active>/PLAN.md の下にあります。正確なパスを取得するには次を実行します:

opencode-ralph-rlm plan-path

そのパスに PLAN.md を書き込みます。ループが期待する見出しを維持してください — 少なくとも ## Goal、## Definition of Done、## Milestones — そして必要に応じて ## Assumptions、## Open Questions、## Invariants、## Decisions、## Notes を追加します。

計画が依拠する仮定を ## Assumptions に明示的に記載してください — 確認済みと未確認の両方について記載し、チャット履歴を持たない新しいワーカーがそれらを引き継げるようにします。重要かつまだ検証されていない仮定(例: 「API は X を返す」、「この関数には副作用がない」、「テーブルはすでにインデックス化されている」)については、まずそれをテスト/検証するための初期マイルストーンを追加してください — 安価なプローブは、何度か試みた後に誤った仮定を発見するよりも優れています。すべてが依存する未確認の仮定は、ループにとって単一最大のリスクです。

4. 検証コマンド(ループの停止条件)

ralph.json の verify.command は、ループに完了を伝える唯一のものです — これは毎回の試行後に実行され、終了コード 0 = 成功です。計画はこのコマンド次第でしか良くなりません。ですから、ユーザーとともに意図的に開発してください:

• それは実際に目標をテストするものでなければなりません — 単なる exit 0、何もしない処理、または機能に関係なく成功するビルドではいけません。それを Definition of Done に結び付けてください。
• それは決定論的で、かつ妥当な速さでなければなりません(毎回の試行で実行されるため)。
• 決定的に重要なのは、作業が完了する前の現時点で失敗するべきだということです — 実行して、レッドベースラインを確認してください。すでに成功するコマンドは、ループが即座に「成功」して何もしないことを意味します。

それを ralph.json に設定し(例: "verify": { "command": ["npm","test"], "cwd": "." } — ステップを連結するには ["bash","-c","…"] を使用)、一度実行して正しい理由で失敗することを確認します。「完了」を真に捉えるまで研ぎ澄ましてください。

5. レビュー

ユーザーと計画をレビューします: 詳細、具体性、順序、成功基準。

彼らが満足するまでループします。意見の不一致は、インタビューが終わっていないシグナルとして扱ってください — 戻って研ぎ澄まします。

6. 最終計画の書き込み

合意された最終 PLAN.md を(opencode-ralph-rlm plan-path の場所に)書き込みます。

• それがブートストラップのプレースホルダーテキストを含まなくなったことを確認します。
• Definition of Done が ralph.json の verify.command と一致していることを確認します — そのコマンドはループの「完了」に関する唯一の情報源です。
• ユーザーに計画の準備ができたことを伝えます: ralph-rlm/supervisor モデルに切り替えて「go」(または「start the loop」)と言います。スーパーバイザーは作成された計画を検出し、それを上書きせずに試行 1 を開始します。

ループへのハンドオフ

ここで生成されるもの	消費するもの
PLAN.md(目標、完了の定義、マイルストーン、不変条件)	すべてのワーカーの試行 — チャット履歴に対する権威
合意された成功基準	ralph.json の verify.command と一致すべき
未解決の質問 / 決定事項	スーパーバイザーとワーカー。解決したら update_plan で更新

RLM_INSTRUCTIONS.md(ワーカーのプレイブック)はループのブートストラップによって作成され、PLAN.md とは別のものです。何を構築するかは PLAN.md で指示し、ワーカーがどのように動作するかは RLM_INSTRUCTIONS.md で指示します。