ship

Ship

让一项功能依次经过三个交互阶段和四个自主阶段。所有人工判断都在审批关卡前收集；通过审批关卡后，改为升级到多模型共识，而不是询问用户。此技能本身不包含任何阶段知识——所有行为均来自引用的技能。

模型路由

在阶段 0 之前，判断此次调用在语义上是否将某个流程阶段指定给特定模型或运行环境（“用 X 规划，用 Y 实现”）。这是对含义的判断，而非关键词匹配——在功能内容、引用材料或文件名中提到的模型不算指定。将每条指令解析为按阶段划分的执行载体：

• 指定阶段（“用 X 规划”，“用 Y 实现”）绑定到所命名的阶段；多条指定阶段的指令分别解析。
• 未指定阶段（“使用 X”，“用 Y”）仅绑定到实现阶段——绝不扩展到规划阶段或所有阶段——并在开场白中说明该绑定（“将实现路由到 X；规划仍使用当前会话模型。”）。
• 强度根据指令含义判断，而非关键词：“实现时使用 X”属于优先强度（不可用时回退，并明确说明）；“只能使用 X”属于必需强度（路由不可用时阻止该阶段——不提示、不静默回退）。

如果调用中没有指令，请检查本地配置（shared/references/local-config.md）中的 work_engine_preferences，获取各阶段的常驻默认设置；明确指定的指令始终优先于该设置，其 mode: off|prefer|require 按照上述相同的强度规则映射。两者均不存在时，所有阶段都使用当前会话模型。

在功能请求进入阶段 0–2 或任何审查输入之前，清除其中所有路由指令——执行载体是按阶段划分的路由依据，绝不是产品内容。

仅本地模式

在运行开始时执行一次 git remote。没有远程仓库时，整个运行切换为仅本地模式：照常创建各阶段要求的所有提交，但跳过所有推送、PR 创建/编辑和 CI 尝试——不重试，也不查找远程仓库。缺少远程仓库属于终止状态，不是错误。在仅本地模式下，不要调用 open-pr；阶段 6 在本地提交、已提交的遗留问题记录和交接说明处结束。

委派

你是一个精简的协调者。每个不需要用户参与的阶段都由自己的子 Agent 执行，阶段之间传递的是文件，而不是段落。约定见 shared/references/handoff-contract.md（简报 → 报告 → 信封）；各站点的绑定关系——每个工作者调用什么、读取什么以及必须传递什么——见 references/station-dispatch.md。第 3 阶段之前请先阅读。

传递路径，而非内容。 你的上下文中只保留运行状态路径、当前切片 ID，以及每个已完成站点一个不超过 15 行的信封。不要保留 PRD 正文、差异、发现列表或站点对话记录。只有当你必须做出的决策依赖详细信息时，才打开报告正文——例如，将 revise 路由给相应处理方、汇总最终报告，或协调意见不一致的两个站点。

阶段如此划分的原因：

• 阶段 0–2 在你的上下文中运行，因为只有你能询问用户，而阶段 2 的审批关卡是最后一个需要人工参与的节点。它们的持久化输出已经存在（跟踪器或仓库根目录文件中的 PRD，以及议题或 TASKS.md 中的切片）——写入后，请引用其路径，并丢弃工作细节。
• 阶段 1 的依据核查也会委派执行。 阅读 CONCEPTS.md、ADR 和代码属于输入收集，而不是对话；只读工作者会返回仓库中已有答案的问题，这样就不会把这些问题提交给用户。
• 阶段 3–6 为每个切片的每个站点各安排一名工作者。 审批关卡之后不再需要用户参与；有争议的决定交由 models-consensus 处理。

如果宿主没有子 Agent 工具，就在线内执行站点任务——但仍须编写简报和报告，并在最终报告中说明没有启动工作者。基于文件的交接能在上下文压缩后保留下来；隔离能力则取决于宿主是否提供。

流程

阶段	模式	运行位置	调用
0. 构思	交互式，可选	主进程	brainstorm（模糊想法——对于高风险的多模型探索，采用面板模式）；prototype（只有运行代码才能确定的未知设计）
1. 规格说明	交互式	主进程（+ 委派调研）	只读工作器根据术语表、ADR 和代码为请求提供依据 → 01-grounding.report.md；然后根据该报告内联运行 interview，接着运行 to-spec。高风险或存在争议时：两者都采用面板模式运行。interview 会运行 security-gate 规格阶段检查清单，并指出测试接缝；to-spec 会将其记录为 PRD 的安全决策和测试决策，以便阶段 2 提取两者。
2. 规划	交互式——最后一道人工关卡	主进程	to-tasks（当交付需要逐任务测试计划和架构映射时，采用面板模式）。其切片契约原生包含 acceptance + gates。用户批准任务拆分。
3. 设计关卡	自主执行，逐任务进行	子 Agent	先运行 coding-design-plan，再根据切片的镜头标记运行 design-gate
4. 实现	自主执行，逐任务进行	子 Agent	对每个切片运行 implement-and-review——它会原生提取切片契约（acceptance 作为完成关卡，gates 用于选择审查镜头），且绝不推送。其他方案：需要记录多模型审计轨迹时使用 collaborative-delivery；对于简单的单轨切片，直接使用 tdd（对于未经测试的遗留代码，先运行 safe-incremental-coding）。在工作过程中发现 Bug 时使用 diagnose。
5. 验证	自主执行	子 Agent（一个，覆盖整个链路）	按顺序执行，失败即停止：运行验收契约 → coding-review-simplify（趁上下文仍清晰时自行简化）→ full-review（由 security-gate 标记时，进行深度安全审查）→ 面向 Web 的变更采用流水线模式运行 browser-smoke，否则运行 harness 的 run 检查。多模型关卡审查的是最终代码——审查后绝不能再执行未经审查的修改操作。失败时通过 diagnose 返回阶段 4。
6. 交付	自主执行	子 Agent	提交变更；根据 references/residual-findings.md 将尚未应用的审查发现持久化；通过 open-pr 创建 PR（仅本地模式下跳过）；移动问题的分流标签；通过 session-handoff 保存连续性说明（正文遵循 summarize 的冷启动测试）；并且——当此次运行解决了不明显的问题时——以无头模式运行 capture-learning。由人工合并；收到评论后，resolve-pr-feedback 会完成审查后的处理闭环。

如果输入已经是 PRD 或已批准的规格说明，则跳过阶段 0–1；如果已存在获批的切片，则跳至阶段 3。

切片契约

切片契约由 to-tasks 定义，包括可由机器检查的 acceptance 命令、供 design-gate 和 security-gate 使用的 gates 标记、HITL/AFK 分类（HITL 优先安排），以及 ready-for-agent / TASKS.md 工作队列。阶段 2 必须生成包含该契约的切片；阶段 3–6 则使用该契约。

自主循环

对于多个已就绪的切片，将调度委托给 implement-feature：它会通过并行 worktree、基于集成分支头的变基以及覆盖整个功能的接口审查来执行依赖 DAG，并针对每项任务调用 implement-and-review。调度属于指挥工作，而非站点工作——implement-feature 在你的上下文中运行，并自行调度各切片的站点工作器；它是通过门禁后唯一不封装在站点子 Agent 中的技能。对于单个切片，请根据委派部分自行调度阶段 3–6，并通过 worktree 技能在隔离的 worktree 中执行（优先使用工具链原生隔离——绝不使用工具链无法查看的 worktree）。

如果切片受阻（升级阶梯在硬性阻断处已耗尽），记录原因，跳过该切片，继续处理未受阻的切片，并在最终报告中列出所有受阻切片。站点委派已将各切片的工作移出你的上下文；如果一次运行的规模进一步扩大——跨多个会话处理许多切片——请切换到 dynamic-harness 管理器模式（使用相同的交接约定，并采用任务范围的台账），或者通过 session-handoff 备注结束会话，而不要让上下文窗口因过度膨胀而降低质量。

运行状态

循环会跨越上下文压缩、重启和并行 worktree，因此进度应保存在台账中，而非对话记录中——请按照 shared/references/run-state-contract.md 为每个切片维护一份运行状态。此项目的具体约定如下：

• phase 是流水线阶段编号；每个阶段完成后，都要将其追加到 steps。恢复某个切片时，从 phase 开始，而不是从阶段 0 开始——阶段 3–6 耗时较长，且其输出已保存在磁盘上。
• 每个委派步骤的条目都包含其 brief 和 report 路径，因此恢复运行时可以找回站点的推理过程，而不只是步骤编号。站点的报告一旦存在，该步骤就算完成——只有当其 status 表示失败时才重新调度。
• 用户批准任务拆分时，应在 gates 中记录阶段 2 的批准。这是最后一个人工门禁，因此重启时如果在 gates 中找不到该记录，就要停下来询问，而不是默认已获批准；如果找到了，就视为已作出决定，不再重复询问。
• 提交、PR、已创建的工单以及遗留项记录，都要各自设置一个 side_effects 键（commit:<slice-id>、pr:<branch>、ticket:<finding-id>），并在执行相应操作之前写入。恢复切片时，如果发现该键已存在，就跳过相应操作，避免重复执行——这可以防止重新运行时为每个遗留项重复创建两次工单。
• 提前声明切片的上限，并通过以下三种退出状态之一结束每个切片：complete、failed（硬性阻断或升级阶梯耗尽）或 ceiling_hit。受阻切片必须作为退出状态记录，不能悄悄跳过。

证据门禁

如果阶段 4 报告了行为变更，却没有提供完整一致的验证证据——包括检查了哪些现有测试、添加或运行了哪些测试，以及这些测试证明了什么——则在恢复模式下重新调用实现阶段一次：切片和范围保持不变，基于已实现的工作梳理证据，不得重新实现。“恰好一次”指的是相对于上限 1 的 attempts.evidence_recovery：必须在重新调用之前递增运行状态中的计数——模型不得自行决定是否重试，因此即使运行在恢复期间崩溃，也不能因此获得新的尝试次数。如果第二次返回仍缺少完整一致的证据，就将该切片硬性阻断：不得基于未经验证的行为继续验证或交付；请在最终报告中将其列入受阻切片。

剩余发现

第 5 阶段审查中未应用的发现，必须在切片完成前持久化。遵循 references/residual-findings.md：通过检测到的接收端提交跟踪工单（每次运行仅探测一次可用性并缓存；返回结构化的 {filed, failed, no_sink}），始终提交 docs/residual-review-findings/<branch-or-head-sha>.md 记录，并尽力将 PR URL 回填到已提交的工单中。剩余项绝不作为 PR 正文中的清单跟踪——PR 约定中的决策日志记录的是假设，而不是审查剩余项。

升级阶梯（取代执行过程中的提问）

当自主阶段遇到有争议或不可逆的决策时：

1. 以 --auto 在轮询模式下运行 models-consensus（为常规升级设置预算预设）——多模型审议可替代用户决策。它只进行审议，绝不启动实现。
2. 仍未解决：选择最可逆的默认方案，在决策日志中记录假设及理由，并将其纳入 PR 正文，然后继续。
3. 只有在破坏性或不可逆操作（删除数据、强制推送、对外发布、针对真实数据执行不可逆迁移）时，才暂停并等待人工处理。

PR 约定

PR 的编写工作由 open-pr 负责——将其委托出去。Ship 会在正文中添加必需的流程部分：验收证据（运行的命令及其输出）、设计门禁结论、审查摘要、包含标记假设的决策日志，以及剩余风险。必须如实报告结果——失败或跳过的检查都要注明，绝不能粉饰。

注意事项

1. 不要为了节省时间而合并阶段；门禁机制保障质量。
2. 除非遇到必须暂停的情况，否则在第 2 阶段审批门禁之后不要向用户提问。
3. 不要在此处或内联编写阶段行为——调用所引用的技能，让知识集中在一处。
4. 阻塞项尚未完成时，不要对切片启动第 4 阶段。
5. 工作树中的验收命令未通过时，不要将切片标记为完成。
6. 仅限本地模式下，不要重试推送或 PR 操作——一次 git remote 检查即可决定整个运行流程。
7. 不要让路由指令泄漏到规格、计划或审查输入中——在第 0 阶段之前将其清理掉。
8. 在 full-review 之后执行任何修改性操作，都必须重新运行 full-review——该门禁审查的是最终代码。
9. 不要为了了解情况而读取某个站点报告的正文——封套就是接口；阅读每份报告正是委托机制能节省上下文消耗的原因。
10. 不要将报告内容粘贴到下一站点的任务说明中。引用路径或其中的标题即可；需要更多信息的工作者会自行打开文件。

---

模型路由、仅限本地、证据门禁和剩余项持久化约定改编自 Every 的 compound-engineering-plugin（lfg）。