build-inline

Ephemera 路径：先解析 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。

内联构建

亲自逐个任务推动已批准的计划直至完成，不派遣实现者（或审查者）子 Agent。每一步都必须先测试。进度保存在台账中。最后进行全分支审查。

这不是子 Agent 编排。 连续多任务子 Agent 波次使用 build-in-waves。带人工审核关卡且使用子 Agent 的审核单元使用 build-by-story。

意图	改用
子 Agent 连续波次	必需子技能：使用 build-in-waves
故事单元关卡 + 子 Agent	必需子技能：使用 build-by-story

此技能的触发条件： 用户选择了内联路线、环境无法（或不得）分派实现者，或者 plan-tasks 提供了内联执行选项且用户接受了。工具是否可用不会改变路线——如果用户要求内联，即使存在子 Agent 工具，也必须坚持内联。

过程说明： 每次工具调用之间最多一行简短说明。台账和工具结果负责记录进度。

共享控制器方案： 必需子技能：使用 execute-common。在 Setup 预检 / 台账 / 待办事项阶段，或最后一个任务开始后，加载 ../execute-common/SKILL.md。该文件是这些步骤以及收尾序列判定条件的唯一依据。 此文件规定内联铁律以及控制器作为实现者的工作循环。

铁律

NO IMPLEMENTER SUBAGENT — YOU ARE THE IMPLEMENTER
NO PRODUCTION CODE WITHOUT TDD
NO GUESSING THROUGH A BLOCKER

仅仅因为“有工具”或“子 Agent 更快”就派遣实现者，违反此技能。仅仅因为改动“只有一行”就跳过 RED，违反此技能。计划有歧义时，擅自编造 API、路径或验收细节，违反此技能——必须停止并询问。

范围与执行模式

调用此技能即选择内联路线。Execution-mode 标头是供同级技能和后续交接使用的记录信息：

标头	此技能的处理方式
continuous 或 story-unit	顺序执行任务；没有单元关卡；没有人工单元审核停顿
缺失 / unset / 无效	将 Execution-mode: continuous 写入 tasks.md（如果受版本控制则提交）。此处仍不会运行关卡

带人工审核关卡且使用子 Agent 的审核单元使用 build-by-story。内联模式已让人在整个对话中逐步参与。

想法	实际情况
“存在子 Agent——使用完整循环”	路线是内联。工具不会改变路线
“只有一行改动——跳过失败测试”	必需子技能：每个任务步骤都使用 test-first
“计划很模糊——我来选个合理方案”	计划存在缺口 → 停止并询问；绝不猜测
“story-unit 标头——每个故事后都停下”	关卡属于 build-by-story。内联模式只按顺序执行
“我只派遣审查者，不派遣实现者”	也不得派遣任务审查者子 Agent；最后使用 inspect-change 审查整个分支
“并行波次会更快完成”	内联模式是串行的。不得分派到多个工作树

设置

1. 路由门槛。 确认内联是预期路径（用户已说明，或不具备子 Agent 能力）。如果用户希望通过子 Agent 持续推进多个波次 → build-in-waves。如果用户希望按故事单元设置障碍 → build-by-story。完成条件：路由为内联。
2. 标头记录。 解析 Execution-mode:。如果缺失、为 unset 或无效：将 Execution-mode: continuous 写入 tasks.md。如果已设置，则保持不变。完成条件：标头已存在。
3. 会话预检。 执行 ../execute-common/SKILL.md 中的 Session preflight。完成条件：该部分的完成条件已满足。
4. 运行时绑定。 执行 ../execute-common/SKILL.md 中的 Runtime binding and lease preflight。内联执行没有工作器租约，但会在 .skills/<CODE>/execution-session.json 中记录当前启用的工具链／提供方／模型、定价策略、上下文预留和实际并发数。完成条件：首次生产代码编辑前已存在运行时快照。
5. 台账检查。 执行 ../execute-common/SKILL.md 中的 Ledger check。完成条件：已知下一项任务。
6. 阅读计划。 阅读一次 tasks.md。记录规范的 Global Constraints 来源路径和内容哈希（如果缺少 docs/agents/project.md，则验证命令位于此处——请说明这一点并建议使用 configure-repo）。完成条件：已掌握来源引用和任务差异。
7. 待办事项 — 门槛。 执行 ../execute-common/SKILL.md 中的 Todos — GATE。完成条件：列表与计划一致，并且包含 Close 分支待办事项。
8. 预检计划审查。 编码前，集中提出一批关于计划内部缺陷的问题。检查无异常 → 不作评论。完成条件：已排除冲突或不存在冲突。
9. 顺序。 按 Depends-on 拓扑顺序；未指定 Depends-on → 依赖所有较早的任务；none → 无前置条件。仅串行执行——此技能中绝不使用并行波次／多工作树分发。完成条件：任务顺序已确定。

按任务循环

按顺序处理每个 Task N：

1. 记录基准。 BASE=$(git rev-parse HEAD)。
2. 构建任务摘要（供自己使用）。 在 .skills/<CODE>/task-N-brief.md 中记录 Task N、规范的 Global Constraints 源路径/哈希，以及任务差异。该文件是你实施时必须遵循的约定——包括精确值、路径、签名、_Requirements: ID。如果存在 docs/architecture/ 架构主线，则包含相关的 **ARCH-N**。如果预检记录了票据 ID，则在摘要中列出。完成标准：摘要文件已创建且你已阅读。
3. 先澄清。 如果摘要中有任何不明确之处——API 形态、路径、验收标准、依赖项——立即停止并提问。未明确前不要开始 RED。
4. 使用 TDD 实施。 必须的子技能：任务中的每一步都使用 test-first。测试描述领域行为；在报告/自检中映射需求 ID，不要把 ID 嵌入源代码。只处理计划中列出的文件。
5. 偏差。 如果实际情况迫使你偏离摘要：你就是实施者——遵循 ../execute-common/implementer-prompt.md 中的 Deviations 流程（在 .skills/<CODE>/implementation-notes.md 中填写九字段条目，包括 Unknown class、Map said、Territory showed、Map impact 等）。必须在完成任务前记录；仅追加。如果 Map impact 为 reroute-plan / realign-spec，或修复推翻了计划/共享约定 → 停止并使用必须的子技能：使用 reroute-plan（或提问）；不要悄悄扩大处理范围。
6. 提交。 使用说明变更内容的 Conventional 提交主题——无需 Implements: / Guards: 尾注。
7. 渲染检查。 你就是实施者——如果差异涉及浏览器会渲染的内容，则执行 ../execute-common/implementer-prompt.md 中的 Render check 步骤（将截图保存到 .skills/<CODE>/task-N-render.png，依据摘要进行评判，修复后重新截图）；Visual check 行应写入步骤 9 的证据包。
8. 自检（由控制者执行，不是子 Agent）。 对照差异重新阅读摘要：每个需求 ID 对应的行为都已覆盖？TDD 证据（RED 后接 GREEN）真实吗？输出干净无误？是否遵循了计划的 File Structure？立即修复遗漏——不会有单独的任务审查者来审查。
9. 可选证据包。 对于非简单任务，在 .skills/<CODE>/task-N-report.md 中记录变更内容、覆盖的 ID、RED/GREEN 命令及其输出、渲染检查运行时的 Visual check 行、问题，以及偏差记录路径或 none。简单任务可以不创建此文件，前提是提交信息和台账已有足够信息；不确定时就写。
10. 台账。 追加 Task N: complete (commits <base7>..<head7>, inline, review self)。 将待办标记为完成。
11. 下一步。 立即继续下一个任务——不暂停等待许可，不设单元屏障。若任务进行中遇到阻塞：停止循环并提问（参见 Stop conditions）。

停止条件

遇到以下情况时，停止并询问用户（不要猜测，也不要派遣子 Agent 臆造答案）：

• 摘要或计划含糊或自相矛盾
• 验证失败，且无法根据摘要明确修复方式
• 偏差会推翻计划/设计/需求
• 需要改动任务范围之外的文件或约定
• 工作区位于 main/master 分支，且缺少对 main/master 的许可

用户回答后，从摘要继续处理同一任务——不要跳过台账流程。

持久进度

• 开始时：阅读 .skills/<CODE>/progress.md；以此文件和 git log 为准，不要依赖记忆。
• 不要重做台账中标记为已完成的任务。
• 压缩上下文后，从第一个没有完成记录的任务继续。
• .skills/ 已被 Git 忽略；如果内容被清除，则根据 git log 重建。

上一个任务完成后

完整执行 ../execute-common/SKILL.md 中的 Close sequence。你是 test-first 流程中的修复者（除非用户明确取消内联流程，否则仍不得使用实现者子 Agent）。让 inspect-change 检查台账或 implementation-notes.md 中的所有 Minor 项或备注。

完成条件：该部分的「完成条件」已满足。

红线 — 绝不可

• 跳过 tracker-sync、占用检查或工作区预检
• 在配置缺失或用户拒绝同步时，自行编造跟踪器或工单集合
• 在此技能下派遣实现者或任务审查者子 Agent
• 跳过 test-first，或在出现失败测试前编写生产代码
• 对歧义、失败的测试套件或计划缺口自行猜测
• 运行单元测试关卡或人工单元测试停检（这些属于 build-by-story）
• 并行波次／多工作树分流
• 在上下文压缩后重做台账中已完成的任务
• 未经明确同意就在 main/master 分支上开始工作
• 未经询问就创建工作树
• 没有台账记录就声称任务已完成
• 跳过收尾流程、悄悄跳过润色，或将 EOD/demo 视为润色的判定条件
• 待办列表（包括任务和 Close 分支）尚未建立就开始任务 1
• 在计划进行中，未经用户明确更改流程，就将工作交给 build-in-waves 子 Agent 循环