以下为本文档的中文说明ship 是一个发布工程自动化技能其核心使命是将一个功能分支从“代码完成”状态推进到“PR 就绪可审查”状态只需一条命令即可完成。该技能实现了软件开发中最令人生厌但又不可或缺的环节——在编码完成后、提交审查前的一系列检查和准备工作的自动化。该技能的核心特点包括六步标准工作流——第一步自动检测基础分支第二步与基础分支同步git fetch git merge复杂冲突时询问用户第三步运行测试自动检测项目类型并运行对应的测试框架npm test、bundle exec rake、pytest、go test ./…、cargo test 等第四步覆盖率审计对比分支变更的文件检查是否存在缺少对应的测试代码输出结构化的覆盖率报告第五步推送分支第六步创建 PR自动生成包含变更内容、变更原因和测试方法的 PR 标题和描述。智能测试框架检测——能根据项目结构和配置文件自动识别并运行正确的测试框架无需手动配置支持 Node.js、Ruby、Python、Go、Rust 等多种语言生态。覆盖率审计——自动识别变更文件中缺少测试覆盖的部分在创建 PR 前主动提示并建议补充测试确保代码质量防线。结构化输出——完成后输出格式化的 Ship Report包括分支名称、基础分支、测试结果、覆盖率变化和 PR 链接等关键信息。使用场景包括需要频繁提交 PR 的敏捷开发团队、对代码质量测试覆盖率有明确要求的项目、以及希望将发布流程标准化和自动化的工程团队。该技能的设计哲学是“将例行工作从人的记忆中转移到自动化流程中”让开发者专注于编码本身而非发布流程的繁琐操作。Ship — From Code Complete to PRYou are the release engineer. Take this branch from “done coding” to “PR ready for review.”Related skills:review | land-and-deploy | qaStep 0: Detect Base Branchgh pr view --json baseRefName -q .baseRefNameFallback:gh repo view --json defaultBranchRef -q .defaultBranchRef.nameFallback:mainStep 1: Sync with Basegitfetch originbase--quietgitmerge origin/base--no-editIf conflicts: resolve them. If complex conflicts, ask the user.Step 2: Run Tests# Detect and run the projects test suitenpmtest# Node.jsbundleexecrake# Rubypytest# Pythongotest./...# Gocargotest# RustAll tests must pass.If tests fail:Read the failure outputFix the failing test (if it’s a real bug, fix the bug)Re-run testsIf stuck after 3 attempts, ask the userStep 3: Coverage AuditCheck test coverage for files changed in this branch:gitdifforigin/base--name-onlyFor each changed file, check if corresponding tests exist. Flag gaps:COVERAGE AUDIT ═══════════════════════════════════════ Changed files: 12 With tests: 9 Missing tests: 3 - src/services/billing.ts (new service, no tests) - src/utils/formatter.ts (new utility, no tests) - src/api/webhook.ts (new endpoint, no tests) ═══════════════════════════════════════If missing tests, write them before proceeding (unless the user explicitly opts out).Step 4: Push Branchgitpush-uorigin HEADStep 5: Create PRGenerate a PR with:Title: Concise description of the changeBody: What changed, why, and how to testLabels: If applicable (bug, feature, refactor)ghprcreate--title...--body...Step 6: Post-Ship ChecklistTests passCoverage gaps addressed or acknowledgedNo uncommitted changesPR description is clearDocumentation updated (suggest document-release if needed)OutputSHIP REPORT ═══════════════════════════════════════ Branch: feature/my-feature Base: main Tests: 42 pass, 0 fail Coverage: 9 new tests PR: github.com/org/repo/pull/123 ═══════════════════════════════════════After the PR is approved, use land-and-deploy to merge and deploy. 发布自动化流程_ship
以下为本文档的中文说明ship 是一个发布工程自动化技能其核心使命是将一个功能分支从“代码完成”状态推进到“PR 就绪可审查”状态只需一条命令即可完成。该技能实现了软件开发中最令人生厌但又不可或缺的环节——在编码完成后、提交审查前的一系列检查和准备工作的自动化。该技能的核心特点包括六步标准工作流——第一步自动检测基础分支第二步与基础分支同步git fetch git merge复杂冲突时询问用户第三步运行测试自动检测项目类型并运行对应的测试框架npm test、bundle exec rake、pytest、go test ./…、cargo test 等第四步覆盖率审计对比分支变更的文件检查是否存在缺少对应的测试代码输出结构化的覆盖率报告第五步推送分支第六步创建 PR自动生成包含变更内容、变更原因和测试方法的 PR 标题和描述。智能测试框架检测——能根据项目结构和配置文件自动识别并运行正确的测试框架无需手动配置支持 Node.js、Ruby、Python、Go、Rust 等多种语言生态。覆盖率审计——自动识别变更文件中缺少测试覆盖的部分在创建 PR 前主动提示并建议补充测试确保代码质量防线。结构化输出——完成后输出格式化的 Ship Report包括分支名称、基础分支、测试结果、覆盖率变化和 PR 链接等关键信息。使用场景包括需要频繁提交 PR 的敏捷开发团队、对代码质量测试覆盖率有明确要求的项目、以及希望将发布流程标准化和自动化的工程团队。该技能的设计哲学是“将例行工作从人的记忆中转移到自动化流程中”让开发者专注于编码本身而非发布流程的繁琐操作。Ship — From Code Complete to PRYou are the release engineer. Take this branch from “done coding” to “PR ready for review.”Related skills:review | land-and-deploy | qaStep 0: Detect Base Branchgh pr view --json baseRefName -q .baseRefNameFallback:gh repo view --json defaultBranchRef -q .defaultBranchRef.nameFallback:mainStep 1: Sync with Basegitfetch originbase--quietgitmerge origin/base--no-editIf conflicts: resolve them. If complex conflicts, ask the user.Step 2: Run Tests# Detect and run the projects test suitenpmtest# Node.jsbundleexecrake# Rubypytest# Pythongotest./...# Gocargotest# RustAll tests must pass.If tests fail:Read the failure outputFix the failing test (if it’s a real bug, fix the bug)Re-run testsIf stuck after 3 attempts, ask the userStep 3: Coverage AuditCheck test coverage for files changed in this branch:gitdifforigin/base--name-onlyFor each changed file, check if corresponding tests exist. Flag gaps:COVERAGE AUDIT ═══════════════════════════════════════ Changed files: 12 With tests: 9 Missing tests: 3 - src/services/billing.ts (new service, no tests) - src/utils/formatter.ts (new utility, no tests) - src/api/webhook.ts (new endpoint, no tests) ═══════════════════════════════════════If missing tests, write them before proceeding (unless the user explicitly opts out).Step 4: Push Branchgitpush-uorigin HEADStep 5: Create PRGenerate a PR with:Title: Concise description of the changeBody: What changed, why, and how to testLabels: If applicable (bug, feature, refactor)ghprcreate--title...--body...Step 6: Post-Ship ChecklistTests passCoverage gaps addressed or acknowledgedNo uncommitted changesPR description is clearDocumentation updated (suggest document-release if needed)OutputSHIP REPORT ═══════════════════════════════════════ Branch: feature/my-feature Base: main Tests: 42 pass, 0 fail Coverage: 9 new tests PR: github.com/org/repo/pull/123 ═══════════════════════════════════════After the PR is approved, use land-and-deploy to merge and deploy.