chore: sync pouch skill workflows

skills/pr-ship/SKILL.md

@@ -7,7 +7,8 @@ description: >-
 
 # PR Ship：合并后的完整交付
 
-重点是合并后的真实状态：PR 分支通过不代表目标分支已回归，也不代表产物和生产已更新。
+当前会话只做管理：绑 ship id、按 `next_step.py` 开新 agent 并等待。不要在本会话
+审 diff、合并或跑回归。
 
 ## 何时使用
 
@@ -22,29 +23,30 @@ description: >-
 
 ## 工作规则
 
-1. 读取已安装的 `ship` skill。从 PR 正文、分支名或用户给出的 id 绑定已有 ship；没有则
-   用 PR 标题生成 slug，创建 `kind: short` 的薄记录，`source.kind: pr`。之后证据都写进
-   这个 ship id。
-2. 读取 PR 的目标/源分支、差异、关联任务、审核状态、CI、冲突和变更风险；使用 `check`。
-3. 审核、CI 或必需检查缺失时停止。若发现可修复问题，只有当前请求明确包含修复时才在 PR 分支上处理，
-   然后重新验证；不能静默改变 PR 范围。
-4. 具备合并条件后执行合并，并重新获取目标分支；记录合并后的 commit，后续所有回归和构建都以它为来源。
-5. 读取并执行 `delivery-loop` 的状态机，运行完整回归；失败时停在合并后的中间状态或回到修复流程，不部署失败版本。
-   每个完成阶段把指针写入该 ship 的 `current.yaml`。
-6. 只有项目 profile 和当前授权允许时才构建、发布和部署；生产部署完成后做节点状态和关键路径检查。
+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` skill 与 `references/record.md`。
-- 执行交付阶段时读取已安装的 `delivery-loop` skill 及其状态机 reference。
-- 发布版本时遵循 `releaser`；构建/部署/回归分别遵循 `builder`、`deployer`、`tester`。
-
 ## 完成报告
 
-报告 ship id、PR/MR、审核/CI 结果、合并 commit、完整回归证据、产物摘要、tag、部署目标、健康检查和回滚点。
+报告 ship id、PR/MR、审核/CI 结果、合并 commit、完整回归证据、产物摘要、tag、部署目标、健康检查和回滚点。数字来自账本。