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.
This commit is contained in:
+19
-19
@@ -2,14 +2,14 @@
|
||||
name: specifier
|
||||
description: >-
|
||||
把复杂或跨模块需求整理成可评审、可版本化的 HTML PRD，并在用户明确批准某个版本后
|
||||
生成交给 long-ship 的结构化 handoff。用户说做复杂功能、写 PRD、梳理需求、设计方案、
|
||||
需求评审、反复改需求或交给 long-ship 开发时使用；小改动、Bug 根因排查和单纯架构讨论
|
||||
生成交给 ship 的结构化 handoff。用户说做复杂功能、写 PRD、梳理需求、设计方案、
|
||||
需求评审、反复改需求或交给 ship 开发时使用；小改动、Bug 根因排查和单纯架构讨论
|
||||
不使用。
|
||||
---
|
||||
|
||||
# Specifier：复杂需求规格化
|
||||
|
||||
把模糊需求变成经过人确认的需求基线，再交给 `long-ship` 执行。HTML 是给人评审的正式交付物，
|
||||
把模糊需求变成经过人确认的需求基线，再交给 `ship`（`kind: long`）执行。HTML 是给人评审的正式交付物，
|
||||
结构化状态和 handoff 是给 ship 记录消费的机器接口。
|
||||
|
||||
---
|
||||
@@ -18,12 +18,12 @@ description: >-
|
||||
|
||||
- 用户要做跨模块、跨页面、跨服务或有数据迁移的复杂功能。
|
||||
- 用户要求写 PRD、产品方案、需求规格、架构/交互方案，并需要多轮确认。
|
||||
- 用户要求把确认后的需求交给 `long-ship` 开发。
|
||||
- 用户要求把确认后的需求交给 `ship` 开发。
|
||||
|
||||
## 不适用
|
||||
|
||||
- 单文件或范围明确的小改动：使用 `short-ship`。
|
||||
- 已有复现证据的 Bug：使用 `/hunt` 找根因，再按需要交给 `short-ship`。
|
||||
- 单文件或范围明确的小改动：使用 `ship`（short 模式）。
|
||||
- 已有复现证据的 Bug：使用 `/hunt` 找根因，再按需要交给 `ship`。
|
||||
- 只问一个技术选型或一次性方案判断：使用 `/think`。
|
||||
- 用户尚未批准的需求：不得创建开发任务、派 worker、改业务代码或开始交付。
|
||||
|
||||
@@ -38,14 +38,14 @@ description: >-
|
||||
.pouch/ship/<ship-id>/
|
||||
├── current.yaml # ship 总账；spec.revision / specStatus 在这里
|
||||
├── spec.md # 短摘要
|
||||
├── tasks.yaml # 批准后由 long-ship 写入，本 skill 不写
|
||||
├── tasks.yaml # 批准后由 ship 写入，本 skill 不写
|
||||
└── spec/
|
||||
├── brief.md
|
||||
├── prd-v001.html
|
||||
├── review.yaml
|
||||
├── decisions.yaml
|
||||
├── risks.yaml
|
||||
└── handoff.yaml # 仅 approved 后生成，交给 long-ship
|
||||
└── handoff.yaml # 仅 approved 后生成，交给 ship
|
||||
```
|
||||
|
||||
目录名使用稳定、短、小写连字符的 ship id。若用户未提供，先从需求生成候选并说明；
|
||||
@@ -64,24 +64,24 @@ description: >-
|
||||
- **评审 / 修改**：读取当前版本和 `spec/review.yaml`，把用户意见转成修改项，生成新版本，
|
||||
展示变更摘要和仍未决的问题。
|
||||
- **批准**：只在用户明确批准指定版本后，把 `spec.specStatus` 改为 `approved`，冻结需求基线。
|
||||
- **交接**：仅针对 `approved` 版本生成 `spec/handoff.yaml`；用户要求继续开发时把它交给 `long-ship`。
|
||||
- **交接**：仅针对 `approved` 版本生成 `spec/handoff.yaml`；用户要求继续开发时把它交给 `ship`。
|
||||
- **状态**：只读报告当前版本、待决策、风险和是否可以交接。
|
||||
- 作为 `long-ship` 派来的 worker：只做 prompt 里的那一个模式，写完 `spec/` 就返回；
|
||||
不要再调用 `long-ship`，不要改业务代码。
|
||||
- 作为 `ship` 派来的 worker：只做 prompt 里的那一个模式，写完 `spec/` 就返回；
|
||||
不要再调用 `ship` 入口，不要改业务代码。
|
||||
|
||||
详细评审状态机和确认规则见 [review-loop.md](references/review-loop.md)。HTML 页面结构和
|
||||
渲染要求见 [html-prd.md](references/html-prd.md)。只有需要对应模式时才读取它们。
|
||||
|
||||
## 新建和调研
|
||||
|
||||
1. 先判断需求是否真的复杂；不复杂时给出转 `short-ship` 的建议，不强行生成 PRD。
|
||||
1. 先判断需求是否真的复杂；不复杂时给出转 `ship` short 模式的建议，不强行生成 PRD。
|
||||
2. 读取项目覆盖层、相关文档、历史决策和代码；优先确认现有能力、模块边界、数据模型、
|
||||
API、权限、运行约束和回归用例。不要从 README 或猜测中虚构项目事实。
|
||||
3. 形成现状与目标差异：背景、用户、场景、目标、非目标、范围、约束、成功标准。
|
||||
4. 对关键方案给出取舍，记录推荐方案、被否决方案、最脆弱假设、风险、依赖和回滚方向。
|
||||
5. 描述必要的产品流程、交互状态、领域模型、状态流、API/数据变化和非功能要求。
|
||||
6. 按可独立验证的垂直切片拆任务，写出依赖、关键路径、`expected` 和 `verification`，
|
||||
但不要写入 `.pouch/ack/tasks.yaml` 或本 ship 的 `tasks.yaml`（任务由 long-ship 在批准后创建）。
|
||||
但不要写入 `.pouch/ack/tasks.yaml` 或本 ship 的 `tasks.yaml`（任务由 ship 在批准后创建）。
|
||||
7. 按模板生成自包含 HTML PRD，并在回复中说明文件路径、版本、待确认问题和下一步。
|
||||
8. 用户需要查看 HTML，或说“把这个 HTML 渲染出来”时，读取已安装 `previewer` 的调用契约，
|
||||
直接执行其共享脚本并传入该文件；不要再次委派 Agent 或在 `specifier` 内复制服务代码。
|
||||
@@ -108,20 +108,20 @@ description: >-
|
||||
评审状态，HTML 被展示不等于用户批准。回复提供完整 URL 和有效期；跨设备预览需设置可访问的
|
||||
监听地址，不能把本机 `127.0.0.1` 描述为远程访问地址。
|
||||
|
||||
## 批准和 long-ship 交接
|
||||
## 批准和 ship 交接
|
||||
|
||||
批准前只允许写该 ship 的 spec 目录和 `current.yaml` 的 spec 字段。批准后仍不自动启动
|
||||
worker；先生成 `spec/handoff.yaml`，其中必须绑定：ship id、PRD 版本和路径、需求范围、
|
||||
非目标、决策、任务依赖、验收信号、风险、回滚/发布注意事项和回归候选。同步
|
||||
`current.yaml` 的 `spec.specStatus`、`spec.approvedRevision`、`spec.handoff`。
|
||||
|
||||
`handoff.yaml` 是 `long-ship` 的输入，不是执行记录。用户明确要求继续开发时，提示使用：
|
||||
`handoff.yaml` 是 `ship` long 模式的输入，不是执行记录。用户明确要求继续开发时，提示使用：
|
||||
|
||||
```text
|
||||
/long-ship 使用 handoff：.pouch/ship/<ship-id>/spec/handoff.yaml
|
||||
/ship long 模式 使用 handoff：.pouch/ship/<ship-id>/spec/handoff.yaml
|
||||
```
|
||||
|
||||
long-ship 应引用批准的 HTML 版本，不复制另一份可漂移的 PRD。handoff 缺字段或需求状态
|
||||
ship 应引用批准的 HTML 版本，不复制另一份可漂移的 PRD。handoff 缺字段或需求状态
|
||||
不是 `approved` 时，停止交接并报告缺口。
|
||||
|
||||
## 安全边界
|
||||
@@ -136,5 +136,5 @@ long-ship 应引用批准的 HTML 版本，不复制另一份可漂移的 PRD。
|
||||
|
||||
完成前检查：HTML 可离线打开、版本号与 ship `current.yaml` 的 `spec.revision` 一致、旧版本
|
||||
未被覆盖、每个未决问题有明确状态、每个任务有可观测验收、handoff 只在 `approved` 后存在
|
||||
且绑定正确的 PRD 版本。需要交给 long-ship 时，先确认 handoff schema 与用户批准版本一致，
|
||||
再停止等待 long-ship。
|
||||
且绑定正确的 PRD 版本。需要交给 ship 时，先确认 handoff schema 与用户批准版本一致，
|
||||
再停止等待 ship。
|
||||
|
||||
Reference in New Issue
Block a user