feat: rename bugfix-ship/requirement-flow to short-ship/long-ship with shared ship records

short-ship and long-ship share one ship-id record under .pouch/ship/<id>/.
specifier writes PRDs into spec/; delivery-loop appends evidence pointers.
Old names stay as deprecation stubs so existing installs keep working.

skills/pr-ship/SKILL.md

@@ -16,18 +16,22 @@ description: >-
 
 ## 不适用
 
-- 没有 PR、需要从零修 bug：使用 `bugfix-ship`。
-- 复杂需求尚未形成批准 PRD：使用 `specifier` 和 `requirement-flow`。
+- 没有 PR、需要从零做小改动或修 bug：使用 `short-ship`。
+- 复杂需求尚未形成批准 PRD：使用 `specifier` 和 `long-ship`。
 - 只做 diff 审查、不合并：使用 `check`。
 
 ## 工作规则
 
-1. 读取 PR 的目标/源分支、差异、关联任务、审核状态、CI、冲突和变更风险；使用 `check`。
-2. 审核、CI 或必需检查缺失时停止。若发现可修复问题，只有当前请求明确包含修复时才在 PR 分支上处理，
+1. 读取已安装的 `ship` skill。从 PR 正文、分支名或用户给出的 id 绑定已有 ship；没有则
+   用 PR 标题生成 slug，创建 `kind: short` 的薄记录，`source.kind: pr`。之后证据都写进
+   这个 ship id。
+2. 读取 PR 的目标/源分支、差异、关联任务、审核状态、CI、冲突和变更风险；使用 `check`。
+3. 审核、CI 或必需检查缺失时停止。若发现可修复问题，只有当前请求明确包含修复时才在 PR 分支上处理，
    然后重新验证；不能静默改变 PR 范围。
-3. 具备合并条件后执行合并，并重新获取目标分支；记录合并后的 commit，后续所有回归和构建都以它为来源。
-4. 读取并执行 `delivery-loop` 的状态机，运行完整回归；失败时停在合并后的中间状态或回到修复流程，不部署失败版本。
-5. 只有项目 profile 和当前授权允许时才构建、发布和部署；生产部署完成后做节点状态和关键路径检查。
+4. 具备合并条件后执行合并，并重新获取目标分支；记录合并后的 commit，后续所有回归和构建都以它为来源。
+5. 读取并执行 `delivery-loop` 的状态机，运行完整回归；失败时停在合并后的中间状态或回到修复流程，不部署失败版本。
+   每个完成阶段把指针写入该 ship 的 `current.yaml`。
+6. 只有项目 profile 和当前授权允许时才构建、发布和部署；生产部署完成后做节点状态和关键路径检查。
 
 ## 安全门
 
@@ -37,9 +41,10 @@ description: >-
 
 ## 必读资料
 
+- 记录格式：已安装的 `ship` skill 与 `references/record.md`。
 - 执行交付阶段时读取已安装的 `delivery-loop` skill 及其状态机 reference。
 - 发布版本时遵循 `releaser`；构建/部署/回归分别遵循 `builder`、`deployer`、`tester`。
 
 ## 完成报告
 
-报告 PR/MR、审核/CI 结果、合并 commit、完整回归证据、产物摘要、tag、部署目标、健康检查和回滚点。
+报告 ship id、PR/MR、审核/CI 结果、合并 commit、完整回归证据、产物摘要、tag、部署目标、健康检查和回滚点。