Back to Details

archie-implement

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implement

执行流程

One Task, from 
todo
to 
ready-for-review
, unattended. You dispatch sub-agents, read what they return, drive one fix round and report.
The engineer writes every line of feature code. Staying out of the diff is what makes your read of it honest, so the one diff you judge yourself is the fix round's, which you did not write. Requires 
/archie-tdd
and 
/archie-code-review
, and a missing one halts the run and is named — absorbing its step would put the reviewer's context and the engineer's diff in the same head.
单个任务从
todo
状态自动流转至
ready-for-review
状态，全程无需人工干预。你将调度子Agent，读取它们的返回结果，推动一轮修复并生成报告。
工程师编写所有功能代码。 不参与代码编写才能保证你对代码评审的客观性，因此你仅需评审修复轮次产生的代码差异——而这部分代码并非由你编写。依赖 
/archie-tdd
和 
/archie-code-review
，若缺少其中任意一项，流程将终止并提示缺失项——若直接合并缺失项的步骤，会导致评审者的上下文与工程师的代码差异混在一起，影响评审公正性。

Readouts

结果播报

Every dispatch ends in a readout — one lead line in your words, then the sub-agent's report verbatim beneath it:
md
**{step} — {the verdict, where each finding lands, and what you dispatch next}**

{the sub-agent's report, unaltered}
The lead line is the only part you write. Leave the body exactly as it arrived: a 
file:line
, a criterion's wording and a gate's command are what the user acts on, and a tidied paraphrase is where they go missing. Step 5's summary is for the user coming back to a finished run; readouts are for the user watching one.
每次调度都会生成一份结果播报——由你撰写一条总结性导语，下方附上子Agent的完整报告原文：
md
**{步骤} — {评审结论，包括每项发现的处理方式及后续调度安排}**

{子Agent的完整报告内容，未做任何修改}
导语是唯一需要你撰写的部分。报告主体需完全保留原始内容：
file:line
、评审标准的措辞以及准入指令都是用户需要执行的依据，若进行改写或转述，关键信息可能丢失。步骤5的总结供用户回顾已完成的流程，而结果播报则是为了让用户实时了解当前流程的进展。

1. Resolve the Task, record the baseline, clear the gates

1. 解析任务、记录基线、通过准入检查

You are handed one reference — 
3.2#1
or a path. Everything resolves from it: Epics are numbered directories nested under 
.archie/
, so 
3.2
is child 
02
of child 
03
of the root, 
#1
is 
tasks/01-<slug>.md
inside it, and the leaf's 
spec.md
sits beside the 
tasks/
folder.
No 
.archie/
at all is a repo that has never been planned. Say so and name 
/archie-architect
, which walks the planning steps from scoping through to Tasks, rather than inventing a Task from the reference. Implementing installs without Planning, so this is a state you will meet.
Read the task file — its demoable outcome, its acceptance criteria, its 
Blocked by
line and its 
Label
— and the leaf's 
spec.md
.
Record the run's baseline: 
git rev-parse HEAD
. Every diff this run reviews is measured from it, including the fix diff you judge yourself.
Three gates decide whether this run happens at all:
  • The blocking edges are met. Every Task on 
    Blocked by
    is 
    done
    . A Task built out of order is built against code that does not exist yet, and the diff reads as correct until its sibling lands.
  • The label is 
    ready-for-agent
    .     A 
    ready-for-human
    Task halts here and names 
    /archie-assist
    . Any other value, and a task file with no 
    Label
    line, halts and names what it found.
  • The tree is clean enough to read a diff off. Uncommitted work already in the tree lands inside every diff this run reviews. Say what is dirty and let the user clear it.
Then set the Task's 
Status:
to 
in-progress
.
Done when the Task and its Spec are in hand, the baseline SHA is recorded, all three gates have passed, and the status line reads 
in-progress
.
你将收到一个任务引用——例如
3.2#1
或路径。所有内容都将基于此引用解析：Epics是
.archie/
目录下的编号子目录，因此
3.2
对应根目录下
03
子目录中的
02
子目录，
#1
对应该目录下
tasks/01-<slug>.md
文件，而叶子目录中的
spec.md
文件位于
tasks/
文件夹旁。
若不存在
.archie/
目录，说明该仓库从未进行过规划。此时需告知用户并推荐使用
/archie-architect
，该工具会引导用户从范围界定到任务创建完成整个规划流程，而非根据引用凭空生成任务。执行流程的安装无需依赖规划流程，因此你会遇到这种未规划的状态。
读取任务文件——包括可演示的成果、验收标准、
Blocked by
行和
Label
字段——以及叶子目录中的
spec.md
文件。
记录流程基线：执行
git rev-parse HEAD
命令。本次流程中评审的所有代码差异都将以此基线为基准，包括你需要评审的修复轮次差异。
三项准入条件决定本次流程是否可以启动：
  • 阻塞任务已完成：
    Blocked by
    中列出的所有任务状态均为
    done
    。若任务顺序错误，将基于尚未存在的代码进行构建，代码差异在评审时看似正确，但后续同级任务合并后会出现问题。
  • 标签为
    ready-for-agent
    ：若任务标签为
    ready-for-human
    ，流程将在此终止并推荐使用
    /archie-assist
    。若标签为其他值或任务文件中无
    Label
    行，流程将终止并告知用户当前的标签状态。
  • 工作树足够清洁，可生成代码差异：工作树中未提交的内容会混入本次流程评审的所有代码差异中。需告知用户哪些内容未提交，让用户清理后再继续。
之后将任务的
Status:
设置为
in-progress
。
完成标志：获取任务及其Spec文件、记录基线SHA、通过所有三项准入检查，且任务状态更新为
in-progress
。

2. Build, test-first

2. 测试优先构建

Dispatch 
/archie-tdd
with the Task reference. It goes red at the Spec's seam, drives each unit it modifies, goes green, and runs the repo's lint, typecheck, test and build gates.
Read the gate results first. A red gate halts the run — a review and a fix round spent on a diff that does not build is the whole pipeline spent on nothing — so report the failing command and its output. A gate the engineer could not find travels into the final report as a gap, so the user knows which of the four vouched for this diff.
Hold the engineer's list of which acceptance criteria its tests cover. Step 5's test plan is built from it.
使用任务引用调度
/archie-tdd
。该工具会在Spec的衔接处触发失败，驱动每个被修改的单元，直至测试通过，然后执行仓库的lint、类型检查、测试和构建准入检查。
优先查看准入检查结果。若准入检查失败，流程将终止——在无法构建的代码差异上花费时间进行评审和修复完全是浪费资源，因此需报告失败的命令及其输出。若工程师未找到某项准入检查，需将其作为漏洞记录在最终报告中，让用户了解四项检查中哪些为代码差异提供了保障。
保留工程师记录的测试覆盖的验收标准列表。步骤5的测试计划将基于此列表生成。

3. Review, on two axes

3. 双维度评审

Invoke 
/archie-code-review
inline, in this conversation — not as a sub-agent. It fans out two sub-agents of its own, one per axis, and sub-agents cannot nest, so the fan-out has to happen at your level. Hand it the Task reference and the baseline SHA.
It returns two reports, Spec and Standards, side by side and unmerged. Relay both verbatim in one readout.
Every finding goes to the fix round or to the report — those are the only two destinations, so the pipeline runs to the end from here. Where a criterion was too ambiguous to judge, the reviewer says so as a finding and the run continues on the reading it reviewed against.
在当前对话中直接调用
/archie-code-review
——而非作为子Agent调用。该工具会自行调度两个子Agent，分别对应两个评审维度，但子Agent无法嵌套调用，因此需在你的层级进行调度。向其传递任务引用和基线SHA。
它将返回两份报告：Spec评审报告和标准评审报告，两者并列展示且未合并。需将两份报告完整转述在同一份结果播报中。
每项发现要么进入修复轮次，要么纳入最终报告——只有这两个去向，因此流程从这里开始将运行至结束。若某项标准过于模糊无法评审，评审者需将其作为发现记录，流程将基于已评审的内容继续推进。

4. One fix round

4. 一轮修复

Dispatch 
/archie-tdd
again, with the Task reference and both axis reports. One round, and only one. A second round on a diff one review and one fix could not settle is a loop, and the user's read is the faster way out.
The same skill fixes as built, so each fix arrives driven by a test and the gates run again over it — a fix merely applied is how untested behaviour lands in a diff that has already been reviewed. Spec and Standards findings are what the round is for; smells are the engineer's discretion inside it, being labelled judgement calls that never earn a round of their own.
Then you judge the fix diff yourself — 
git diff
from the baseline, read against the findings it answers. Review does not re-run: the diff is small, and you did not write it, so the reason a reviewer exists does not apply. What the fix did and did not resolve goes in the report in your own words, and anything still standing is named with its file and line. A gate the fix round turned red is reported red.
Skip this step when both axes came back clean.
Done when the fix round is spent and judged, or was not needed, and its readout is out with your own read of the diff as the lead line.
再次调度
/archie-tdd
，传递任务引用和两份维度评审报告。仅执行一轮修复。若经过一次评审和一轮修复仍无法解决问题，继续循环只会浪费时间，用户直接介入处理会更高效。
修复流程与构建流程使用相同工具，因此每项修复都由测试驱动，修复后会再次执行准入检查——仅手动应用修复会导致未测试的行为混入已评审的代码差异中。修复轮次的目标是解决Spec和标准评审中的发现；代码异味属于工程师的自主判断范畴，不会单独触发修复轮次。
之后你需要自行评审修复产生的代码差异——执行
git diff
对比基线，对照需要解决的发现进行评审。无需重新执行完整评审：修复的代码差异较小，且并非由你编写，因此评审者存在的合理性不受影响。需用你自己的语言在报告中说明修复解决了哪些问题、未解决哪些问题，并注明未解决问题对应的文件和行号。若修复轮次导致准入检查失败，需报告失败状态。
若两个维度的评审均无问题，可跳过此步骤。
完成标志：完成修复轮次并完成评审（或无需修复），且已发布包含你对代码差异的总结导语的结果播报。

5. Set the status and report once

5. 设置状态并生成最终报告

Set the Task's 
Status:
to 
ready-for-review
. 
done
is the user's word and only the user writes it, so the unattended phase never declares its own work finished.
Then one summary, the run in a single read:
md
_Implemented:_ {Task reference} — {Task title}
_Status:_ ready-for-review
将任务的
Status:
设置为
ready-for-review
。
done
状态仅能由用户设置，因此自动流程阶段永远不会自行宣告工作完成。
然后生成一份总结报告，将整个流程浓缩为一份结果播报：
md
_已执行:_ {任务引用} — {任务标题}
_状态:_ ready-for-review

Built

构建情况

{The seam the integration test sits at, the units it covers, and one line per gate with its result.}
{集成测试的衔接点、覆盖的单元，以及每项准入检查的结果（各一行）。}

Review

评审情况

Spec: {the findings, and which the fix round resolved} Standards: {the same, with smells marked as judgement calls} {Then the unresolved ones, file and line each.}
Spec评审: {所有发现，以及修复轮次解决的问题} 标准评审: {所有发现，代码异味标注为自主判断项} {未解决的问题，每项注明文件和行号。}

Test plan

测试计划

{One line per acceptance criterion:}
  • covered by tests — {criterion} — {the test that covers it}
  • walk it by hand — {criterion} — {the steps through the running app that show it, in order}
{每条验收标准对应一行：}
  • 测试覆盖 — {标准内容} — {覆盖该标准的测试用例}
  • 手动验证 — {标准内容} — {在运行的应用中执行验证的步骤，按顺序列出}

Left for you

待用户处理事项

{The unresolved findings, any gate that did not run, and every criterion needing a manual walk.}

**The test plan is the point of the report.** No browser drives this app during the run, so a criterion the unit and integration tests do not cover has been proven by nobody until the user walks it. Give the manual ones as steps someone can follow through the running app without reading the code.
{未解决的发现、未执行的准入检查，以及所有需要手动验证的标准。}

**测试计划是报告的核心**。流程执行期间不会驱动浏览器运行应用，因此单元测试和集成测试未覆盖的标准，在用户手动验证前无法确认其是否符合要求。对于需要手动验证的标准，需提供可直接按照步骤操作的流程，无需用户阅读代码。