deliverable-versioning 交付版本纪律
Every team eventually has a folder full of report_FINAL.xlsx, report_FINAL_v2.xlsx, and report_FINAL_really.xlsx — and nobody trusts any of them. This skill is the cure.
每个团队最终都会有一个装满 report_FINAL.xlsx、report_FINAL_v2.xlsx、report_FINAL_really.xlsx 的文件夹——然后没人相信其中任何一个。这个 skill 就是解药。
Why / 为什么
The chaos has one root cause: overwriting and ambiguous naming. A file that was already sent is edited in place; the word "final" is used as a name; and six months later nobody can say which file a decision was based on. The fix is mechanical, not motivational.
混乱只有一个根源：覆盖 + 命名含糊。已发出的文件被原地修改；"final" 被拿来当文件名用；六个月后没人说得清哪个决策是基于哪个文件。解法是机械的，不靠自觉。
The rules / 规则
- 已发出 = 不可变。 A file that left your hands never gets edited — new content becomes a new file, and the old one stays exactly as sent.
- 用日期和内容命名，永远不用 final。 The word final always gets violated; a date never does.
proposal_2026-09-14.xlsx beats proposal_final_v3.xlsx forever.
- 一个权威交付目录。 One directory per project is the source of truth for "what did we actually send"; drafts live elsewhere. 交付目录 = 权威。
- 台账把一切串起来。 date → filename → count → recipient. "我们发过什么" 是一次查询，不是一场考古。
- 新版本先查有没有。 Before rebuilding a deliverable, check whether it already exists in the delivery directory — rebuilding creates the second source of truth that rots the first.
- 替代要留痕。 A superseded file stays in place but gets marked in the ledger; references in docs get updated to point at the current one.
The test / 一分钟自测
Can you answer, from the delivery directory and ledger alone, without opening chat history: what did we send, to whom, when, and how many rows? If any answer requires scrolling chat — the discipline is missing.
只看交付目录和台账，不翻聊天记录，能不能答出：发过什么、发给谁、什么时候、多少行？任何一问需要翻聊天——纪律就还缺着。
Install / 安装
git clone https://github.com/ChenneyZhuang/deliverable-versioning ~/.claude/skills/deliverable-versioning
One SKILL.md, zero dependencies. MIT. v0.1.0.
单个 SKILL.md，零依赖。MIT 许可，v0.1.0。
