用途
ship 是一个部署智能体，用于把已经批准的功能部署到生产环境。它通常在 /document 完成后使用，负责创建 Pull Request、运行部署前检查，并更新 TASKS.md。它支持通过任务 ID 来定位和处理具体任务。
主要能力
- 解析任务 ID，找到对应的任务文档。
- 在 TASKS.md 中验证任务处于“Approved”状态。
- 检查任务文档中的 Automation 字段（manual | auto）。
- 将任务移动到 TASKS.md 中的“Ready to Ship”。
- 运行部署前检查：build、typecheck、lint。
- 检查分支是否已存在于 origin（worktree 流程）。
- 创建带 [task-{ID}] 引用的 Pull Request。
- 在 TASKS.md 中更新 PR 链接。
- 合并后更新“Merged”列，但任务仍停留在“Ready to Ship”，直到 /release 将其移至“Shipped”并附带版本号。
使用方式
命令格式为 /ship {ID}。执行后按以下工作流进行：
- 解析任务 ID → 找到任务文档
- 在 TASKS.md 中验证任务处于“Approved”
- 检查 Automation 字段（manual | auto）
- 移动到 TASKS.md 中的“Ready to Ship”
- 运行部署前检查（build、typecheck、lint）
- 检查分支是否已存在于 origin（worktree 流程）
- 创建带 [task-{ID}] 引用的 Pull Request
- 更新 TASKS.md 中的 PR 链接
合并后 → 更新“Merged”列（仍停留在“Ready to Ship”）
/release → 移至“Shipped”并附带版本号
注意：条目在合并后仍停留在“Ready to Ship”，只有 /release 才会把条目移到“Shipped”。
自动模式行为
当任务文档中带有 Automation: auto 时，输出如下信号：
≡ SIGNAL
STAGE: ship
STATUS: DONE
TASK: {ID}
SUMMARY: PR #{number} created and ready for review
PR: {full PR URL}
≡ END
编排器接收该信号后，显示流水线完成摘要并退出。自动模式不会自动合并。
部署前检查清单
1. 验证批准
- 任务位于 TASKS.md 的“Approved”部分
- 功能文档存在
- 测试报告显示 PASS
2. 审查变更
git status
git diff main...HEAD
- 所有预期文件已变更
- 没有意外变更
- 没有敏感文件（.env、credentials）
3. 运行部署前检查
pnpm build
pnpm typecheck
pnpm lint
创建 PR 前必须全部通过。
Git 工作流
分支策略
feature/{ID}-{task-name} - 新功能
fix/{ID}-{task-name} - Bug 修复
enhance/{ID}-{task-name} - 增强
如果分支已存在于 origin（Worktree 流程）
先检查：
git ls-remote --heads origin feature/{ID}-{task-name}
如果存在 → 不检出，直接创建 PR：
gh pr create --base main --head feature/{ID}-{task-name} --title ...
如果分支不存在（手动 / 回退流程）
git checkout -b feature/{ID}-{task-name}
git add {files-changed-by-this-task}
git commit -m "[task-{ID}] feat: {description}
{Detailed description of changes}
Task: docs/task/{ID}-{task-name}.md
Test: docs/testing/{ID}-{task-name}.md
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"
git push -u origin feature/{ID}-{task-name}
创建 Pull Request
gh pr create --title "[Task #{ID}] {PR Title}" --body "$(cat <<'EOF'
## Summary
{2-3 bullet points describing the changes}
## Task Documentation
- **Task ID:** #{ID}
- **Task Doc:** [docs/task/{ID}-{task-name}.md](link)
- **Test Report:** [docs/testing/{ID}-{task-name}.md](link)
- **Feature Doc:** [docs/features/{feature}.md](link)
## Changes
| File | Change |
|------|--------|
| `path/to/file` | Description |
## Commits
{List commits with [task-{ID}] prefix}
## Testing
- [x] E2E tests passed (see test report)
- [x] Manual testing completed
- [ ] Ready for code review
---
Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
更新 TASKS.md
移动到 Ready to Ship 后：
| ID | Task | Branch | PR | Merged | Task Doc |
|---|
- 创建 PR 后：添加 PR 链接。
- PR 合并后：用日期更新“Merged”列——条目在 /release 之前一直停留在“Ready to Ship”。
合并后，更新任务文档：
Status: MERGED Merged: {Date} PR: #{number}
PR 检查清单
| 类别 | 检查项 |
|---|---|
| 代码质量 | Build 通过、无 TypeScript 错误、lint 通过、无 console.log、无注释掉的代码 |
| 文档 | 任务文档完整、测试报告 PASS、功能文档已更新、用户指南已更新（如面向用户） |
| 安全 | 无硬编码密钥、无 .env 文件、无暴露的 API 密钥、正确的认证检查 |
| 测试 | E2E 测试通过、手动测试完成、边界情况已处理 |
摘要输出
- 手动模式：输出 PR URL、分支名称、部署前检查结果，以及后续步骤（审查/合并 PR，然后 /release）。
- 自动模式：按上述格式输出 SIGNAL 并退出。
适用场景
适用于在 /document 完成后，将已批准的功能部署到生产环境，尤其是需要创建 PR、运行部署前检查并同步更新 TASKS.md 的工作流。
限制
- 自动模式不会自动合并。
- 条目在合并后仍停留在“Ready to Ship”，只有 /release 才会将其移至“Shipped”。
- 创建 PR 前，build、typecheck、lint 必须全部通过。
- 关于收费、价格、平台支持范围等信息，资料中暂未提供。