build-by-story

临时路径：解析 FEATURE_CODE / <CODE>，然后遵循 templates/skills-ephemera-paths.md（功能根目录 .skills/<CODE>/）。按以下顺序解析包种子，使用第一个存在的路径：(1) 与此 SKILL.md 同目录的 templates/，(2) 设置了变量 ${CLAUDE_PLUGIN_ROOT} 时使用 ${CLAUDE_PLUGIN_ROOT}/templates，(3) 相对于此 SKILL.md 的 ../../../templates。

按故事构建

推动已批准的 story-unit 计划完成：从需求故事推导评审单元，在每个单元内运行共享的持续调度器，每个单元结束后暂停并等待人工评审，再根据单元台账恢复执行，最后进行整个分支的评审。

没有单元屏障的持续多任务编排称为 build-in-waves。 由控制器直接实现、无需子 Agent 的模式称为 build-inline。调用此技能即选择 story-unit 执行模式；持续模式的交接方式见下文的模式归属。如果用户不想使用子 Agent，请指定 build-inline。

共享控制器流程： 必须使用子技能 execute-common——这是预检、台账、待办事项和收尾工作的唯一归属，并按下方各设置步骤的说明应用。本文件负责 story-unit 屏障和单元推导；加载 ../execute-common/task-lifecycle.md 以进行任务分派和评审，并在每个单元内使用 build-in-waves 的持续调度器规则。

叙述： 工具调用之间最多只写一行简短说明。记录以台账和工具结果为准。

铁律

NO NEXT UNIT WITHOUT HUMAN UNLOCK (OR A WRITTEN MODE CHANGE)

Agent 评审通过不等于解锁人工评审。一天结束、演示压力以及“整个 PR 以后再评审”都不能取消屏障。“别再停下”属于模式变更：必须先在 tasks.md 中写入 Execution-mode: continuous，才能取消屏障。

铁律（story-unit）

1. 评审单元必须推导得出，不能在 tasks.md 中编写（划分单元时忽略 PM 的“人工评审顺序”注释）。
2. 每个单元的任务通过检查后：单元 Agent 评审 → 暂停并等待人工评审 → 解锁。
3. 查看后说 “continue” = 仅执行下一个单元。说 “stop stopping” / “just run it all” = 必须先在 tasks.md 中写入 Execution-mode: continuous，再将剩余工作交给 build-in-waves。只在聊天中说不算模式变更。
4. 台账中的 Unit <k>: complete (tasks …, range <base>..<head>) 用于恢复执行。
5. 最后一个单元完成后，仍须进行整个分支的 Agent 评审。各单元的人工评审不能替代它。

想法	实际情况
“用户说继续——不用编辑 tasks.md”	“别再停下”属于模式变更；必须写入标头，否则计划就不准确
“单元 Agent 评审通过了——跳过人工屏障”	单元 Agent 评审不等于暂停等待人工评审
“今天结束了 / 整个 PR 以后再评审——取消单元暂停”	时间安排和后续评审都不能改写 Execution-mode
“continue 就是执行剩下的所有内容”	“continue”只解锁一个下一个单元；要一次全部执行，必须明确要求变更模式
“PM 评审波次比故事更清晰”	划分依据是需求故事 ID，而不是手动编写的列表

模式归属

将 tasks.md 与 story-unit 路线对齐并继续：

tasks.md 中的 Execution-mode:	操作
story-unit	继续
continuous	必须使用子技能 build-in-waves
缺失 / unset / 无效	在 tasks.md 中写入 Execution-mode: story-unit（如果受版本控制，则提交更改）。继续

设置

1. 模式归属。 应用上表。完成条件：标头为 story-unit，且继续使用此技能，或已移交给 build-in-waves。
2. 会话预检。 应用 ../execute-common/SKILL.md 中的 Session preflight。 完成条件：该部分的完成条件已满足。
3. 台账检查。 应用 ../execute-common/SKILL.md 中的 Ledger check（其中 的 story-unit 条款涵盖跳过已登记为完成的单元）。 完成条件：已知下一个任务／单元。
4. 阅读计划。 阅读一次 tasks.md。记录规范的 Global Constraints 路径和内容哈希；派发内容应引用该文件，并从中获取验证命令，而不是将其粘贴到每个审阅者提示词中。 如果缺少 docs/agents/project.md，请说明并建议使用 configure-repo。 当 ## Team 中有人员名单／等级时，仅加载等级 packaging——即使是 Solo，也绝不能跳过双重判定审阅。完成条件：已逐字记录约束。
5. 推导单元 — GATE。 加载此文件旁的 story-unit-mode.md。运行 Derive partition + File count + 打印 Unit table。硬性失败会阻止派发。完成条件：已打印表格；硬性失败已解决或报告。
6. 待办事项 — GATE。 应用 ../execute-common/SKILL.md 中的 Todos — GATE。 完成条件：列表与计划一致，并且包含 Close 分支待办事项。
7. 预检计划审阅。 派发前，针对计划内部缺陷提出一个批次问题。检查无误 → 不作评论。完成条件：已排除冲突或确认不存在冲突。
8. 单元顺序。 已由步骤 5 的 Derive partition 固定。在每个单元内，使用共享的就绪集调度器：仅有一个就绪任务或任务涉及的表面重叠时串行；仅在表面互不重叠且工作树隔离安全时并行。完成条件：已确定每个单元的并发方式。

每单元循环

按顺序处理每个单元 U：

A. 单元中的任务

对 U 中每个就绪任务运行 ../execute-common/task-lifecycle.md。调度器会提供通道、工作者／审阅者租约 ID、基准修订版、简介、报告和差异包路径。任务审阅通过后，应在单元屏障前登记到台账；该文件的单任务收尾和禁止重复审阅者规则决定了下方 B 是否仍需派发。

B. 单元屏障（U 中的所有任务均已登记到台账后）

加载 story-unit-mode.md 中的 Per-unit barrier，并完整执行。面向用户的 STOP 消息必须填写该流程中的每个 REQUIRED 项——时间紧迫时也不得随意缩写。多任务单元的一次单元范围派发 （来自 A）即为其综合审阅；单任务单元已在 A 中完成收尾，不在此处重新审阅。

解锁：

用户回复	操作
continue / LGTM / looks good（看过之后）	登记 Unit <k>: complete (tasks …, range <base>..<head>)。仅处理下一个单元。模式保持为 story-unit。
stop stopping / just run it all	在 tasks.md 中写入 Execution-mode: continuous（如已跟踪则提交）。将此单元登记为完成。必需的子技能：剩余任务使用 build-in-waves（不再设置单元屏障）。
stop / hold / changes needed	保持停止；不要开始下一个单元。

C. 下一个单元

继续每单元循环。最后一个单元解锁并登记台账后 → 最后一个单元之后。

实施者状态处理

状态	你的下一步
DONE	打包差异 → 任务审查。
DONE_WITH_CONCERNS	阅读顾虑 以及 .skills/<CODE>/implementation-notes.md。条目必须符合 ../execute-common/implementer-prompt.md 中九字段的 Deviations 规范。缺少说明文件路径、字段不完整，或声称存在偏差却只填写五个字段 → 不完整 — 先重新派发任务以记录说明。映射影响 reroute-plan / realign-spec 或可能推翻计划的影响 → 必须使用子技能：使用 reroute-plan（不要将其视为干净的 DONE）。
NEEDS_CONTEXT	补充所需内容；使用同一模型重新派发。
BLOCKED	缺少上下文 → 补充；达到能力上限 → 使用更强模型；任务太大 → 拆分；计划有误 → 必须使用子技能：使用 reroute-plan。

每项任务最多重新派发 2 次；仍未达到 DONE → 升级给用户处理。

模型分级

每次派发都要 明确指定 模型。

• 低成本： 转录 / 单文件机械性修复。
• 中等起步： 所有审查者；所有依据散文开展工作的实施者。
• 最高级： 设计判断、广泛理解代码库、整分支审查。

审查者提示词规范

• 派发时绝不预先判断发现结果（“不要标记 X”“最多算小问题”）。
• 计划要求的缺陷仍然是发现项 — 询问用户以哪项为准。
• 没有具体理由时，不要发出开放式的“检查所有内容”指令。
• 不要重新运行实施者已在报告中提供证据的测试。

持久化进度

• 绝不重新派发任务，也不重新打开台账中标记为已完成的单元。
• 压缩后，从第一个没有完整行的任务继续；单元的完整行表示该单元的人工关卡已关闭。
• .skills/ 是被 git 忽略的临时目录；如果被清除，请从 git log 重建。

最后一个单元之后

完整执行 ../execute-common/SKILL.md 中的 Close sequence。检查基点为 git merge-base main HEAD — 绝不要只检查最后一个单元的范围。

完成条件：该部分的 Done when 条件已满足。

红线 — 绝不可

• 跳过 tracker-sync、占用情况或工作区预检
• 配置缺失或用户拒绝同步时，自行编造 tracker 或工单集合
• 没有人工解锁或书面模式变更就启动下一个单元（或将台账单元标记为已完成，仿佛已经解锁）
• 只在聊天中把“停止停止”当作指令，而不写入 Execution-mode: continuous
• 把“继续”过度解读为运行所有剩余单元
• 编写或优先采用 PM 审查顺序列表，而不是从故事推导单元
• 跳过单元 Agent 审查，直接先把原始单元交给人工
• 因每个单元都已获人工批准，就跳过整分支审查
• 使用 HEAD~1 作为审查基点
• 将整个计划文件交给子 Agent
• 在 Critical/Important 发现项尚未解决时继续推进
• 在控制器上下文中修复审查者发现的问题
• 重新派发台账中标记为已完成的工作
• 待办列表（任务 和 Close 分支）创建之前就进行派发
• 跳过关闭序列、静默跳过润色，或把 EOD/demo 当作润色条件
• 未经明确同意就在 main/master 上实施
• 未经询问就创建 worktree
• 标题仍写着 story-unit 时，悄悄切换到 continuous 规则