implement-slice

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Build exactly one vertical slice, prove it in the running product, and commit it with the proof attached. One call is one slice; the next slice gets a fresh conversation. Progress lives only in git: a slice is done when its commit is on the branch.

精确构建一个垂直切片，在运行中的产品中证明其效果，并连同证明材料一起提交。一次调用只处理一个切片；下一个切片应开启新的对话。进度只保存在 git 中：当切片的 commit 位于该分支上时，这个切片才算完成。

Steps

Find the slices file: the path given,
```
spec/features/<slug>/slices.json
```
for a feature the user names, the only slices file under
```
spec/features/
```
, or ask.
```
<slug>
```
is its folder name; the branch is
```
slices/<slug>
```
. Read it and the spec it names.
Find the verify skill: a project skill that runs the product and records whether checks passed, and its feature map. With none, tell the user to run
```
/make-verify
```
and end the turn.
Get on the branch. A dirty tree stops the skill: list the files and leave them to the user. Switch to
```
slices/<slug>
```
and pull, or create it from the up-to-date default branch. Stop if the slices file or its spec is not committed on this branch, its
```
commit
```
is not an ancestor of
```
HEAD
```
, or the verify skill is not on this branch yet.
Pick the slice from the trailers on
```
<default-branch>..HEAD
```
:
bash
```
git log --format='%h Slice=[%(trailers:key=Slice,valueonly,separator=%x2C)] Pending=[%(trailers:key=Slice-Pending,valueonly,separator=%x2C)]' <default-branch>..HEAD
```
Done has
```
Slice: <id>
```
, pending has only
```
Slice-Pending: <id>
```
, ready has neither and every
```
blocked_by
```
done, blocked is the rest. With
```
--signoff <id>
```
, follow references/signoff.md instead. Refuse a named slice that is done, or blocked (name the blocker); take it if it is ready or pending (rework). With none named, take the lowest ready id. If every slice is done and the PR has no
```
## Branch review
```
yet, go to step 9; if nothing is ready, say what is pending or blocked by what, and end the turn. Open your reply with it, for example
```
Slice S3: Reject a malformed header (also ready: S5)
```
.
Build it from pointers only: the spec's claimed Behaviour entries and Seams, the slice's
```
seam
```
,
```
done
```
and
```
scope
```
, the verify skill and map, and
```
git show
```
of each blocker's commit. A missing seam file the spec does not mark new means the spec and slices need regenerating: stop. Build only what the slice claims. Each
```
done.automated
```
item is a verify item if the verify skill can drive it, otherwise a test item at the slice's seam. Add missing behaviour to the feature map in this commit; changing what it already says needs a
```
manual
```
verdict. When an edge case forces you off the spec, take the conservative option, note it as a deviation, and keep going.
Pass the gate against the code you will commit: the project's typecheck, lint and tests pass; a verify run (call the Skill tool with the verify skill's name) started after your last edit has its verdict filled in, no
```
fail
```
, and
```
pass
```
on every verify item; every test item has a passing test. Unclaimed checks may be
```
not driven
```
. On
```
fail
```
, fix and rerun, up to three different causes. A
```
manual
```
, or a verify item
```
not driven
```
, means the map, the slicing or the change is wrong: the user decides. On any stop, commit nothing, leave the diff, report the check, the causes tried and the run folders, and end the turn.
Review it: call the Skill tool with "review-change" and the arguments
```
HEAD --no-check
```
. Its fixes are ungated edits, so pass step 6 again. Fix any
```
blocks
```
finding, regate, and review once more; a second
```
blocks
```
, or no subagent available, stops the slice like step 6.

Commit and push one commit to

slices/<slug>

, subject the slice title:

text

Reject a malformed header

Slice S3 of spec/features/<slug>/spec.md, behaviours 4, 5.

Verify run 20260927-103133-773664: Done
- <verify item> -> <check heading>: pass
- <test item> -> <test file>: pass
Project checks: <each command>: pass

Deviations:
- <spec line or behaviour> - <what you did instead> - <why>

<the review-change block, exactly as returned>

Slice: S3

Deviations:

reads

- none

when there were none. A

hitl

slice lists its

done.manual

items under

Awaiting sign-off:

after the checks, with trailer

Slice-Pending: S3

. The first commit opens a draft PR to the default branch, titled as the spec, its body one line per slice (id, title, blockers) then

## Slices

. After each commit, append to

## Slices

### S3 - <title>

section with the short SHA and the commit body below the first line, trailer excluded.

Close the branch once every slice is done. Call the Skill tool with "review-change" and the default branch, the only review that sees duplication between slices, and check the branch against the spec yourself. Fix every
```
blocks
```
finding and spec gap, regate what the fixes touched, commit as
```
Address review
```
with proof and block, push, and append the block under
```
## Branch review
```
. Call the Skill tool with "pr-brief", then mark the PR ready for review.

查找 slices 文件：使用给定路径、用户命名的 feature 对应的
```
spec/features/<slug>/slices.json
```
、
```
spec/features/
```
下唯一的 slices 文件，或者向用户询问。
```
<slug>
```
是其文件夹名；分支为
```
slices/<slug>
```
。读取该文件及其指定的 spec。
查找 verify Skill：项目中用于运行产品并记录检查是否通过的 Skill，以及它的 feature map。如果没有，告知用户运行
```
/make-verify
```
并结束本轮。
切换到目标分支。 工作树不干净会阻止 Skill 执行：列出相关文件，并将它们留给用户处理。切换到
```
slices/<slug>
```
并 pull，或从最新的默认分支创建该分支。如果 slices 文件或其 spec 未提交到该分支、slices 文件中的
```
commit
```
不是
```
HEAD
```
的祖先，或者 verify Skill 尚未位于此分支上，则停止。
从
```
<default-branch>..HEAD
```
范围内的 trailers 中选取切片：
bash
```
git log --format='%h Slice=[%(trailers:key=Slice,valueonly,separator=%x2C)] Pending=[%(trailers:key=Slice-Pending,valueonly,separator=%x2C)]' <default-branch>..HEAD
```
Done 表示包含
```
Slice: <id>
```
，pending 表示仅包含
```
Slice-Pending: <id>
```
，ready 表示两者都没有且每个
```
blocked_by
```
都已完成，blocked 则指其余情况。使用
```
--signoff <id>
```
时，改为遵循 references/signoff.md。如果指定的切片已完成或被阻塞，则拒绝执行并指出阻塞项；如果它处于 ready 或 pending（返工）状态，则接受该切片。如果未指定切片，则选择 id 最小的 ready 切片。如果所有切片均已完成且 PR 尚无
```
## Branch review
```
，则转到步骤 9；如果没有任何 ready 切片，说明哪些切片处于 pending 状态或被什么阻塞，然后结束本轮。回复开头必须写明所选切片，例如
```
Slice S3: Reject a malformed header (also ready: S5)
```
。
构建切片时只能依据以下指针：spec 声明的 Behaviour 条目和 Seams、切片的
```
seam
```
、
```
done
```
和
```
scope
```
、verify Skill 及其 map，以及用于查看每个 blocker commit 的
```
git show
```
。如果缺少某个 seam 文件，而 spec 未将其标记为 new，则说明 spec 和 slices 需要重新生成：停止。只构建切片所声明的内容。如果 verify Skill 能驱动某个
```
done.automated
```
项，则它是一个 verify item；否则，它就是该切片 seam 处的 test item。在本次 commit 中将缺失的 behaviour 补充到 feature map；如果要更改 map 已有的描述，则需要
```
manual
```
verdict。如果某个 edge case 迫使实现偏离 spec，请采取最保守的方案，将其记为 deviation，然后继续。
通过 gate，且必须针对将要提交的代码：项目的 typecheck、lint 和 tests 均须通过；通过 verify Skill 的名称调用 Skill 工具启动的 verify run 必须在最后一次编辑之后开始，其 verdict 已填写，不含
```
fail
```
，且每个 verify item 均为
```
pass
```
；每个 test item 都必须有通过的测试。未被覆盖的检查可以标记为
```
not driven
```
。遇到
```
fail
```
时，修复并重新运行，最多针对三种不同原因尝试。如果出现
```
manual
```
，或者某个 verify item 为
```
not driven
```
，则说明 map、切片划分或变更存在问题，交由用户决定。因任何原因停止时，不提交任何内容，保留 diff，报告检查结果、已尝试的原因及运行目录，然后结束本轮。
审查变更：使用参数
```
HEAD --no-check
```
调用 Skill 工具，并指定
```
"review-change"
```
。它所做的修复属于未经过 gate 的编辑，因此必须再次执行步骤 6。修复所有
```
blocks
```
发现，重新执行 gate，再次审查；如果第二次仍出现
```
blocks
```
，或者没有可用的 subagent，则像步骤 6 一样停止该切片。

向

slices/<slug>

提交并 push 一个 commit，提交主题为切片标题：

text

Reject a malformed header

Slice S3 of spec/features/<slug>/spec.md, behaviours 4, 5.

Verify run 20260927-103133-773664: Done
- <verify item> -> <check heading>: pass
- <test item> -> <test file>: pass
Project checks: <each command>: pass

Deviations:
- <spec line or behaviour> - <what you did instead> - <why>

<the review-change block, exactly as returned>

Slice: S3

没有偏差时，

Deviations:

写为

- none

。对于

hitl

切片，在检查结果之后以

Awaiting sign-off:

列出其

done.manual

项，并使用 trailer

Slice-Pending: S3

。第一个 commit 会创建一个面向默认分支的 draft PR，标题与 spec 相同，PR 正文先按每个切片一行列出（id、标题、阻塞项），然后是

## Slices

。每次 commit 后，在

## Slices

下追加一个

### S3 - <title>

小节，其中包含短 SHA，以及 commit 首行以下的主体内容（不含 trailer）。

所有切片完成后，关闭该分支。使用默认分支调用 Skill 工具并指定
```
"review-change"
```
；这是唯一能够发现切片之间重复实现的审查，同时还要自行根据 spec 检查该分支。修复所有
```
blocks
```
发现和 spec 缺口，对修复涉及的部分重新执行 gate，以
```
Address review
```
为题提交并附上证明和审查块，push，然后将审查块追加到
```
## Branch review
```
下。调用 Skill 工具并指定
```
"pr-brief"
```
，然后将 PR 标记为 ready for review。

Report

报告

The slice and its state, the commit and PR, the verify run, the review's

Open

lines, any deviations, the PR's attention level after step 9, and what is ready next.

切片及其状态、commit 和 PR、verify run、审查中的

Open

行、所有 deviation、步骤 9 之后 PR 的 attention 级别，以及下一个就绪项。

Guardrails

防护规则

Push only to

slices/<slug>

, edit only its PR's body and

attention:

labels, and never force push or merge. The slices file, the spec, and what the feature map already says are read-only.

只允许 push 到

slices/<slug>

，只允许编辑其 PR 正文和

attention:

标签，绝不 force push 或 merge。 slices 文件、spec，以及 feature map 已有的内容均为只读。