ship-it

交付

负责从已接受的计划一直执行到记录最终交付状态。除非新的仓库证据造成实质冲突，否则不要重新讨论已确定的产品决策。

范围与授权

遵循用户明确指定的范围，以及适用的既有授权，优先于工作流默认设置。按照既定惯例，继续执行已授权的准备工作和可逆操作；仅针对尚未解决的重大决策或尚未授予的权限提问。保留工程防护措施和访问控制。如果某项技能阻碍进度，请指出具体指令及其造成的具体冲突，并继续执行其他已授权的工作。

对于只读或不做更改的请求，应在聊天中返回调查结果，不要创建或更新计划、状态、记忆、配置或知识记录，除非明确授权进行这些写入。相较于过时的材料，应以用户当前的更正为准；仅在写入属于授权范围时更新这些材料。

必需的交接

阅读已接受的计划、简报、任务状态、发现项处置结果、工作树、预期的基础分支和交付路径、验证预期，以及是否委派实现的决定。如果这些内容存在冲突，请停止编辑，并先协调持久化材料，使其保持一致。

压缩上下文或中断后，应从任务状态以及当前 Git/PR 状态恢复。不要根据聊天记忆重建任务。

如果用户在执行期间更正了范围、架构、目标分支、验证、监控或收尾方式，应先将更正记录到任务状态，再继续执行。必要时同步调整简报或计划，仅使过时的验证/评审阶段失效，绝不要要求用户重复说明已作出的决定。

实现委派

根据明确的任务选择、已保存的 implementation_delegation_default，然后是 auto，确定使用 never、auto 还是 always。明确的用户或执行环境限制优先。根据 kickoff 技能的 references/config.md，按照操作手册中的代码角色确定各工作者。

当 auto 选择工作者或模式为 always 时，请阅读 references/delegation.md，了解工作者选择、执行清单、有界派发、集成和临时产物清理。

• never：由编排者实现。
• auto：对于 fast 和 full 路径，将编写代码的工作交给受委派者，使编排者负责评审；这样做的收益是将评审与实现分开，而不是减少代码行数。仅在操作手册的吞吐量检查点允许时进一步拆分任务，且各独立工作流必须负责互不重叠的文件。除非某项工作流确实独立，否则 tiny 级别的更改由编排者完成。
• always：至少委派一项有明确范围的任务；如果配置的工作者不可用，则停止。

向工作者提供简报、计划、任务状态、发现项、仓库说明的路径，以及一份精简的执行清单。绝不要发送完整对话。编排者负责共享架构、执行顺序、集成和最终验证。

工作流

1. 核实工作树、分支、基准和脏状态。保留无关工作。
2. 将实现步骤映射到已接受的计划事项和发现 ID。
3. 实施符合要求的最小变更，条件允许时采用测试优先。
4. 检查每位工作者的所有差异，并拒绝扩展范围。
5. 在实施过程中运行有针对性的检查，并在最终头 SHA 上进行集成式仓库/验收验证。对于未变更的内容和环境，复用已有证据；修复或集成后重新运行受影响的检查，而非仅因进入新的工作流阶段就重复检查。
6. 选择并记录下述评审模式。微小、低风险的差异可以通过一次聚焦评审同时检查简洁性和正确性；其他非空差异则需要先进行专门的 ponytail-review，再进行 code-review。
7. 应用或明确处置所选评审模式中的每项简洁性发现。解决 code-review 发现的 P0/P1 问题；解决 P2 问题或明确说明其处置方式。更新阶段状态。
8. 对于 PR 交付路径，调用 create-pr，并提供预期的基准、已接受的产物、最终验证、风险、监控要求以及 Babysit 模式。对于获得明确授权的直接交付路径，使用下述直接交付约定。
9. 核实返回的交付记录与预期的本地/远程引用一致，并包含适用的监控证据或具体阻碍。
10. 持续进行评审循环，直至达到终止状态，然后完成收尾。

实现评审

只有在差异微小、沿用成熟模式、没有重大歧义、安全/数据风险、兼容性影响或协同需求，且仓库政策允许时，才使用 combined。聚焦的 code-review 必须同时检查不必要的机制和正确性；记录原因与发现。未安装 Ponytail 不会阻碍使用此模式。如果范围扩大，则重新评估模式。

对于其他非空差异，或用户或仓库要求时，使用 separate：

1. ponytail-review 接收最终差异、简报、已接受的计划和仓库说明，而非完整对话。它只检查可删除的代码、重复路径、重复造轮子、推测性抽象或灵活性、不必要的依赖以及精简机会。保留需求和保障措施。在阶段状态中记录其输出和预计净可删除行数。
2. code-review 针对同一头 SHA 检查正确性、行为、回归、无障碍性、安全/隐私、兼容性、可靠性和测试覆盖率。不得将 Ponytail 评审作为正确性证据。

如果 Ponytail 未发现问题，记录 Lean already. Ship. 如果发现问题，则予以应用，或记录具体说明为何必须保留这些机制。变更后重新运行受影响的验证。如果实现发生实质性变更，则重新运行所选评审模式；仅有注释、格式或元数据变更时无需重复评审。

当必须进行单独评审但 ponytail-review 不可用时，启动一个新的子任务，对差异应用 simplicity-review 的删除、复用和压缩方法，完成简洁性检查。记录这一替代方案。切勿将简洁性检查悄然并入正确性评审。

直接交付约定

仅当用户当前指令明确授权且仓库策略允许时，才可采用不创建 PR 的交付路径。交付前立即核实目标分支、远程仓库、确切的提交集合、当前 HEAD 验证结果以及适用的审核处置。核实是工具检查；授权已明确时，无需再次征求用户确认。交付时不得改写共享历史，然后读取远程目标 SHA 以及任何必需的 CI、部署或晋级状态。只有确认目标远程状态符合预期时，才记录状态 delivered-direct；否则记录状态 blocked，并注明确切的不匹配项或外部条件。

直接交付时不要调用 create-pr。仅当交付约定要求建立分支或部署监控，且现有自动化能够观测相关状态时，才建立监控。直接集成经核实后，按照 Closeout 中所述的同一 Forest 关闭或保留决策进行处理。

原子化 PR 与监控门槛

PR 创建完成前，必须记录以下所有信息：

• PR URL 和编号；
• head/base 分支及 head SHA；
• 初始可合并性/检查状态；
• 当需要监控时，记录 watch_status: active 以及监控机制和 ID；或者记录 blocked 及确切原因；否则记录 not-applicable 及其授权依据；
• 终止条件。

记录集成是否通过 Git 祖先关系、相对于预期 base 的已验证补丁/整体等效性，或确切的已合并 PR head 证据得到证明。依赖已合并 PR 时，须针对即将关闭的工作树，核实其仓库、编号、head SHA、base 分支和合并状态；另行证明任何其他提交也已集成。缺少上游跟踪引用本身并不能证明有尚未发布的工作。确切的已合并 PR head 证据可以证明已发布，但过时或不匹配的证据不能绕过 Forest 对脏状态或集成情况的保护措施。

如果用户询问“你在监控吗？”，请核实实时监控记录。不要根据意图、待办列表或先前的一次性轮询作答。

对于可采取行动的审核或 CI 反馈，运行 kickoff Babysit playbook：确认其适用于当前 head，仅执行已获授权且范围明确的修复，完成验证、推送并更新状态，然后重新启用监控。仅在已记录 land 授权后，才可通过 kickoff Shipping playbook 合并。

交付状态

• ready-to-merge：当前 head 可合并，必需的检查/审核均已通过或经确认无需执行，且没有尚待处理的发现。只有当已接受的交付路径以 PR 就绪为终点时，此状态才是终态；对于具有 land 授权的任务，或持续管理到合并的工作树任务，此状态是一个里程碑，监控仍将继续静默运行。
• merged：已核实合并及最终 SHA；完成必需的工作树关闭或保留处置并记录其他收尾证据后，该任务才进入终态。
• delivered-direct：已核实明确授权的远程目标及最终 SHA，且未创建 PR，并已完成必需的交付监控和收尾工作。
• canceled：用户或仓库所有者明确取消了工作。
• blocked-external：存在阻止工作继续的具体外部条件，且已记录所需的下一位执行者/行动。

检查仍待完成的开放 PR 不属于终态。

收尾

记录最终验证、PR 状态、部署／推广状态（如适用）、未解决的限制、持久化构件的位置、任务记录核对情况、临时构件清理情况，以及工作树的处置方式。

只能通过创建受管工作树的后端（T3、Forest 或 git）关闭该工作树，并且只有在已证明集成完成或用户／仓库策略授权关闭时才能关闭。压缩合并可能需要明确的远程证据；不要将祖先关系不匹配误认为工作未合并。

收尾时，重新检查确切的工作树和当前所有者，然后确定最新适用的明确任务，或用户保存的关闭或保留决定，并记录其来源。检查所属任务及其关联的终端／进程是否正在使用该确切路径；过时的活动时间戳不能证明其不再活动。记录检查及结果。如果无法确定是否有活动使用，则暂时保留，直到所有者交接或确认解决问题。对于临时保留，记录所有者和重新检查触发条件（review/testing complete 或 merge），然后将后续重新检查交接给指定所有者／跟进人员，或在触发条件满足前持续进行适用且获授权的监控；正在运行的工作树不能关闭。

如果后端是 Forest，请在 episode 状态中记录每个关闭 CLI 的命令名称、解析后的可执行文件路径和报告的版本。在执行 forest close 前，枚举被忽略的名称（例如，git ls-files --others --ignored --exclude-standard），仅检查由仓库说明或定向检查确定的相关名称，将相关的独特证据／配置保存在获授权的持久位置，通过哈希验证复制的内容，并记录名称和哈希，不要打印机密内容。

在已验证集成且没有未提交或未推送工作的情况下，运行 forest close，并记录 Forest 状态、git worktree list --porcelain 和确切的磁盘路径。部分关闭或未经验证的关闭仍属于 closure-blocked；保留所有者、内容、分支和监控，并记录失败的环节。如果存储的 Forest 基准缺失或无法解析，则阻止关闭；仅在已获授权时恢复一个本地可解析的基准，重新运行 Forest 关闭检查，不要根据 PR 元数据猜测或改写 Forest 状态。保留未解决的更改和任何已保留的决定；只有在缺少关闭授权时才询问一次。所需决定或关闭仍待处理时，不要给出最终收尾报告。

根据 episode 状态返回简洁的最终报告。episode 实际达到终止状态后，不要继续运行监控。PR 已合并但清理尚未解决（包括仍由当前任务负责重新检查的临时保留）时，episode 尚未终止。完成已验证关闭、永久保留或明确的重新检查交接后，停止监控，除非用户要求继续监控。监控不在范围内时，不要启动监控。