feat(ship): merge short-ship and long-ship into one entry

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.
2026-10-24 14:27:19 +08:00
parent 7d6f3fe8e5
commit a15a046e4e
33 changed files with 331 additions and 315 deletions
@@ -1,31 +1,25 @@
-# short-ship
+# short-ship（已弃用）

-把一次范围清楚的改动（小功能、文案、已确认的 bug）从说明推进到配置允许的 PR、合并或部署。
+`short-ship` 已并入 [ship](../ship/README.md)。本目录只是兼容占位，
+让旧项目里的 `.pouch.yaml`、已经装好的旧软链和旧说法不至于失效；真正的说明和流程都在
+`ship/`。命中后按 **short 模式** 执行。

-## 什么时候使用
+## 使用示例

 ```text
-给列表页加一个导出按钮，测完后发 PR。
+使用 short-ship，给列表页加一个导出按钮，测完后发 PR。
 ```

-或：
+Agent 命中后会立刻转到 `ship`，按 short 模式执行。新请求建议直接用 `ship`，需要时可写
+`short 模式`。

-```text
-修复这个线上回归，完整验证并部署到测试环境。
+## 迁移
+
+```bash
+pouch add ship          # 新名，当前项目
+pouch add ship -g       # 新名，全局
 ```

-## 使用前准备
-
- 同时安装 `ship`（记录格式）和 `delivery-loop`。
- 目标已经说清，或有可复现的问题描述、截图、日志。
- 项目已配置测试环境和所需 builder/tester/deployer 能力。
- 若要外部发布，明确允许的停止点或使用项目 profile。
-
-## Agent 会做什么
-
-主会话只建 ship 记录、写短说明、按步骤开新 agent 并等待结果。改代码、测试、开合 PR、
-构建和部署都在新会话里做，不会堆进同一个上下文。一次交付一个 ship id。
-
-## 如何判断完成
-
-你会得到 ship id、说明、测试证据、PR/合并/tag、产物和部署状态；不会只收到“本地测试通过”。
+- 旧软链保持有效，不需要先删除。
+- 各项目 `.pouch.yaml` 里的 `short-ship` 可以分批改成 `ship`。
+- 确认没有项目再按旧名启用后，删除本目录即可；它是纯占位，删除不丢内容。
@@ -1,59 +1,19 @@
 ---
 name: short-ship
 description: >-
-  处理范围已清楚的单次变更：小功能、文案、加按钮，或已有证据的 bug。建立
-  ship 记录、改代码、验证，再按配置发 PR、合并、构建或部署。触发词：short-ship、
-  小需求、小改动、修 bug、改文案、加按钮。复杂需求用 long-ship；已有 PR 用 pr-ship。
+  【已弃用，兼容占位】short-ship 已并入 ship。命中本 skill 时不要在此执行任何
+  流程，直接读取 ../ship/SKILL.md 并按其执行；本次按 short 模式。小需求、小改动、
+  修 bug、改文案、加按钮、修复后发 PR 或部署都属于 ship。
 ---

-# Short Ship：单次变更到交付
+# short-ship（已弃用）

-当前会话只做管理：建账本、问用户、按 `next_step.py` 开新 agent 并等待。不要把
-hunt / 改代码 / 测试 / 交付读进本会话。
+本 skill 已并入 [ship](../ship/SKILL.md)。这里只是兼容占位，**没有流程内容**。

-## 何时使用
-
- 加按钮、改文案、改短描述、单页小功能，目标与验收已经明确。
- 用户报告错误、回归、崩溃或明确要求修 bug，并且能指出问题。
- 用户要求改完后继续测试、发 PR、合并、构建、发布或部署。
-
-## 不适用
-
- 跨模块、要方案取舍、要多任务协作：使用 `long-ship` 和 `specifier`。
- 已有 PR 的合并和发布：使用 `pr-ship`。
- 只做根因分析、不改代码：使用 `hunt`。
-
-## 工作规则
-
-1. 读取已安装 ship 的 [manager.md](../ship/references/manager.md)。派发 worker 时再读
-   [worker-prompt.md](../ship/references/worker-prompt.md)。没有 `ship-id` 就生成
-   slug，跑 `create_ship.py --kind short`。功能任务不要写入 `.pouch/ack/tasks.yaml`。
-2. 主会话只写 `spec.md` 四段和那一条 task。有故障证据时 `next_step.py` 会给出
-   `hunt` worker，不要在本会话读 hunt。
-3. 之后只跑：
-
-   ```bash
-   python3 <ship-skill>/scripts/next_step.py \
-     --project-root <root> --ship-id <id> --entry short
-   ```
-
-   `actor: worker` 就开新 agent 并等待；`ask_user` / `blocked` 就停下来问用户。
-   需要字段含义时再读 [record.md](../ship/references/record.md)。
-4. 范围涨到需要 PRD 或多条任务时，同一 `ship-id` 把 `kind` 改为 `long`，改用
-   `--entry long`。
-
-不要读取 `delivery-loop`、`tester`、`builder`、`deployer`、`check`、`hunt`。
-这些由对应 worker 按 JSON 的 `skill` 加载。
-
-## 安全门
-
- 没有 ship-id、spec.md 四段不齐、验收不可观察时停止。
- 开不出新 agent 时停止；worker 失败时不要自己把该步做完。
- 根因不清、测试缺失、真机不可达、CI/回归失败或工作树有无关改动时停止并说明。
- 不强推、不覆盖他人分支、不绕过 PR 审核，不把测试环境成功当生产成功。
- 数据迁移、破坏性 API、权限/密钥、安全修复和不可逆生产操作需要额外确认。
-
-## 完成报告
-
-报告 ship id、spec 路径、根因（若有）、变更、测试/真机证据指针、停止点、commit、
-PR/tag、产物摘要、部署状态和未完成项。数字来自账本，不要复述 worker 技能正文。
+- 用户提到 `short-ship`、`/short-ship`、`$short-ship` 或 short 模式时：读取
+  [../ship/SKILL.md](../ship/SKILL.md)，按其内容与授权边界执行，并把本次 `kind`
+  定为 `short`。不要在本目录里寻找步骤、references 或 templates。
+- 本目录不保留 `references/` 和 `templates/`，正文只有一份，在 `ship/`。
+- 旧项目 `.pouch.yaml` 里仍写 `short-ship` 也能正常安装，软链不会悬空；方便时改成
+  `ship`。
+- 确认没有项目再按旧名启用后，可以直接删除本目录。
@@ -1,6 +0,0 @@
-interface:
-  display_name: "Short Ship"
-  short_description: "Ship a small change or bug fix through verification and delivery"
-  default_prompt: "You are the short-ship manager: keep the ship record, spawn a fresh agent for each next_step, and wait. Do not hunt, code, test, or deliver in this session."
-policy:
-  allow_implicit_invocation: true