Reference · User-invoked · 编排层 / 主流程施工段

implement 速查

主流程施工段的口袋版:从票到 commit。完整教学见 Lesson 0011; 原文见 SKILL.md(全文仅 15 行)、 agents/openai.yamldocs 叙事版

一句话

spec 或票描述的活干成代码:内部驱动 tdd 在约定接缝上写、 按三档节奏验证、收尾跑 code-review、commit 到当前分支。 它是手不是脑(hands, not head)——做什么在上游已经定了,它不重新决定。

何时伸手 / 何时别伸手

调用方式(两道锁,只能人敲)

五行正文解剖(全文就这些)

#原文(压缩)含义 / 挂着的厚文件
1Implement the work … in the spec or tickets输入只有 spec / 票两类;不重新决定做什么
2Use /tdd where possible, at pre-agreed seamsprose 调用 tdd;接缝上游定好,中途不发明。「where possible」是原词,默认姿态仍是 test-first
3Typechecking regularly, single test files regularly, full suite once at the end三档验证节奏,implement 自己唯一的规定;全量在 review 之前
4Once done, use /code-reviewprose 调用 code-review;Standards + Spec 双轴,commit 之前
5Commit your work to the current branch唯一落地动作;不开分支、不发 PR

继承的 tdd 纪律(施工期真实行为 = 五行 + tdd 全文)

会改什么 / 不会改什么

对象动不动说明
业务代码、测试文件写 / 改本职;测试落在约定接缝上
git制造 commit落在当前分支
工单系统正文没写不改票状态、不勾验收框;想要就自己加一行
分支 / PR正文没写合并与发 PR 是人的下一步
CONTEXT.md / ADR只读写它们是 domain-modeling 那条线

上下游

grill-with-docs → to-spec → to-tickets ─frontier─► implement ─► commit
triage ─agent-ready issue─────────────────────────►    │prose 调用
wayfinder ─(仅活真的小)─────────────────────────►    ▼
                                              tdd → code-review
一票一会话;下一步:下一张 frontier 票(新会话)或人工合并 / 发 PR

微调入口(症状 → 改哪里)