.pouch/skills/ship/SKILL.md

name, description

name	description
ship	short-ship、long-ship、pr-ship、specifier 共用的交付记录格式。一次交付一个 ship-id，目录在 .pouch/ship/{id}/。新建 id 使用 YYYYMMDD-短语，例如 20261014-dynamic-editor。不单独作为用户入口；用户说 short-ship、 long-ship、交付记录、ship id 时由对应入口读取本 skill。

Ship：一次交付的记录

这是内部记录契约，不替用户选择 short 或 long，也不执行构建或部署。

使用方式

short-ship / long-ship / pr-ship 的主会话只编排：读 manager.md，按 scripts/next_step.py 开新 agent；派发时 用 worker-prompt.md。

创建目录用 scripts/create_ship.py，改证据指针用 scripts/append_evidence.py， 写回后跑 scripts/validate_ship.py。

不可违反的规则

• 进入 short-ship / long-ship / pr-ship 的第一件事是拿到或创建 ship-id。没有 id 不得改业务代码、不得跑 tester / obtain / deploy。
• 入口主会话不得加载 hunt / tester / builder / deployer / releaser / check / specifier / delivery-loop，也不得亲自执行这些步骤；开不出新 agent 时停止。
• 记录只写 .pouch/ship/<ship-id>/。功能、小改动和本次修复的任务不要写入 .pouch/ack/tasks.yaml。ACK 任务板只收缺陷；缺陷要交付时在 ship 的 source 里引用。
• ship-id 用稳定短 slug：小写字母开头，小写字母、数字、连字符，最长 64。不要用日期、 随机数或当前分支名冒充业务 id。
• 短长同一套字段。kind: short 恰好 1 条 task；kind: long 是 DAG，子任务默认不是 新的 ship。
• tester / builder / deployer 的 SSOT 仍在各自目录。ship 只追加指针。本轮跑过的 测试、obtain、部署若没写入 current.yaml 的 evidence，该阶段不算完成。
• 新建 ship 的任务带 testPlan，开发 worker 把新增/修改测试写入 2-develop/test-manifest.yaml；verify 按 manifest 的 selector 执行，regress 再叠加 所有 tester catalog 根和项目原生完整测试。没有测试时必须有明确批准的 testGap。
• 项目构建/部署契约仍在 .pouch/ack/delivery.yaml 和 builder/deployer 配置里，不要 复制进每个 ship。
• 旧的 .pouch/specifier/features/<id>/ 在继续该需求时迁到 .pouch/ship/<id>/spec/，规则见 record.md。

结果

有效 ship 目录含 current.yaml、spec.md、tasks.yaml、status.md；long 另有 spec/ 下的 PRD 与 handoff。校验通过后入口 skill 才能继续交付。