bdd-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

BDD Plan

BDD 计划

Create a plan; do not implement it. Accept a rough idea, conversation, issue, PRD, or repository as input. Use behavior-driven development to make expected outcomes observable before prescribing code changes.

创建计划；不要实施该计划。接受粗略想法、对话、Issue、PRD 或代码仓库作为输入。使用行为驱动开发，在规定代码变更之前，使预期结果变得可观察。

Intake

需求收集

Before writing the plan, ask the user which policy the eventual implementer should follow when post-implementation verification finds gaps: automatic fix or show findings in the conversation and wait for a reply. Record the answer in the plan. Ask on every invocation, even when implementation will happen later.
Read the supplied material. When a repository is available, inspect its relevant code, tests, and agent instructions. Cite verified repository-relative paths in the plan; label proposed paths as proposed. Resolve conflicting sources with the user. Ask about missing decisions that change observable behavior; state minor assumptions explicitly.
Identify the main success path, relevant alternate paths, failures, and boundaries. For a bug fix, describe the current failure and corrected behavior in observable terms. Do not invent a fixed number of scenarios.

在编写计划之前，询问用户：最终实施者在实施后验证发现缺口时应遵循哪种策略：自动修复，或者在对话中展示发现结果并等待回复。将答案记录在计划中。每次调用时都要询问，即使实施工作将在之后进行。
阅读所提供的材料。如果有代码仓库，请检查其相关代码、测试和 Agent 指令。在计划中引用已验证的仓库相对路径；将拟议路径明确标记为“拟议”。对于相互冲突的信息，与用户共同解决。对于缺失且会改变可观察行为的决策，向用户询问；明确说明次要假设。
确定主要成功路径、相关备选路径、失败情形和边界条件。对于 Bug 修复，以可观察的方式描述当前失败行为和修正后的行为。不要设定固定数量的场景。

Plan contract

计划约定

Write one Markdown plan in the repository at a suitable path, or return Markdown in the conversation when no repository is available. Honor a user-specified path. Scale detail to the change. Include:

Objective, scope, sources, relevant current behavior, assumptions, and unresolved blockers.
Scenarios with stable
```
B-01
```
,
```
B-02
```
, ... identifiers. Use
```
Given / When / Then
```
, adding
```
And
```
or an examples table where helpful. State outcomes a user or external observer can distinguish; include setup and expected results precise enough to verify.
Give any explicit plan requirement that is not itself a scenario a stable
```
R-01
```
,
```
R-02
```
, ... identifier, so the final verifier can account for it.
Ordered implementation tasks sized so one agent can implement and verify each independently. Each task names the scenarios it serves, concrete work, genuine dependencies, and a verification step with expected results. Include relevant repository paths when known. Every scenario must map to implementation and verification work; every implementation task must serve a stated behavior or necessary constraint.
Completion criteria that cover the scenarios and any other explicit plan requirements.
A mandatory final task, after implementation, directing the implementing agent to dispatch one sub-agent to verify the implemented code against every scenario and every other plan requirement. The verifier must inspect relevant code, run appropriate tests or checks, and report
```
pass
```
,
```
fail
```
, or
```
unverified
```
for each scenario and requirement, with concrete code or test evidence. The implementing agent must show that report in the conversation; it writes no report file unless the user requests one.

In the final task, encode the user's selected gap policy:

Automatic fix: dispatch a different sub-agent to fix reported gaps, then another sub-agent to recheck affected scenarios and requirements. Repeat the fixer → new verifier cycle while progress is being made. If the same gap persists or a decision is needed, report the blocker to the user.
Show findings first: show the verifier's report in the conversation and wait for the user's reply before fixing gaps.

Before delivering the plan, check its scenario coverage, task links, dependencies, observable outcomes, and final verification task. Report the plan's location and material assumptions or blockers. The post-implementation verification is an instruction in the plan; run it only when implementation is actually complete.

在代码仓库中的合适路径下编写一份 Markdown 计划；如果没有可用的代码仓库，则在对话中返回 Markdown。遵循用户指定的路径。根据变更规模调整详细程度。计划应包括：

目标、范围、信息来源、相关的当前行为、假设和未解决的阻塞项。
使用稳定的
```
B-01
```
、
```
B-02
```
等标识符的场景。采用 Given / When / Then，并在有帮助时添加 And 或示例表格。描述用户或外部观察者能够区分的结果；包含足够精确、可供验证的前置条件和预期结果。
对于任何本身不是场景的明确计划要求，使用稳定的
```
R-01
```
、
```
R-02
```
等标识符进行表述，以便最终验证者能够逐一核查。
按顺序排列实施任务，并调整任务规模，使一个 Agent 能够独立实施和验证每项任务。每项任务都应列明其服务的场景、具体工作、实际依赖关系，以及带有预期结果的验证步骤。如果已知，应包含相关代码仓库路径。每个场景都必须映射到实施和验证工作；每项实施任务都必须服务于已明确描述的行为或必要约束。
覆盖所有场景和其他明确计划要求的完成标准。
强制包含一个实施后的最终任务，指示实施 Agent 派发一个 sub-agent，根据每个场景和所有其他计划要求验证已实施的代码。验证者必须检查相关代码、运行适当的测试或检查，并针对每个场景和要求报告
```
pass
```
、
```
fail
```
或
```
unverified
```
，同时提供具体的代码或测试证据。实施 Agent 必须在对话中展示该报告；除非用户要求，否则不写入报告文件。

在最终任务中编码用户选择的缺口处理策略：

自动修复： 派发一个不同的 sub-agent 修复报告的缺口，然后由另一个 sub-agent 重新检查受影响的场景和要求。只要仍在取得进展，就重复“修复者 → 新验证者”循环。如果同一缺口持续存在或需要作出决策，则向用户报告阻塞项。
先展示发现结果： 在对话中展示验证者的报告，并等待用户回复后再修复缺口。

交付计划前，检查场景覆盖率、任务关联、依赖关系、可观察结果和最终验证任务。报告计划所在位置以及实质性假设或阻塞项。实施后验证是计划中的一项指令；只有在实施真正完成后才能执行。