interview-and-create-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Interview and Create Plan

访谈并创建计划

A strong loop depends on a strong plan. The Ralph RLM loop spends real time and money per attempt, and every worker inherits

PLAN.md

as authority over chat history. This skill produces that plan: a bullet-proof, easily-followed

PLAN.md

the loop can run against — created with the user, not guessed.

The output is an authored
PLAN.md
in the active plan directory (run

opencode-ralph-rlm plan-path

to get the exact location — it is

.ralph-rlm/plans/<active>/PLAN.md

in the named-plan layout, or the repo root in legacy mode). Once it exists (and no longer contains the bootstrap placeholder),

start_loop

skips re-bootstrapping and launches attempt 1 directly against it.

Do not rush to write. The interview and the design discussion are the point. Reach an agreed goal and an agreed shape before writing anything.

强大的循环依赖强大的计划。Ralph RLM 循环每次尝试都会消耗实际的时间和成本，而且每个 worker 都会继承

PLAN.md

，将其作为高于聊天历史的权威依据。此 skill 会生成该计划：一份经得起推敲、易于遵循的

PLAN.md

，供循环据此执行——它需要与用户共同完成，而不是凭空猜测。

输出是在当前活动计划目录中生成一份经过共同编写的
PLAN.md
（运行

opencode-ralph-rlm plan-path

可获取准确位置——在命名计划布局中为

.ralph-rlm/plans/<active>/PLAN.md

，在旧版模式下则为仓库根目录）。一旦该文件存在且不再包含 bootstrap 占位文本，

start_loop

就会跳过重新初始化，直接基于它启动第 1 次尝试。

不要急于编写。访谈和设计讨论才是重点。在写入任何内容之前，应就目标和整体方案达成一致。

Process

流程

1. Understand

1. 理解

Make sure you understand what is going on and what the user actually wants.

Explore the repo to understand the current state of the codebase, if you haven't already.
Use the project's domain glossary / vocabulary if present, and keep using it throughout.
Interview the user relentlessly about the plan or design. The goal is to stress-test the idea before any code is written.

确保你了解当前情况以及用户的真实需求。

如果尚未探索代码库，应先探索代码库，以了解当前状态。
如果项目中存在领域术语表或词汇表，应使用它，并在整个过程中持续沿用。
不厌其烦地就计划或设计访谈用户。目标是在编写任何代码之前严格检验想法。

Interview tactics

访谈策略

Challenge previous uses of terms. When the user uses a term that conflicts with the existing language, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
Sharpen fuzzy language. When the user uses a vague or overloaded term, propose a precise canonical one. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
Discuss concrete scenarios. When domain relationships come up, stress-test them with specific scenarios. Invent edge cases that force the user to be precise about the boundaries between concepts.
Cross-reference with code. When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
Discuss the domain itself — the fundamental meanings of words; the types / primitives relevant to the plan; their interactions, invariants, and implications.
Surface and state assumptions. Make implicit assumptions explicit and say them back to the user for confirmation — about the domain, how the existing code behaves, data shapes, external systems, and what "done" means. An unstated assumption is a silent risk; when the user nods past something, name the assumption you're both making and ask if it holds. Note which ones you're confident about versus guessing.
Ask about success criteria. What does success look like? What is the ultimate goal? How will we know it's done? (This becomes the Definition of Done — and should align with the loop's
```
verify.command
```
.)

质疑此前对术语的使用。 当用户使用的术语与现有语言体系冲突时，立即指出。“你的术语表将‘取消’定义为 X，但你似乎指的是 Y——究竟是哪一种？”
明确模糊表述。 当用户使用含糊或含义过载的术语时，提出一个精确的规范术语。“你说的是‘账户’——是指 Customer 还是 User？两者并不相同。”
讨论具体场景。 当涉及领域关系时，使用具体场景对其进行严格检验。构造边界用例，迫使用户精确定义各概念之间的边界。
与代码交叉验证。 当用户说明某项机制的工作方式时，检查代码是否一致。如果发现矛盾，应直接指出：“你的代码会取消整个 Order，但你刚才说可以部分取消——哪种说法才正确？”
讨论领域本身——包括词语的根本含义、与计划相关的类型或原语，以及它们的交互、不变量和影响。
揭示并陈述假设。 将隐含假设明确化，并复述给用户确认——包括对领域、现有代码行为、数据结构、外部系统以及“完成”含义的假设。未说明的假设就是潜在风险；当用户对某项内容点头略过时，应指出双方正在采用的假设，并询问它是否成立。注明哪些假设已有充分把握，哪些仍属于猜测。
询问成功标准。 成功是什么样的？最终目标是什么？如何判断工作已经完成？（这将构成 Definition of Done，并且应与循环的
```
verify.command
```
保持一致。）

2. Sketch

2. 勾勒

Sketch the seams at which you will test the feature.

Prefer existing seams to new ones. Use the highest seam possible.
If new seams are needed, propose them at the highest point you can.
The fewer seams across the codebase, the better — the ideal number is one.

Present possible solutions to the user for review and guidance — especially around interaction, success, invariants, specific important technical decisions, and API-design taste.

Make sure you can clearly state the goals and the proposed solutions, and that the user agrees with you on them.

Present the general shape — solutions, milestones, decisions — so the user understands and agrees.

Do NOT include specific file paths or code snippets. They go stale quickly and the loop will re-discover them. Describe shape and intent, not line numbers.

勾勒用于测试该功能的测试接缝。

优先使用现有接缝，而不是新建接缝。应尽可能选择最高层级的接缝。
如果必须引入新接缝，应尽可能在最高层级提出。
整个代码库中的接缝越少越好——理想数量是一个。

向用户展示可能的解决方案供其审阅和指导——尤其是交互方式、成功条件、不变量、具体的重要技术决策，以及 API 设计偏好。

确保能够清晰陈述目标和拟议方案，并确保用户对此达成一致。

展示整体结构——解决方案、里程碑和决策——让用户理解并认可。

不要包含具体文件路径或代码片段。 它们很快就会过时，而循环会重新发现这些内容。应当描述结构和意图，而不是行号。

3. Plan

3. 规划

After exploration and discussion, write the plan.

Lead with the high-level goals and the domain information.
Follow with a step-by-step plan: milestones, open questions, success criteria, invariants, resources, decisions/quotes from the user, blockers, and important notes/details.
It should be bullet-proof and easy to follow / implement.

Write the plan to the path the loop reads

PLAN.md

from. Do not assume the repo root — with the named-plan layout it lives under

.ralph-rlm/plans/<active>/PLAN.md

. Get the exact path by running:

bash

opencode-ralph-rlm plan-path

Write your

PLAN.md

to that path. Keep the headings the loop expects — at minimum

## Goal

## Definition of Done

, and

## Milestones

— and add

## Assumptions

## Open Questions

## Invariants

## Decisions

, and

## Notes

as needed.

State the assumptions the plan rests on explicitly in

## Assumptions

— both confirmed and unconfirmed, so a fresh worker (which has no chat history) inherits them. For any assumption that is load-bearing and not yet verified (e.g. "the API returns X", "this function has no side effects", "the table is already indexed"), add an early milestone to test/validate it first — a cheap probe beats discovering a wrong assumption after several attempts. An unconfirmed assumption that everything depends on is the single biggest risk to the loop.

完成探索和讨论后，编写计划。

先介绍高层目标和领域信息。
然后给出分步骤计划：里程碑、待解决问题、成功标准、不变量、资源、用户的决定或原话、阻塞项，以及重要说明和细节。
计划应当经得起推敲，并且易于理解和实现。

将计划写入循环读取

PLAN.md

的路径。不要假定它位于仓库根目录——在命名计划布局中，它位于

.ralph-rlm/plans/<active>/PLAN.md

。运行以下命令获取准确路径：

bash

opencode-ralph-rlm plan-path

将

PLAN.md

写入该路径。保留循环所要求的标题——至少应包含

## Goal

、

## Definition of Done

和

## Milestones

——并根据需要添加

## Assumptions

、

## Open Questions

、

## Invariants

、

## Decisions

和

## Notes

。

在

## Assumptions

中明确说明计划所依赖的假设——包括已确认和未确认的假设，以便让没有聊天历史的新 worker 继承这些信息。对于任何至关重要但尚未验证的假设（例如“API 返回 X”“此函数没有副作用”“该表已建立索引”），应尽早增加一个里程碑，优先测试或验证该假设——低成本探测比在多次尝试后才发现错误假设更有效。一个尚未确认且被everything依赖的假设，是循环面临的最大风险。

4. Verify command (the loop's stop condition)

4. 验证命令（循环的停止条件）

verify.command

ralph.json

is the single thing that tells the loop it's done — it runs after every attempt and exit 0 = success. The plan is only as good as this command, so develop it deliberately with the user:

It must actually test the goal — not just
```
exit 0
```
, a no-op, or a build that passes regardless of the feature. Tie it to the Definition of Done.
It must be deterministic and reasonably fast (it runs every attempt).
Crucially, it should fail right now, before the work is done — run it and confirm a red baseline. A command that already passes means the loop would "succeed" immediately and do nothing.

Set it in

ralph.json

(e.g.

"verify": { "command": ["npm","test"], "cwd": "." }

— use

["bash","-c","…"]

to chain steps), then run it once to confirm it fails for the right reason. Sharpen until it genuinely captures "done."

ralph.json

中的

verify.command

是唯一用于告知循环任务已经完成的机制——它会在每次尝试后运行，退出码 0 表示成功。计划的好坏取决于这条命令，因此应与用户共同审慎制定：

它必须真正测试目标——不能只是
```
exit 0
```
、空操作，或者无论功能是否存在都能通过的构建。它应与 Definition of Done 保持一致。
它必须具备确定性，且运行速度应当合理，因为它会在每次尝试时执行。
最关键的是，在工作尚未完成时，它现在就应该失败——运行它并确认得到红色基线。一条已经通过的命令会让循环立即“成功”，什么也不做。

在

ralph.json

中设置该命令（例如

"verify": { "command": ["npm","test"], "cwd": "." }

——可使用

["bash","-c","…"]

串联多个步骤），然后运行一次，确认它因为正确的原因失败。持续完善，直到它能够准确判定“完成”。

5. Review

5. 审查

Review the plan with the user: details, specifics, order, success criteria.

Loop until they are satisfied. Treat disagreement as a signal the interview wasn't finished — go back and sharpen.

与用户共同审查计划：细节、具体内容、执行顺序和成功标准。

持续迭代，直到用户满意。将分歧视为访谈尚未完成的信号——返回并进一步明确内容。

6. Write final plan

6. 编写最终计划

Write the final, agreed

PLAN.md

(to the

opencode-ralph-rlm plan-path

location).

Confirm it no longer contains the bootstrap placeholder text.
Confirm the Definition of Done is consistent with
```
ralph.json
```
's
```
verify.command
```
— that command is the loop's single source of truth for "done."
Tell the user the plan is ready: switch to the
```
ralph-rlm/supervisor
```
model and say "go" (or "start the loop"). The supervisor will detect the authored plan and start attempt 1 without overwriting it.

将最终达成一致的

PLAN.md

写入

opencode-ralph-rlm plan-path

返回的位置。

确认其中不再包含 bootstrap 占位文本。
确认 Definition of Done 与
```
ralph.json
```
中的
```
verify.command
```
一致——该命令是判断“完成”的唯一事实来源。
告知用户计划已经就绪：切换到
```
ralph-rlm/supervisor
```
model，并说“go”（或“start the loop”）。supervisor 会检测到经过共同编写的计划，并在不覆盖它的情况下启动第 1 次尝试。

Handoff to the loop

交接给循环

Produced here	Consumed by
`PLAN.md` (goal, definition of done, milestones, invariants)	Every worker attempt — authority over chat history
Agreed success criteria	Should match `verify.command` in `ralph.json`
Open questions / decisions	The supervisor and workers; update via `update_plan` as they resolve

RLM_INSTRUCTIONS.md

(worker playbooks) is created by the loop's bootstrap and is separate from

PLAN.md

. Steer what to build in

PLAN.md

; steer how workers operate in

RLM_INSTRUCTIONS.md

此处产出	后续使用方
`PLAN.md` （目标、完成定义、里程碑、不变量）	每次 worker 尝试——作为高于聊天历史的权威依据
已达成一致的成功标准	应与 `ralph.json` 中的 `verify.command` 匹配
待解决问题和决策	supervisor 和 worker；在问题得到解决时通过 `update_plan` 更新

RLM_INSTRUCTIONS.md

（worker 操作手册）由循环的 bootstrap 创建，与

PLAN.md

相互独立。在

PLAN.md

中指导构建什么；在

RLM_INSTRUCTIONS.md

中指导worker 如何操作。