laily
a15a046e4e
Promote ship to the user-facing delivery skill. Kind is short or long from an explicit mode, then self-judgment, then a question, defaulting to short. Old names remain deprecation stubs.
53 lines
2.2 KiB
Markdown
53 lines
2.2 KiB
Markdown
---
|
|
name: pr-ship
|
|
description: >-
|
|
处理已有 PR/MR：检查差异、审核和 CI，必要时修复阻塞项，合并后以合并 commit 做完整回归，
|
|
再按配置构建、发布和部署。用户说处理、合并、回归或发布 PR 时使用。
|
|
---
|
|
|
|
# PR Ship：合并后的完整交付
|
|
|
|
当前会话只做管理：绑 ship id、按 `next_step.py` 开新 agent 并等待。不要在本会话
|
|
审 diff、合并或跑回归。
|
|
|
|
## 何时使用
|
|
|
|
- 用户提供 PR/MR 或要求处理当前 PR。
|
|
- 用户要求合并 PR 后完整回归并部署。
|
|
|
|
## 不适用
|
|
|
|
- 没有 PR、需要从零做小改动或修 bug：使用 `ship`。
|
|
- 复杂需求尚未形成批准 PRD：使用 `specifier` 和 `ship` long 模式。
|
|
- 只做 diff 审查、不合并：使用 `check`。
|
|
|
|
## 工作规则
|
|
|
|
1. 读取已安装 ship 的 [manager.md](../ship/references/manager.md)。派发 worker 时再读
|
|
[worker-prompt.md](../ship/references/worker-prompt.md)。从 PR 正文、分支名或
|
|
用户给出的 id 绑定已有 ship；没有则用 PR 标题生成 slug，创建 `kind: short` 的
|
|
薄记录，`source.kind: pr`。之后证据都写进这个 ship id。
|
|
2. 只跑：
|
|
|
|
```bash
|
|
python3 <ship-skill>/scripts/next_step.py \
|
|
--project-root <root> --ship-id <id> --entry pr
|
|
```
|
|
|
|
检查、修复、合并、回归、obtain、发布、部署都是 worker。主会话只写 `source.ref`
|
|
和等待结果。需要字段含义时再读 [record.md](../ship/references/record.md)。
|
|
3. 合并后的回归和构建必须以合并 commit 为来源；worker 会写 `commits.role: merged`。
|
|
|
|
不要读取 `check`、`delivery-loop`、`tester`、`builder`、`deployer`、`releaser`。
|
|
|
|
## 安全门
|
|
|
|
- 开不出新 agent 时停止；worker 失败时不要自己把该步做完。
|
|
- 不绕过审核、CI、分支保护或冲突；不强推、不重写已共享历史。
|
|
- 不用 PR 源分支的旧 APK/镜像证明合并版本已发布。
|
|
- 目标分支变化、合并后代码漂移、回归失败、产物来源不明或部署健康检查失败时停止。
|
|
|
|
## 完成报告
|
|
|
|
报告 ship id、PR/MR、审核/CI 结果、合并 commit、完整回归证据、产物摘要、tag、部署目标、健康检查和回滚点。数字来自账本。
|