deliverable-versioning
交付物版本规范：离开你手中的文件不可更改，用日期代替“final”一词，每个项目设一个权威交付目录，并建立将文件名、日期、数量与收件人对应起来的台账——这样就不会有人再问哪个 FINAL_v3 才是真正的版本。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:ChenneyZhuang/deliverable-versioning#d6cf4c5879622453aac3fcb79017b95cf545a52bDeliverable Versioning 以 deliverable-versioning 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →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 就是解药。
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" 被拿来当文件名用；六个月后没人说得清哪个决策是基于哪个文件。解法是机械的，不靠自觉。
proposal_2026-09-14.xlsx beats proposal_final_v3.xlsx forever.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.
只看交付目录和台账，不翻聊天记录，能不能答出：发过什么、发给谁、什么时候、多少行？任何一问需要翻聊天——纪律就还缺着。
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。