60 lines
2.8 KiB
Markdown
60 lines
2.8 KiB
Markdown
---
|
|
name: short-ship
|
|
description: >-
|
|
处理范围已清楚的单次变更：小功能、文案、加按钮，或已有证据的 bug。建立
|
|
ship 记录、改代码、验证，再按配置发 PR、合并、构建或部署。触发词：short-ship、
|
|
小需求、小改动、修 bug、改文案、加按钮。复杂需求用 long-ship；已有 PR 用 pr-ship。
|
|
---
|
|
|
|
# Short Ship：单次变更到交付
|
|
|
|
当前会话只做管理：建账本、问用户、按 `next_step.py` 开新 agent 并等待。不要把
|
|
hunt / 改代码 / 测试 / 交付读进本会话。
|
|
|
|
## 何时使用
|
|
|
|
- 加按钮、改文案、改短描述、单页小功能，目标与验收已经明确。
|
|
- 用户报告错误、回归、崩溃或明确要求修 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 技能正文。
|