plan-it

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan It

制定计划

Plan from the reason outward: Why the change matters to its users, How it fits the current system, and What will be delivered in verifiable slices. Leave exact code, filenames, edit ordering, and naming to implementation unless they are part of the contract.

从“为什么”向外推演：Why 说明变更为何对用户重要，How 说明变更如何融入当前系统，What 说明将以可验证的切片交付什么。除非具体代码、文件名、编辑顺序和命名属于契约的一部分，否则这些内容应留到实施阶段再确定。

Boundaries

边界

Inspect only the instructions, code, tests, and configuration needed to resolve the planning decisions. Reuse current context rather than rereading it ceremonially.
Planning alone does not authorize product edits or persistent artifacts. Keep the plan in the conversation unless another location is approved.
Use the harness's planning support when it helps or is required. A short conversational plan is sufficient for a small, clear, low-risk change.
If asked only for feasibility, report approach, impact, risks, and go/no-go, then stop.

仅检查为解决规划决策所需的内容，包括说明、代码、测试和配置。复用当前上下文，而不是走形式般地重新阅读。
仅做规划并不授权修改产品或创建持久化产物。除非已批准使用其他位置，否则将计划保留在对话中。
在有帮助或必要时，使用 harness 的规划支持功能。对于小型、明确且低风险的变更，简洁的对话式计划即可。
如果只要求进行可行性评估，请报告方案、影响、风险和 go/no-go 结论，然后停止。

1. Establish the Why

1. 确立 Why

Before anything else, state who the change is for, what problem it solves for them, and what success looks like from their side. The Why is the source of the acceptance criteria and the test for scope.

The request must supply three things: the desired capability, the acceptance standard, and the user value. Ask only for what is missing; do not re-ask what the user already stated. When the user gives only a How ("add a column", "switch to X"), ask what it is for.

首先说明变更面向谁、解决他们的什么问题，以及从用户角度看成功是什么样的。Why 是验收标准的来源，也是判断范围的依据。

请求必须提供三项信息：所需能力、验收标准和用户价值。只询问缺失的信息；不要重复询问用户已经说明的内容。当用户只给出了 How（例如“添加一列”“切换到 X”）时，询问变更的目的。

2. Decide the How

2. 确定 How

If the repo has a verify skill, find the feature the request names in its feature map; its

Where it lives

section is the starting point for the code and its

Driving it

section for acceptance. Choose the approach in terms of the current system: which existing module, interface, or pattern it extends, what stays unchanged, and which trade-offs matter. Compare alternatives only when the choice matters. Stay abstract — no code, pseudo-code, or edit itinerary.

When the approach depends on something not yet observed — an external endpoint, a GPU path, a third-party permission, a deploy target — check it for real before committing the plan: one call or run that shows it works. A blocked dependency found here costs a question; found after building, it costs the build.

如果代码仓库提供了 verify skill，请在它的 feature map 中找到请求所命名的功能；其

Where it lives

部分是代码位置的起点，

Driving it

部分则是验收方式的起点。应结合当前系统选择方案：说明将扩展哪个现有模块、接口或模式，哪些内容保持不变，以及需要关注哪些权衡。只有在选择至关重要时才比较替代方案。保持抽象——不要编写代码、伪代码或编辑顺序清单。

如果方案依赖尚未观察到的内容，例如外部 endpoint、GPU 路径、第三方权限或部署目标，请在确定计划前实际检查并验证。通过一次调用或运行证明其可用。在此阶段发现受阻依赖只需提出一个问题；等到构建完成后才发现，则会付出整个构建的代价。

3. Cut the What into Slices

3. 将 What 拆分为切片

Deliver the work as an ordered list of slices. Each slice:

Outcome — a result a user or caller can observe.
Acceptance — how that outcome is demonstrated on the real system: the command, request, or user flow, and the observable result that counts as passing. Checks such as tests, typecheck, or lint support acceptance; they do not replace it.
Boundary — the modules or contracts it touches, and what it deliberately leaves alone.
Serves — which part of the Why it advances.

A slice that serves no part of the Why is cut, not deferred into the same branch. Size each slice so it can be committed, reviewed, and reverted on its own; if one would span several unrelated boundaries, split it. Order slices so each builds on a verified base.

将工作交付为有序的切片列表。每个切片包含：

结果 — 用户或调用者可以观察到的成果。
验收 — 如何在真实系统上证明该结果：相关命令、请求或用户流程，以及视为通过的可观察结果。测试、类型检查或 lint 等检查可以为验收提供支持，但不能替代真实验收。
边界 — 该切片涉及的模块或契约，以及明确不涉及的内容。
服务目标 — 该切片推进了 Why 的哪一部分。

如果某个切片无法服务于 Why 的任何部分，应直接删除，而不是延期并塞入同一分支。调整每个切片的大小，使其能够独立提交、审查和回滚；如果一个切片跨越多个互不相关的边界，应将其拆分。按照每个切片都建立在已验证基础上的顺序进行排列。

4. Settle Validation and Authority

4. 确定验证方式与授权

Test-first. Honor the user's choice or project policy; otherwise choose and state it. If TDD is chosen,
```
/implement-plan
```
follows
```
/tdd
```
for behavior-changing slices. Use test judgment to decide whether a new test adds coverage.
Project verification. Name the project's verify skill if it has one; otherwise state how acceptance will be driven for this kind of app, and suggest the user run
```
/create-verification-skill
```
.
Commits. Record whether each slice is committed automatically after it passes, or only on request.
Approvals. Surface new design decisions, destructive actions, or effects on shared or production systems that need approval. Ask only questions that block a sound plan.

测试先行。 遵循用户的选择或项目政策；否则由你选择并明确说明。如果选择 TDD，对于会改变行为的切片，
```
/implement-plan
```
应遵循
```
/tdd
```
。使用测试判断决定新增测试是否能够增加覆盖率。
项目验证。 如果项目提供 verify skill，请指明该 skill；否则说明如何针对此类应用执行验收，并建议用户运行
```
/create-verification-skill
```
。
提交。 记录每个切片是在通过后自动提交，还是仅在用户提出要求时提交。
审批。 明确指出需要审批的新设计决策、破坏性操作，或对共享系统、生产系统造成的影响。只提出阻碍形成合理计划的问题。

Output

输出

Scale detail to risk. A small change needs a few lines covering Why, How, and one slice. For a larger change:

markdown

undefined

根据风险调整细节。小型变更只需几行内容，覆盖 Why、How 和一个切片。对于大型变更：

markdown

undefined

Why

How

What

Validation and Authority

Risks and Open Decisions

undefined

undefined

Completion Criterion

完成标准

The plan states the Why, the How, and ordered slices that each have an observable outcome, a real-system acceptance check, a boundary, and a link to the Why; feasibility of unobserved dependencies was checked or is listed as a risk; test-first choice, verification method, and commit policy are recorded. No implementation has occurred under planning-only authority.

Once accepted, continue with

/implement-plan

. If the user already authorized a clear, low-risk implementation, the brief plan need not introduce another approval round; new design decisions still require approval.

计划应明确说明 Why、How，以及有序的切片；每个切片都应包含可观察的结果、真实系统上的验收检查、明确的边界，以及与 Why 的关联。对于尚未观察到的依赖，其可行性应已得到验证，或已列为风险；同时应记录测试先行的选择、验证方式和提交策略。在仅拥有规划权限的情况下，不得实施任何变更。

计划被接受后，继续执行

/implement-plan

。如果用户已经授权实施一项明确且低风险的变更，简要计划无需再引入一轮审批；但新的设计决策仍需要获得批准。