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.
This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
# short-ship
|
||||
|
||||
把一次范围清楚的改动(小功能、文案、已确认的 bug)从说明推进到配置允许的 PR、合并或部署。
|
||||
|
||||
## 什么时候使用
|
||||
|
||||
```text
|
||||
给列表页加一个导出按钮,测完后发 PR。
|
||||
```
|
||||
|
||||
或:
|
||||
|
||||
```text
|
||||
修复这个线上回归,完整验证并部署到测试环境。
|
||||
```
|
||||
|
||||
## 使用前准备
|
||||
|
||||
- 同时安装 `ship`(记录格式)和 `delivery-loop`。
|
||||
- 目标已经说清,或有可复现的问题描述、截图、日志。
|
||||
- 项目已配置测试环境和所需 builder/tester/deployer 能力。
|
||||
- 若要外部发布,明确允许的停止点或使用项目 profile。
|
||||
|
||||
## Agent 会做什么
|
||||
|
||||
建立 ship 记录,写短需求说明,改代码并验证,再继续完成配置允许的交付阶段。一次交付一个 ship id。
|
||||
|
||||
## 如何判断完成
|
||||
|
||||
你会得到 ship id、说明、测试证据、PR/合并/tag、产物和部署状态;不会只收到“本地测试通过”。
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: short-ship
|
||||
description: >-
|
||||
处理范围已清楚的单次变更:小功能、文案、加按钮,或已有证据的 bug。建立
|
||||
ship 记录、改代码、验证,再按配置发 PR、合并、构建或部署。触发词:short-ship、
|
||||
小需求、小改动、修 bug、改文案、加按钮。复杂需求用 long-ship;已有 PR 用 pr-ship。
|
||||
---
|
||||
|
||||
# Short Ship:单次变更到交付
|
||||
|
||||
把一次范围清楚的改动推进到项目配置允许的停止点。
|
||||
|
||||
## 何时使用
|
||||
|
||||
- 加按钮、改文案、改短描述、单页小功能,目标与验收已经明确。
|
||||
- 用户报告错误、回归、崩溃或明确要求修 bug,并且能指出问题。
|
||||
- 用户要求改完后继续测试、发 PR、合并、构建、发布或部署。
|
||||
|
||||
## 不适用
|
||||
|
||||
- 跨模块、要方案取舍、要多任务协作:使用 `long-ship` 和 `specifier`。
|
||||
- 已有 PR 的合并和发布:使用 `pr-ship`。
|
||||
- 只做根因分析、不改代码:使用 `hunt`。
|
||||
|
||||
## 工作规则
|
||||
|
||||
1. 读取已安装的 `ship` skill。没有 `ship-id` 就从需求生成候选 slug,用
|
||||
`scripts/create_ship.py --kind short` 建 `.pouch/ship/<id>/`;已有目录则校验后复用。
|
||||
写 `spec.md` 四段:要做什么、不做什么、可观察验收、怎么验。有故障证据时加复现和根因。
|
||||
任务保持恰好 1 条。功能任务不要写入 `.pouch/ack/tasks.yaml`。
|
||||
2. 有故障证据时使用 `hunt` 确认根因、复现和验收信号。纯小需求跳过 hunt。
|
||||
3. 修改代码并补或更新回归用例;行为、API、图片、UI 改动不得只跑编译。
|
||||
4. 使用 `tester` 做黑盒、浏览器或真机验证;涉及资源加载时检查真实 URL、状态、类型、
|
||||
内容和截图。跑完立刻用 ship `append_evidence.py --kind testRun` 追加指针。
|
||||
5. 读取并执行 `delivery-loop`。停止点由用户或项目 delivery profile 决定,canonical
|
||||
为 `verified`、`validation_ready`、`review_ready` 或 `released`。每个完成阶段都要把
|
||||
对应指针写入该 ship 的 `current.yaml`;缺指针则阶段未完成。需要产物时只调用
|
||||
builder `obtain.sh --sha <merged-or-pushed-commit>`。
|
||||
6. 范围涨到需要 PRD 或多条任务时,同一 `ship-id` 把 `kind` 改为 `long`,交给
|
||||
`long-ship`,不要另开 id。
|
||||
|
||||
## 安全门
|
||||
|
||||
- 没有 ship-id、spec.md 四段不齐、验收不可观察时停止。
|
||||
- 根因不清、测试缺失、真机不可达、CI/回归失败或工作树有无关改动时停止并说明。
|
||||
- 不强推、不覆盖他人分支、不绕过 PR 审核,不把测试环境成功当生产成功。
|
||||
- 数据迁移、破坏性 API、权限/密钥、安全修复和不可逆生产操作需要额外确认。
|
||||
|
||||
## 必读资料
|
||||
|
||||
- 记录格式:已安装的 `ship` skill 与 `references/record.md`。
|
||||
- 交付阶段:已安装的 `delivery-loop` 及其状态机 reference。
|
||||
- 测试、构建、部署、提交前审查:项目的 `tester`、`builder`、`deployer`、`check`、
|
||||
`releaser`。
|
||||
|
||||
## 完成报告
|
||||
|
||||
报告 ship id、spec 路径、根因(若有)、变更、测试/真机证据指针、停止点、commit、
|
||||
PR/tag、产物摘要、部署状态和未完成项。
|
||||
@@ -0,0 +1,6 @@
|
||||
interface:
|
||||
display_name: "Short Ship"
|
||||
short_description: "Ship a small change or bug fix through verification and delivery"
|
||||
default_prompt: "Use $short-ship to implement this small change, verify it, and continue to the configured delivery stop."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
Reference in New Issue
Block a user