implement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Work the plan one thin slice at a time. A slice is the smallest piece that changes observable behavior.

When a spec exists at

docs/specs/<slug>.md

, its acceptance criteria are the plan: work criterion by criterion, and let the spec's non-goals fence every diff. A spec that still carries an

## Open decisions

section is a draft, not a plan: stop and route back to

drill

; implementation cannot start until the draft is settled.

Pick the smallest unfinished slice of the plan.
Write the test that fails for it. Test external behavior through the interface, never implementation details. If no failing test can be written, the seam is wrong: stop and fix the plan, not the test.
Write the minimum code that makes it pass.
Refactor only with tests green. Match the existing style of the surrounding code.
Repeat until the plan has no unfinished slices.

Rules:

On
```
main
```
or
```
development
```
, recommend a git branch before the first test and ask; the spec slug names it. Implementing on the base branch is the user's call to make, not yours to assume. A session already on a feature branch stays there.
One implementation at a time. Unlanded work is never abandoned for a new task on your own: name the options (finish and land it, land it partial, or park it) and let the user pick. Only
```
land
```
ends the work.
No production code before its failing test exists.
A test that passes regardless of the change protects nothing; grep-style string checks counterfeit falsifiability.
Keep every diff surgical: each changed line traces to the current slice.
The code that passes the test still meets the bar: walk the ladder before adding any (does it need to exist, does the stdlib or a native platform feature do it, does an already-present dependency, does one line) and never add a dependency for what a few lines cover; no premature abstraction, since three similar lines beat a wrong one; type-safe with no escape hatches; defensive at I/O boundaries, trusting inside; no silent fallback that hides failure; clear over clever, names that document themselves, comments that say what the code is now, not its history; delete what your change orphaned and flag dead code without removing it unasked.
Each slice's commit message names the criterion it satisfies and the why, not only the what: one line, imperative, lowercase. Stage the specific files, never
```
git add .
```
.
A bug or unexpected failure mid-slice routes to the
```
debug
```
skill; do not patch around symptoms.
Three failed attempts on the same slice stop the loop: escalate to the user with the criterion, what was tried, and the last error.
When the last slice lands, run the
```
verify
```
skill before claiming the work is done.
Deep mode (the
```
deep
```
skill is active): work only from the spec, criterion by criterion. No one-sentence plans.

每次按最小的功能切片推进方案。一个切片是能改变可观察行为的最小单元。

当

docs/specs/<slug>.md

中存在规格文档（spec）时，其验收标准即为执行方案：逐条完成验收标准，且规格文档中“非目标”部分需约束每一处代码差异（diff）。若规格文档仍包含

## Open decisions

章节，则说明它还是草稿，并非确定的方案：此时应停止当前工作，转而执行

drill

技能；在草稿确定前，不能开始实现工作。

选择方案中未完成的最小切片。
编写针对该切片的失败测试。通过接口测试外部行为，绝不要测试实现细节。如果无法编写失败测试，说明接口设计存在问题：停止当前工作，修正方案而非测试。
编写能让测试通过的最少代码。
仅在测试全部通过时进行重构。代码风格需与周边现有代码保持一致。
重复上述步骤，直到方案中没有未完成的切片。

规则：

在
```
main
```
或
```
development
```
分支上，在编写第一个测试前建议创建一个git分支并询问用户；分支名称以规格文档的slug命名。是否在基础分支上实现由用户决定，不要自行假设。若当前会话已在功能分支上，则继续在该分支工作。
一次仅进行一项实现工作。绝不要自行放弃未完成的工作去开展新任务：列出可选方案（完成并合并、部分合并或暂存），让用户选择。只有执行
```
land
```
技能才代表工作结束。
在对应的失败测试编写完成前，不要编写生产代码。
无论代码如何变更都能通过的测试毫无意义；类似grep的字符串检查会伪造可证伪性。
确保每一处代码差异（diff）都精准：每一行变更都对应当前处理的切片。
通过测试的代码仍需符合标准：在添加代码前逐步考量（是否真的需要这段代码，标准库或原生平台功能是否已实现，现有依赖是否能完成，能否用一行代码实现），绝不要为几行代码就能实现的功能添加依赖；不要过早抽象，三段相似的代码胜过一段错误的抽象；保证类型安全，无逃逸漏洞；在I/O边界处做防御性处理，内部逻辑可信任；不要使用会隐藏错误的静默回退；优先清晰而非巧妙，使用自文档化的命名，注释应说明当前代码的作用而非历史；删除因你的变更而废弃的代码，标记死代码但不要未经询问就删除。
每个切片的提交信息（commit message）需说明其满足的验收标准及原因，而非仅描述做了什么：单行、祈使句、小写。仅暂存特定文件，绝不要使用
```
git add .
```
。
若在处理切片过程中遇到bug或意外失败，转而执行
```
debug
```
技能；不要治标不治本。
若同一切片尝试三次仍失败，停止循环：向用户上报该验收标准、已尝试的操作以及最后一次错误信息。
当最后一个切片合并后，在宣称工作完成前执行
```
verify
```
技能。
深度模式（
```
deep
```
技能已激活）：仅依据规格文档（spec）逐条完成验收标准。不接受一句话式的方案。