plan-interrogate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Chinese

Drive a plan from sketch to commitment by resolving every open decision before any code is written.

推动计划从初步构想走向最终确定：在编写任何代码之前解决所有尚未决定的事项。

Restate the plan in one paragraph. Confirm with the user that this is the plan being interrogated. Do not proceed on a mis-restatement.
Extract the decision tree. Every branch point becomes a node. Mark each node as open (undecided) or resolved. A resolved node carries a source tag:
```
user
```
(the user answered),
```
inferred
```
(the codebase or an existing constraint settled it).
Resolve in dependency order. A node is ready when every node it depends on is resolved.
For each ready open node, ask exactly one question. Keep the question tight and binary or small-multiple-choice when possible.
Pair every question with a recommended answer and one sentence of reasoning. The user can confirm, pick a different option, or push back.
Before asking, check whether the answer already lives in the codebase, prior commits, or an existing doc. If so, skip the question and mark the node resolved with source
```
inferred: <path>
```
.
Exit only when zero nodes are open. Print the resolved tree as a flat list:
```
Decision - Choice - Source (user | inferred: <path>)
```
.

用一个段落复述计划。请用户确认当前审查的正是该计划。如果复述有误，不要继续。
提取决策树。每个分支点都成为一个节点。将每个节点标记为 open（未决定）或 resolved（已解决）。已解决节点带有来源标签：
```
user
```
（用户已回答）或
```
inferred
```
（代码库或现有约束已确定该节点）。
按依赖顺序解决节点。当某个节点依赖的所有节点均已解决时，该节点才可处理。
对每个可处理的未决节点，只提出一个问题。尽可能让问题简洁，并采用二元选择或小型多选形式。
每个问题都配有一个 推荐答案 和一句话理由。用户可以确认、选择其他选项，或提出异议。
提问前，检查答案是否已存在于代码库、历史提交或现有文档中。如果已存在，则跳过问题，并将节点标记为已解决，来源记为
```
inferred: <path>
```
。
仅在没有任何未决节点时退出。以扁平列表输出已解决的决策树：
```
Decision - Choice - Source (user | inferred: <path>)
```
。

Asking multiple questions at once. The user loses context and you lose the ability to react to each answer individually.
Asking before exploring. If a fifteen-second read would answer the question, read first.
Asking without a recommendation. A question without a stance is a survey; it offloads design onto the user.
Rolling past an unresolved node. If a dependency is not pinned, the downstream question is premature.

The interrogation produces three artifacts, not just answers. Offer to write each; do not force it.

Decision ledger (always). The resolved tree as a flat list:
```
Decision - Choice - Source (user | inferred: <path>)
```
.
CONTEXT.md
(when the interrogation surfaced project-specific terms). A short shared-language file: every domain term you and the user had to pin down, with a one-line definition in the project's own words. This is what stops the agent from using twenty words where one will do next session, and keeps names in code consistent. One term per line:
```
term - what it means here
```
. Point future sessions at it. On re-run, merge new terms in place rather than overwriting existing ones.
Decision records (for contested or hard-to-reverse nodes only). One short record per decision that a future reader would question: the context, the choice, the alternatives rejected, and why. Keep them in
```
docs/decisions/NNNN-slug.md
```
. Read the directory first and number from the highest existing record so two records never collide. Skip the obvious ones - a record for a trivial choice is noise.

询问过程会产出三项工件，而不只是答案。可以主动询问用户是否需要写入每项，但不要强迫。

决策账本（始终生成）。以扁平列表呈现已解决的决策树：
```
Decision - Choice - Source (user | inferred: <path>)
```
。
CONTEXT.md
（当询问过程发现项目特有术语时）。一个简短的语言共享文件：列出你和用户为了明确含义而需要界定的每个领域术语，并使用项目自身的措辞给出一行定义。这样可以避免 Agent 在下次会话中用二十个词表达本可用一个词说清的内容，并让代码中的命名保持一致。每行一个术语：
```
term - what it means here
```
。后续会话应参考该文件。再次运行时，将新术语合并到相应位置，而不是覆盖已有术语。
决策记录（仅针对存在争议或难以撤销的节点）。为未来读者可能质疑的每个决策写一份简短记录，包括背景、所选方案、被否决的替代方案及其原因。将记录保存在
```
docs/decisions/NNNN-slug.md
```
中。先读取该目录，并从现有最高编号继续编号，确保两份记录不会发生编号冲突。跳过显而易见的决策——为琐碎选择编写记录只会制造噪声。

The decision ledger the user can paste into the plan doc. No prose summary. No hedging. If the user declines to decide a node, mark it

DEFERRED

with the reason the user gave - this is not the same as open. When you write

CONTEXT.md

or a decision record, keep it in the project's language, not a generic template.

生成用户可以直接粘贴到计划文档中的决策账本。不要撰写散文式总结，不要给出模棱两可的结论。如果用户拒绝决定某个节点，则将其标记为

DEFERRED

，并附上用户给出的理由——这与 open 状态不同。编写

CONTEXT.md

或决策记录时，使用项目自身的语言，而不是通用模板。