# /workflow-ship - 预检、提交、推送、PR 你是一名运输助理。您的工作是通过运行质量检查、提交、推送和打开 PR 来交付当前分支。对所有用户提示使用“AskUserQuestion”，以便流程快速且只需最少的输入。 ## 流程 ### 第 1 步：飞行前检查运行“/workflow-preflight”技能来执行类型检查、lint 和测试检查。如果任何检查失败： 1. 尝试自动修复问题（lint --fix、格式等） 2. 重新运行失败的检查以确认修复有效 3. 如果应用了修复，**在此停止**并告诉用户： * 失败的内容和修复的内容 * 要求他们在发货前检查修复情况 * 告诉他们一旦满意就再次运行“/workflow-ship” 4. 如果修复失败或问题无法自动解决，**在此停止**并报告剩余问题如果所有检查均通过且无需修复，请继续执行步骤 2。 ### 第 2 步：分支 + 提交首先，确定当前分支： git 分支 --显示当前然后运行“git status”（从不-uall）和“git diff”来了解更改。如果没有变化，请告诉用户并停止。 **分支提示：** 使用 `AskUserQuestion` 询问用户在哪里提交： * 如果在 `main` 或 `master` 上：不允许直接提交。目前的选项： *“创建新分支”（描述：“为这些更改创建功能/修复分支”） * 用户选择“其他”来输入自定义分支名称 * 如果在任何其他分支（staging、feature/_、fix/_ 等）：当前选项： *“当前分支 ({branch_name})”（描述：“直接提交到 {branch_name}”）- 标记为第一个/推荐选项 *“创建新分支”（描述：“为这些更改创建一个新分支 {branch_name}”）如果用户选择“创建新分支”或通过“其他”输入自定义名称： 1. 创建并签出新分支：`git checkout -b ` 然后继续提交： 1. 运行 `git log --oneline -5` 以匹配存储库的提交消息样式 2.暂存相关文件（优先选择特定文件而不是`git add -A`） 3. 起草一份简洁的提交信息，重点关注“为什么” 4. 使用 Co-Authored-By 预告片创建提交：共同创作者：Claude Opus 4.6 5. 对提交消息使用 HEREDOC 以确保格式正确 ### 第 3 步：推送 1. 检查当前分支是否跟踪远程： `git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null` 2. 如果没有设置上游，则使用“-u”标志推送到远程，否则正常推送 3.验证推送成功 ### 第 4 步：创建公关首先，收集上下文： # 当前分支 git 分支 --显示当前 # 检查原点是否存在暂存 git ls-remote --heads 原点暂存 # 检查 main 是否存在于 origin 上 git ls-remote --heads 起源主要 **PR 目标提示：** 使用 `AskUserQuestion` 询问 PR 应该合并到哪里。根据现有内容动态构建选项： * 如果当前分支是 `staging`：仅提供 `main` （并且“其他”始终可用于自定义输入） * 如果当前分支是其他分支（feature/_、fix/_ 等）： * 如果原点存在 `staging`：提供以下选项： *“staging”（描述：“合并到 staging 进行预生产审核”）- 标记为第一个/推荐 *“main”（描述：“直接合并到主/生产中”） * 如果原点不存在“staging”：提供以下选项： *“main”（描述：“合并到main”）-标记为第一个/推荐用户始终可以选择“其他”来键入任何自定义分支名称。然后创建 PR： 1. 运行 `git log ..HEAD --oneline` 以了解包含的所有提交 2. 运行 `git diff ...HEAD` 查看完整的差异 3. 使用 `gh pr create` 创建 PR： * `--base ` 设置合并目标 * 简短标题（70 个字符以下） * 正文包含摘要项目符号和测试计划 * 正文使用 HEREDOC 格式 * 包含克劳德代码归属页脚格式： gh pr create --base --title "pr 标题" --body "$(cat <<'EOF' ## 总结 <1-3要点> ## 测试计划 <测试步骤清单> 🤖 使用 [Claude 代码](https://claude.com/claude-code) 生成 EOF ）” 4.将PR URL返回给用户 ## 重要规则 * 始终使用 `AskUserQuestion` 作为分支和 PR 目标提示（永远不要假设） * 切勿跳过飞行前检查 * 切勿强行推动 * 切勿直接提交或推送到 main/master * 如果没有要提交的更改，则告诉用户并停止 * 不要提交看起来像秘密的文件（.env、凭据等）

工作流程船

包含技能