成果完整交付：让合作者交回「拿到就能接手」的包

把活交给别人——合作者、外包，或者另一个 AI——最怕收回来的只有一句「做完了」：不知道产物在哪、怎么用、测没测过、还差什么。

这个 skill 要求交付是一个收件人只拿到它就能接手的包。

包里有什么

START-HERE.md   入口：成果是什么、怎么用、最少接手步骤
artifacts/      最终产物（源码、文档、配置模板）
evidence/       真实跑过的检查：命令、退出码、截图
DELIVERY.json   状态、文件白名单、检查结果、未完成项
MANIFEST.json   每个文件的大小和 SHA-256，由脚本生成

状态只有三种：完成、部分完成、阻塞。三种都可以交，但「部分完成」和「阻塞」必须写清缺什么。

几条硬规矩

• 没跑就写没跑。 每项检查只能是通过、失败或未运行；未运行要写原因，不能暗示通过，更不能编日志。
• 自测不等于验收。 包里的「独立验收」字段只能填「未知」，由收件方另外判断。
• 按白名单打包，不整目录塞。 只有清单里列出的文件会进包；凭据、.env、私钥、个人记忆、缓存一律不进。
• 返修出新版本。 旧包保留，不在原包上改。

打包脚本

附带一个只用 Python 标准库的脚本，两条命令：

python delivery.py pack --root <整理好的目录> --out <新的 .zip>
python delivery.py verify <新的 .zip>

两条都退出 0 才算能交。verify 只读压缩包，不解压、不运行，逐个核对路径、大小和摘要。

实测与边界

2026-11-02 跑了一轮冒烟测试：正常打包和校验通过；拒绝覆盖已有的包；清单里写了 .env 会被拒绝；改动包内一个文件后，校验能查出摘要不符；声明「已完成」却列了未完成项，会被拒绝。

它只证明包的结构和内容与清单一致，不证明质量、能不能运行，也不证明作者是谁。那部分要人或另一个工具去验收——这正是 跨工具交接 里「验收」栏的活。