用途
Ship Ticket 用于驱动一个工作项——一个已跟踪的工单，或对话中提供的自然语言需求——最终产出一个经过评审的草稿拉取请求（draft pull request）。它把父智能体定位为编排者，将实现、每一次评审以及每一次修复都交给独立的全新子智能体完成。
前置依赖
该技能要求环境中存在以下五个工作流依赖技能：
- implement
- codebase-design
- code-review
- ponytail
- ponytail-review
它会合并仓库本地/项目级与全局/用户级安装的技能目录或目录清单，按技能 frontmatter 中的名称（而非仅目录名）进行匹配。若缺少任何一个，会报告所有缺失名称及其来源分组并停止。对于 Matt Pocock 的技能，会引导用户执行：
npx skills@latest add mattpocock/skills
对于 Ponytail 技能，会引导用户查看官方安装说明。安装后需重启 harness 并再次调用 $ship-ticket。只有在刷新后的本地加全局合并结果包含全部五个技能时才继续。
主要能力与流程
1. 固定工作项与分支
从调用参数或当前对话中解析工作项：
- 已跟踪工单：当用户提供工单引用时，通过其跟踪系统获取完整正文、评论、验收标准和关联上下文。若工单含糊、检索失败、被阻塞或需求细节不足以安全实现，则停止；切换到仅提示模式需要用户指示。
- 仅提示（prompt-only）：使用提供的需求和相关对话作为规格，说明其范围与可检查的验收标准，不额外添加需求。在清晰时继续；仅询问阻碍安全实现的缺失细节。此模式不需要 issue、跟踪系统配置、已认证的跟踪身份或跟踪操作。
随后读取仓库说明并检查相关代码路径，保留无关工作。记录当前分支为 <base-branch>，其当前 HEAD 为 <work-base>。从 <work-base> 创建并检出专用分支，遵循仓库或 harness 命名规则；否则对已跟踪工单使用 feat/<ticket-id>-<short-slug>，对仅提示工作使用 feat/<short-slug>。仅当现有分支的历史和工作项上下文证明其属于本工作且从 <work-base> 开始时才复用。
提交主题定义为 <type>(<scope>): <terse imperative summary>。已跟踪工单使用 Jira key 作为 <scope>；否则使用稳定的仓库相关 scope。正文中保留所需证据和工单链接。
仅针对已跟踪工单：从跟踪系统的已认证身份解析 <executor> 并发现其原生生命周期，解析 In Progress 和 <review-handoff-state>（优先 Review 或 In Review，其次 Testing 或 QA，再次 Done）。使用现有原生状态或生命周期标签；当只有 open/closed 状态时，用 open 表示 In Progress，用 closed 表示交接。将工单分配给 <executor>，然后转换到 In Progress。若分配或转换失败，在实现前停止。
2. 实现
在实现前，从仓库说明、根与工作区清单、任务运行器、脚本和 CI 配置中发现完整验证工作流，清点所有可用的验证命令（测试、linter、格式化、类型检查、构建及其他仓库检查）。定义 <validation-contract> 并逐字包含在每个实现和修复子智能体提示中。
生成一个全新子智能体，携带完整规格、关联上下文、仓库说明、<work-base>、分支和提交格式，加载并全力应用 implement、codebase-design 和 ponytail，以现有接缝处最小正确改动实现每个工作项需求与验收标准，保留验证、错误处理、安全、可访问性和仓库标准。在交接前通过 <validation-contract>。仅在工作分支上提交本工作项的实现，在 implement 的评审交接前结束。返回提交 SHA、需求证据、变更文件清单、验证命令及结果和阻塞项。
父智能体等待完成后，验证提交存在于工作分支、遵循提交格式、不含无关工作且每个需求都有证据。遇到未提交或未说明的变更则停止。
3. 评审与修复
按顺序针对 <work-base>...HEAD 运行评审：
- 正确性评审：生成全新子智能体，加载并应用 code-review，针对仓库标准和完整规格分别返回两个维度的精确可操作发现。仅当标准无记录违规且规格无缺失、部分、错误或未请求行为时通过。
- 简洁性评审：正确性通过后，生成另一个全新子智能体，加载并应用 ponytail-review，检查不必要复杂度。仅当返回 Lean already. Ship. 时通过。
修复循环：当任一评审报告问题时，生成全新修复子智能体，加载并全力应用 implement、codebase-design 和 ponytail，仅以最小正确改动修复所报告发现，在工作分支上单独提交修复，返回提交 SHA、逐项证据、变更文件清单和验证结果。任何修复后，因 diff 变化需重新开始正确性评审。持续直到正确性通过且后续全新简洁性评审返回 Lean already. Ship.。
4. 推送并创建草稿拉取请求
两次评审通过后：在最终 HEAD 运行完整验证工作流并确认工作树无未说明变更；验证 <work-base> 之后的每个提交遵循提交格式且属于本工作项；将工作分支推送到仓库远程；通过仓库宿主原生机制创建草稿拉取请求，从工作分支指向 <base-branch>。PR 标题使用提交主题格式，正文限制为 1–3 句简短摘要：先说明为何需要该变更，再解释关键决策及其理由。已跟踪工作添加原生工单链接。省略变更清单、验证部分和评审部分。
仅针对已跟踪工单：草稿 PR 创建成功后，保持 <executor> 分配并将工单通过跟踪系统原生生命周期机制转换到 <review-handoff-state>。
保持 PR 为草稿，不要合并。若推送、PR 创建或适用的最终跟踪转换失败，保留已完成状态，报告确切失败和重试点，然后停止。
5. 完成
仅当每个工作项需求都有证据、最终 HEAD 完整验证工作流通过、工作树已说明、正确性通过、Ponytail 返回 Lean already. Ship.、每个工作项提交已推送、PR 以草稿形式针对 <base-branch> 打开，且（对已跟踪工单）工单仍分配给 <executor> 并处于 <review-handoff-state> 时，才声明完成。报告工作项、分支、提交范围、验证结果、两项评审结果和草稿 PR 链接。仅对已跟踪工单包含 executor 和跟踪转换。
适用场景
适用于需要把单个工单或明确需求，以可评审、可追溯的方式推进到草稿 PR 的开发工作流，尤其是希望实现与评审由不同子智能体分离执行、并强制完整验证门禁的场景。
限制
- 依赖五个指定技能，缺失时无法继续。
- 已跟踪工单模式需要跟踪系统配置、已认证身份和原生生命周期支持。
- 仅提示模式不需要跟踪系统，但需用户提供清晰规格与验收标准。
- 不合并 PR，只创建草稿。
- 关于具体收费、价格、平台支持范围等事实，资料未提供。