wemilabs/ship-to-prod

交付到生产

当用户在完成工作后说“ship it”或类似的话时，无需二次确认，直接执行以下步骤。

流程取决于当前所在分支。一次性检测环境，然后在后续步骤中复用。

检测环境

在开始时并行执行以下检测操作：

1. 包管理器：在仓库根目录检查 lockfile。
   • pnpm-lock.yaml -> pnpm
   • yarn.lock -> yarn
   • bun.lockb 或 bun.lock -> bun
   • package-lock.json -> npm
   • 如果 package.json 中包含 packageManager 字段，则使用该字段。
   • 如果未找到任何，默认使用 npm。
2. 默认分支：git symbolic-ref refs/remotes/origin/HEAD（或回退到 git config init.defaultBranch）。如果两者都失败，则默认使用 main。
3. PR 工具：gh --version。如果已安装并认证了 gh，则使用它来创建和合并 PR。否则，回退到打印 PR URL，让用户手动创建。
4. Shell：检测当前 shell。在 Windows（PowerShell）上，heredoc 无法工作，因此对 git commit 使用多个 -m 标志。在 bash/zsh/fish 以及其他 Unix shell 上，使用 heredoc。

将这些检测结果存储为 <pkg>、<default-branch>、<gh-available> 和 <shell>，供后续流程使用。

步骤

1. 清理（可选）

在提交之前，有两个技能可以清理 AI 生成的垃圾代码。如果两者都可用，则运行它们：

• deslop：从 diff 中移除 AI 代码糟粕（不必要的注释、对可信路径的防御性检查、any 类型转换、深层嵌套）。针对当前与默认分支之间的 diff 调用它。
• unslop：从散文中移除 AI 文本痕迹（UI 字符串、注释、提交信息、PR 描述）。针对本次会话中编写的任何文本调用它。

在继续之前，修复这两个技能标记的所有问题。

如果某个技能未安装，不要只是静默跳过。询问用户是否要安装缺失的技能，并提供以下选项。提及这两个技能均来自 Cursor AI 的官方插件仓库（https://github.com/cursor/plugins），因此是可信来源：

• 全局安装（供未来所有项目使用）：npx skills add https://github.com/cursor/plugins --skill deslop unslop -g
• 本地安装（仅限此项目）：npx skills add https://github.com/cursor/plugins --skill deslop unslop
• 跳过本次运行：继续流程，不安装缺失的技能。不要因为缺失可选依赖而阻塞整个流程。

使用 ask_user_question 工具来呈现选项。如果用户选择全局或本地安装，则运行安装命令，然后在调用之前重新检查该技能现在是否可用。如果安装失败或用户选择跳过，则使用当前可用的技能继续流程。

2. 验证工作

按顺序运行以下命令，在继续之前修复任何问题。将 <pkg> 替换为检测到的包管理器。npm 始终需要 run（例如 npm run format）；pnpm/yarn/bun 允许直接调用（例如 pnpm format）：

1. <pkg> run format（对于 pnpm/yarn/bun 使用 <pkg> format）：自动格式化
2. <pkg> run lint（对于 pnpm/yarn/bun 使用 <pkg> lint）：修复您修改过的文件中的 lint 错误（忽略其他文件中已有的问题）
3. <pkg> run typecheck（对于 pnpm/yarn/bun 使用 <pkg> typecheck）：必须以退出码 0 通过
4. <pkg> run build（对于 pnpm/yarn/bun 使用 <pkg> build）：必须以退出码 0 通过

如果某个脚本缺失（例如没有 format 脚本），则跳过该步骤并记录下来。不要因为缺失可选脚本而中断整个流程。typecheck 和 build 如果存在则是必需的；如果两者都不存在，则在发出警告后继续。

在可用检查通过之前，不要继续提交。

如果在验证后 git status 是干净的（没有暂存或未暂存的内容），则报告“没有可交付的内容”并停止。不要尝试空提交。

3. 评估当前分支

运行 git branch --show-current 获取当前分支名称。将其与 <default-branch> 进行比较。然后决定：

• 如果在 <default-branch> 上：直接提交并推送。无需 PR，无需合并。跳到步骤 5。
• 如果在任何其他分支上：提交，推送，创建一个指向 <default-branch> 的 PR 并进行合并。继续执行步骤 4。

4. 审查更改

并行运行 git status、git diff 和 git log --oneline -5，以了解更改的内容并匹配提交风格。

5. 暂存并提交

git add -A，然后使用约定式提交信息（feat/fix/refactor）进行提交。

提交信息格式：

<type>: <short description>

<optional body>

在 bash/zsh/fish 以及其他 Unix shell 上，使用 heredoc：

git commit -m "$(cat <<'EOF'
type: subject

body
EOF
)"

在 PowerShell（Windows）上，heredoc 无法工作，因此使用多个 -m 标志：

git commit -m "type: subject" -m "body"

6. 推送

git push（如果分支尚未设置上游，则使用 git push -u origin <branch>）。

7. 如果在功能分支上：创建 PR 并合并

如果 <gh-available>：

• 将 PR 正文写入一个临时文件，然后使用 --body-file 创建 PR（适用于所有 shell，包括 PowerShell）：
  • gh pr create --base <default-branch> --head <current-branch> --title "<title>" --body-file <temp-file>
• 在 gh pr create 返回后删除临时文件。不要将其留在磁盘上。
• 不指定策略进行合并，以便应用用户的仓库默认设置：
  • gh pr merge <number>

PR 正文格式：

## Summary
<bullet points>

#### Test plan
- [ ] <checklist>

如果 gh 不可用：

• 推送分支（步骤 6）。
• 打印用户应手动打开以创建 PR 的 URL： <repo-url>/compare/<default-branch>...<current-branch>
• 停止。让用户自行创建和合并 PR。不要在没有 gh 的情况下尝试合并。

8. 保持当前分支存活

合并后不要删除工作分支。它将保持打开状态，用于下一个功能。

9. 确认

向用户报告 PR URL（如果适用）以及合并/推送状态。

冲突处理

如果功能分支落后于 <default-branch>，则在推送前进行变基：

git fetch origin <default-branch>
git rebase origin/<default-branch>

解决所有冲突，然后继续推送 + PR + 合并。

注意事项

• 目标始终是检测到的 <default-branch>，而不是硬编码的名称。
• 合并后切勿删除工作分支。
• 如果在 <default-branch> 上，只需提交并推送。不需要 PR。
• 切勿跳过验证步骤，即使时间紧迫。
• deslop 步骤是可选的。如果缺少某个技能，请先提供安装选项（全局或本地），然后再回退到跳过。