Back to Details

ship

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/ship

/ship

Optimize the delivery path from completed work to working install. The insight: when execution is cheap, delivery is the work.
Ship is the final step of the Execution phase. Code that isn't in users' hands isn't delivering value. This skill identifies and removes friction in your delivery path.
优化从已完成工作到可运行安装的交付流程。核心思路：当开发成本很低时，交付环节就是核心工作。
Ship是执行阶段的最后一步。没有交付到用户手中的代码无法创造价值。本技能用于识别并消除交付流程中的阻碍。

When to Use

使用场景

Invoke 
/ship
when:
  • Execution is complete - code is ready, tests pass, review is done
  • You need to deploy - getting changes from merged to running
  • Delivery feels slow - the code is done but it's not reaching users
  • You're blocked on gates - reviews, scans, approvals are piling up
  • You want to automate delivery - make the path from code to install frictionless
Do not use when: You're still building. Ship is for getting completed work to users, not for execution.
在以下场景中调用
/ship
：
  • 开发已完成 - 代码准备就绪，测试通过，评审完成
  • 需要部署 - 将已合并的变更部署到运行环境
  • 交付速度缓慢 - 代码已完成但无法触达用户
  • 被环节阻塞 - 评审、扫描、审批堆积
  • 希望自动化交付 - 让从代码到安装的流程无阻碍
请勿在以下场景使用： 仍在开发阶段时。Ship用于将已完成的工作交付给用户，而非开发执行环节。

The Ship Process

Ship流程

Step 1: Identify the Delivery Path

步骤1：识别交付流程

Before shipping, map the path from code to working install:
"The delivery path for this change is: [local] -> [PR/review] -> [merge] -> [CI/CD] -> [staging/prod] -> [user install]."
Be specific. Name each step and who/what owns it.
在交付前，梳理从代码到可运行安装的完整路径：
"本次变更的交付路径为：[本地] -> [PR/评审] -> [合并] -> [CI/CD] -> [预发布/生产] -> [用户安装]。"
请尽可能具体，明确每个步骤及其负责人/负责系统。

Step 2: Assess the Delivery-Path Tax

步骤2：评估交付流程损耗

The delivery-path tax is the friction that slows velocity. Identify where time is lost:
交付流程损耗是指降低交付速度的阻碍因素。找出时间消耗的节点：

Review Time

评审时间

  • How long do PRs wait for review?
  • Is the review queue a bottleneck?
  • Can AI review pre-check before human review?
  • PR等待评审的时长是多少？
  • 评审队列是否成为瓶颈？
  • 是否可以在人工评审前先进行AI预检查？

Merge Time

合并时间

  • Are there merge conflicts blocking progress?
  • Is the main branch unstable?
  • How long from approval to merge?
  • 是否存在合并冲突阻碍进度？
  • 主分支是否不稳定？
  • 从审批通过到完成合并需要多长时间？

Gate/Scan Time

环节/扫描时间

  • Security scans, compliance checks, quality gates
  • Are gates running in parallel or serial?
  • Which gates are flaky or slow?
  • 安全扫描、合规检查、质量关卡
  • 这些环节是并行运行还是串行运行？
  • 哪些环节不稳定或速度缓慢？

Approval Time

审批时间

  • Who needs to approve?
  • Are approvers available?
  • Can approval be automated for low-risk changes?
  • 需要哪些人审批？
  • 审批人是否可及时处理？
  • 低风险变更是否可以自动化审批？

Deploy Time

部署时间

  • How long does deployment take?
  • Is rollback fast if needed?
  • Are there manual steps?
  • 部署需要多长时间？
  • 若出现问题，回滚速度是否够快？
  • 是否存在手动操作步骤？

Step 3: Execute the Ship

步骤3：执行交付

Based on context available, execute the appropriate shipping actions:
根据现有上下文，执行合适的交付操作：

With CI/CD Context

有CI/CD上下文时

If you have access to the CI/CD configuration (build YAML, pipeline definitions):
  1. Reference the pipeline - Point to the specific build/deploy configuration
  2. Trigger the appropriate workflow - Label PRs, push to deploy branches, etc.
  3. Monitor the pipeline - Watch for failures, report status
  4. Verify deployment - Confirm the change is live
如果可以访问CI/CD配置（构建YAML、流水线定义）：
  1. 关联流水线 - 指向具体的构建/部署配置
  2. 触发对应工作流 - 为PR添加标签、推送到部署分支等
  3. 监控流水线 - 关注失败情况，报告状态
  4. 验证部署 - 确认变更已上线

Without CI/CD Context

无CI/CD上下文时

If shipping manually or without pipeline access:
  1. List deployment steps - What needs to happen in order?
  2. Execute each step - Or provide commands to execute
  3. Verify each stage - Confirm success before proceeding
  4. Report final status - Confirm user-facing change is live
如果需要手动交付或无法访问流水线：
  1. 列出部署步骤 - 明确需要按顺序执行的操作
  2. 执行每个步骤 - 或提供执行命令
  3. 验证每个阶段 - 确认成功后再进行下一步
  4. 报告最终状态 - 确认面向用户的变更已上线

Step 4: Post-Ship Verification

步骤4：交付后验证

Shipping isn't done until you verify:
  • Is it running? - The code is deployed and executing
  • Is it working? - The intended behavior is present
  • Is it reachable? - Users can access/use it
Create ad-hoc verification tests if needed. These can be kept or discarded - the point is confidence, not permanent test infrastructure.
只有完成以下验证，交付才算真正完成：
  • 是否正常运行？ - 代码已部署并正在执行
  • 是否功能正常？ - 实现了预期的功能
  • 是否可访问？ - 用户可以访问/使用该功能
必要时可创建临时验证测试。这些测试可保留或丢弃，核心是确保交付结果的可靠性，而非构建永久测试基础设施。

Output Format

输出格式

Always produce a ship report in this structure:
undefined
请始终按照以下结构生成交付报告：
undefined

Ship Report

交付报告

Shipped: [what was shipped] Target: [where it was shipped to] Path: [the delivery path taken]
已交付内容： [交付的具体内容] 目标环境： [交付的目标环境] 交付路径： [实际采用的交付流程]

Delivery-Path Tax Identified

识别到的交付流程损耗

  • [Friction point 1]: [time/effort cost]
  • [Friction point 2]: [time/effort cost]
  • [阻碍点1]：[时间/人力成本]
  • [阻碍点2]：[时间/人力成本]

Ship Actions Taken

执行的交付操作

  1. [Action 1 - result]
  2. [Action 2 - result]
  3. [Action 3 - result]
  1. [操作1 - 结果]
  2. [操作2 - 结果]
  3. [操作3 - 结果]

Verification

验证结果

  • Deployed successfully
  • Running in target environment
  • User-facing functionality confirmed
  • 部署成功
  • 在目标环境正常运行
  • 面向用户的功能已确认可用

Recommendations

建议

[Any suggestions for reducing delivery-path tax in future]
undefined
[未来减少交付流程损耗的建议]
undefined

Examples

示例

Example 1: Shipping with CI/CD Pipeline

示例1：通过CI/CD流水线交付

/ship

PR #247 is approved. Need to get it deployed to production.
Output:
undefined
/ship

PR #247已通过审批。需要部署到生产环境。
输出：
undefined

Ship Report

交付报告

Shipped: PR #247 - Add dark mode toggle Target: Production (users) Path: Approved PR -> Merge -> CI build -> Staging auto-deploy -> Prod deploy
已交付内容： PR #247 - 添加深色模式切换按钮 目标环境： 生产环境（用户端） 交付路径： 已审批PR -> 合并 -> CI构建 -> 预发布环境自动部署 -> 生产环境部署

Delivery-Path Tax Identified

识别到的交付流程损耗

  • Review time: 2 hours (acceptable)
  • CI build: 8 minutes
  • Staging deploy: 3 minutes
  • Prod approval: Waiting (manual gate)
  • 评审时间：2小时（符合预期）
  • CI构建：8分钟
  • 预发布环境部署：3分钟
  • 生产环境审批：等待中（手动关卡）

Ship Actions Taken

执行的交付操作

  1. Merged PR #247 to main - success
  2. CI build triggered automatically - passed (8m)
  3. Staging deploy completed - verified working
  4. Requested prod deployment approval
  5. Prod deploy completed after approval
  1. 将PR #247合并到主分支 - 成功
  2. 自动触发CI构建 - 构建通过（耗时8分钟）
  3. 预发布环境部署完成 - 验证功能正常
  4. 申请生产环境部署审批
  5. 审批通过后完成生产环境部署

Verification

验证结果

  • Build passed CI
  • Staging environment shows dark mode toggle
  • Production deployment complete
  • User-facing: toggle visible in settings
  • 构建通过CI检查
  • 预发布环境显示深色模式切换按钮
  • 生产环境部署完成
  • 用户端：设置页面可见切换按钮

Recommendations

建议

  • Consider auto-deploy to prod for UI-only changes (low risk)
  • Staging verification could be automated
undefined
  • 考虑对仅涉及UI的低风险变更启用生产环境自动部署
  • 可将预发布环境验证环节自动化
undefined

Example 2: Identifying Delivery-Path Tax

示例2：识别交付流程损耗

/ship

We've had 3 PRs sitting for a week. What's blocking us?
Output:
undefined
/ship

我们有3个PR已经搁置一周了。是什么在阻碍我们？
输出：
undefined

Ship Report

交付报告

Shipped: Analysis only (no deployment) Target: Identifying delivery friction
已交付内容： 仅分析（无实际部署） 目标环境： 识别交付阻碍因素

Delivery-Path Tax Identified

识别到的交付流程损耗

  • Review time: 5-7 days average (CRITICAL)
    • Only 2 reviewers for 8 developers
    • Reviews happen in batches, not continuously
  • Security scan: 45 minutes per PR (HIGH)
    • Runs serially, not parallel
    • Same scan runs on every commit, not just final
  • Merge conflicts: 2 of 3 PRs have conflicts
    • Main branch has diverged significantly
  • 评审时间：平均5-7天（严重问题）
    • 8名开发人员仅对应2名评审人员
    • 评审工作批量处理，而非持续进行
  • 安全扫描：每个PR耗时45分钟（高风险）
    • 串行运行，未并行执行
    • 每次提交都重复扫描，而非仅针对最终版本
  • 合并冲突：3个PR中有2个存在冲突
    • 主分支已大幅偏离

Recommendations

建议

  1. Immediate: Resolve merge conflicts on PRs #251, #253
  2. This week: Add 2 more reviewers or implement AI pre-review
  3. This sprint: Move security scan to run only on merge-ready PRs
  4. Consider: Daily review slots instead of batch reviews
undefined
  1. 紧急处理： 解决PR #251、#253的合并冲突
  2. 本周内： 新增2名评审人员或引入AI预评审
  3. 当前迭代： 仅对准备合并的PR执行安全扫描
  4. 考虑方案： 改为每日固定评审时段，而非批量评审
undefined

Example 3: Manual Deployment

示例3：手动部署

/ship

Need to deploy the firmware update to the test device. No CI for this.
Output:
undefined
/ship

需要将固件更新部署到测试设备。无CI流水线支持。
输出：
undefined

Ship Report

交付报告

Shipped: Firmware v2.3.1 Target: Test device (ESP32) Path: Local build -> USB flash -> Device verification
已交付内容： 固件v2.3.1 目标环境： 测试设备（ESP32） 交付路径： 本地构建 -> USB烧录 -> 设备验证

Ship Actions Taken

执行的交付操作

  1. Built firmware: 
    pio run -e esp32
  2. Connected device via USB
  3. Flashed: 
    pio run -e esp32 -t upload
  4. Monitored boot: 
    pio device monitor
  1. 构建固件：
    pio run -e esp32
  2. 通过USB连接设备
  3. 烧录固件：
    pio run -e esp32 -t upload
  4. 监控启动过程：
    pio device monitor

Verification

验证结果

  • Flash completed without errors
  • Device booted successfully
  • Version shows 2.3.1 in status endpoint
  • New feature (power saving mode) responding
  • 烧录过程无错误
  • 设备成功启动
  • 状态端点显示版本为2.3.1
  • 新功能（省电模式）可正常响应

Delivery-Path Tax Identified

识别到的交付流程损耗

  • Manual USB connection required
  • No OTA update path for test devices
  • Build takes 2 minutes locally
  • 需要手动连接USB
  • 测试设备不支持OTA更新
  • 本地构建耗时2分钟

Recommendations

建议

  • Set up OTA updates for faster iteration
  • Consider PR builds that produce flashable artifacts
undefined
  • 搭建OTA更新系统以加快迭代速度
  • 考虑通过PR构建生成可烧录的固件包
undefined

Session Persistence

会话持久化

This skill can persist context to 
.oh/<session>.md
for use by subsequent skills.
If session name provided (
/ship auth-refactor
):
  • Reads/writes 
    .oh/auth-refactor.md
    directly
If no session name provided (
/ship
):
  • After producing the ship report, offer to save it:
    "Save to session? [suggested-name] [custom] [skip]"
  • Suggest a name based on git branch or the work being shipped
Reading: Check for existing session file. Read Aim (what outcome we wanted), Solution Space (what approach we took), and Execute status.
Writing: After shipping, write the deployment status:
markdown
undefined
本技能可将上下文持久化到
.oh/<session>.md
，供后续技能使用。
若指定会话名称（
/ship auth-refactor
）：
  • 直接读写
    .oh/auth-refactor.md
若未指定会话名称（
/ship
）：
  • 生成交付报告后，会询问是否保存：
    "保存到会话？[建议名称] [自定义] [跳过]"
  • 会根据Git分支或交付内容建议会话名称
读取： 检查是否存在会话文件。读取目标（预期结果）、解决方案范围（采用的方案）和执行状态。
写入： 交付完成后，写入部署状态：
markdown
undefined

Ship

Ship

Updated: <timestamp> Status: [staged | deployed | verified | rolled-back]
[shipping notes, verification results, etc.]
undefined
更新时间： <时间戳> 状态： [已预发布 | 已部署 | 已验证 | 已回滚]
[交付说明、验证结果等]
undefined

Adaptive Enhancement

自适应增强

Base Skill (prompt only)

基础技能（仅提示）

Works anywhere. Produces ship checklist for manual execution. No persistence.
可在任何环境使用。生成供手动执行的交付检查清单。无持久化功能。

With .oh/ session file

配合.oh/会话文件

  • Reads 
    .oh/<session>.md
    for context on what was built and why
  • Writes deployment status to the session file
  • /review
    can check if shipping achieved the aim
  • 读取
    .oh/<session>.md
    获取已构建内容及背景上下文
  • 将部署状态写入会话文件
  • /review
    可检查交付是否达成目标

With CI/CD Configuration

配合CI/CD配置

  • Reads pipeline definitions (GitHub Actions, CircleCI, etc.)
  • References specific workflow files
  • Triggers appropriate pipelines via labels or commands
  • 读取流水线定义（GitHub Actions、CircleCI等）
  • 关联具体的工作流文件
  • 通过标签或命令触发对应流水线

With Full Pipeline Integration (MCP tools)

配合完整流水线集成（MCP工具）

  • Directly triggers deployments
  • Monitors pipeline progress in real-time
  • Queries deployment status from infrastructure
  • Session file serves as local cache for deployment state
  • 直接触发部署
  • 实时监控流水线进度
  • 从基础设施查询部署状态
  • 会话文件作为部署状态的本地缓存

The Intent -> Execution -> Review Loop

意图 -> 执行 -> 评审循环

Ship is part of the execution phase, but it has its own mini-loop:
  1. Intent: Get this code to users
  2. Execute: Run the deployment pipeline
  3. Review: Verify the deployment worked
After shipping, the outer loop continues:
  • /review
    - Did the shipped change achieve the aim?
  • /salvage
    - If shipping revealed problems, capture learnings
  • Back to 
    /aim
    - What's the next outcome to pursue?
Ship属于执行阶段，但自身也有一个小型循环：
  1. 意图： 将代码交付给用户
  2. 执行： 运行部署流水线
  3. 评审： 验证部署是否成功
交付完成后，外部循环继续：
  • /review
    - 已交付的变更是否达成了目标？
  • /salvage
    - 如果交付过程中发现问题，总结经验
  • 回到
    /aim
    - 确定下一个要实现的目标

Position in Framework

在框架中的位置

Comes after: 
/execute
(the work is done, now deliver it). Leads to: 
/review
(did the shipped change achieve the aim?), then back to 
/aim
for the next outcome. This is the end of the line: Ship is where code becomes value. Everything before this is potential; ship makes it real.
前置环节： 
/execute
（开发完成后，进入交付环节）。 后续环节： 
/review
（验证已交付变更是否达成目标），之后回到
/aim
确定下一个目标。 核心意义： Ship是代码转化为价值的环节。在此之前的所有工作都是潜在价值，Ship将其转化为实际价值。

Key Vocabulary

关键术语

  • Delivery Path: The journey from merged code to working install
  • Delivery-Path Tax: Friction that slows delivery (review time, merge time, gate time, approval time)
  • Working Install: The code is running and users can interact with it
Remember: Code that isn't shipped isn't delivering value. When execution is cheap, delivery is the bottleneck. Optimize the path, reduce the tax, get changes to users.
  • 交付路径： 从合并代码到可运行安装的完整流程
  • 交付流程损耗： 减缓交付速度的阻碍因素（评审时间、合并时间、环节时间、审批时间）
  • 可运行安装： 代码已运行且用户可交互的状态
请记住： 未交付的代码无法创造价值。当开发成本很低时，交付环节就是瓶颈。优化交付路径，减少流程损耗，将变更尽快交付给用户。