关于 close-spec
close-spec 是将已交付功能规格从构建计划转为决策记录的技能。它指导团队保留设计理由、代码指针和视觉参考，同时移除过时的实现步骤。
主要功能
- 01确认功能已交付
- 02对照计划与实际实现
- 03将规格改写为决策记录
- 04保留不变量与视觉参考
- 05依据代码和测试审查陈述
适用场景
- 01归档已完成的功能规格
- 02记录实现选择的原因
- 03为后续维护保留视觉标准
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/close-spec确认已加载。
详细介绍
关闭规范
规范在构建期间是构建计划，交付之后则是决策依据记录。关闭规范，就是将它从前者转变为后者。计划由一系列切片和预测构成；记录则承载代码无法表达的意义层——它为何存在、绝不能破坏什么，以及哪些尝试失败了。代码是关于如何实现的唯一事实来源；已关闭的规范则是关于为何如此的事实来源，也是通往代码的地图。
不要总结实现。任何人都可以阅读代码。如果某段内容只是重述某个函数的作用，就删掉它，改为指向该函数。
工作流
-
确认已交付。 功能已合并或已在代码树中正常运行，且测试和截图检查均已通过。如果还有未验证的切片，就说明还没完成——先完成，或先进行审查。
-
对照计划与实际情况。 阅读规范的 README 和各个切片，然后阅读实际交付的内容。记录构建与计划不一致的所有地方：删掉的切片、重命名的接口、结果不同的机制、被证伪的假设。偏差是最有价值的记录内容——它们正是未来读者原本需要重新推导的东西。
-
移动文件。
specs/<feature>/→specs/done/<feature>/（使用git mv）。 单文件规范：specs/<feature>.md→specs/done/<feature>.md。 -
将 README 改写为记录，而不是计划。保留：
- 概述与目的——交付了什么，以及它解决了什么问题；使用现在时（“经济每月结算”），而不是将来时（“将新增”）。
- 原因——为什么采用这种做法，而不是那些显而易见的替代方案；哪些约束和权衡决定了最终方案。这部分信息无法从代码中得知。
- 原则与不变量——实现必须始终遵守的规则。哪些内容必须保持成立；违反后会导致哪些问题在不知不觉中发生。
- 代码指引——便于搜索的模块、类型和函数名称，文件路径，以及锁定这些行为的测试。机制细节请引导读者查看代码；列出入口点，让他们一次搜索就能找到。
- 行不通的方案——尝试过但最终否决的做法，以及否决原因，以免后来的人重蹈覆辙。
- 视觉出处——作为比对基准、对比目标或外观灵感而上传的图片。这些图片本身就是需求：它们说明“完成”应当是什么样子，以及为何最终结果会呈现现在的形态。将图片保留在代码树中，并在 README 中引用，注明每张图片的来源（真实截图、情绪板或参考游戏），以及它所影响的设计内容。没有这些图片，读者只能看到结果，却不知道评判它的标准。
删除：逐切片构建顺序、“接下来我们将……”之类的内容、搭建说明、逐切片验证清单，以及任何重新叙述代码的文字。
-
整合切片，保留图像。 切片曾是构建的阶梯；交付后，它们就成了历史沉淀。将所有持久有效的内容（偏差、行不通的方案、切片确立的不变量）整合到 README 中，然后删除
slices/。但请保留基准图、对比图和灵感图——也就是衡量这项工作是否达标的参考图片；同时保留仍有助于读者评估结果的visualizations/或assets/。这些是出处记录，不是搭建材料：可以丢弃构建说明，但不要丢弃定义构建目标的图片。将每张图片都纳入 README 的视觉出处说明，确保关闭规范后仍能追溯需求的来源。 -
修正引用。 更新指向旧路径的链接。如果
[[memory]]笔记或其他技能中引用了该规范，也要更新为新路径。 -
公正地审查每项陈述。 派出未参与编写规范且不了解对话内容的子 Agent，让他们逐条对照实际代码和测试，检查最终文档。分散审查任务——每个部分安排一个 Agent，或将声明列表拆分给多个 Agent——避免任何单一审查因偏见而放行。每个 Agent 都要逐条给出结论：
- 指向项（具名的模块／类型／函数／文件／测试）——它是否存在，且是否表达了规范所述内容？标出过时的名称和错误路径。
- 不变量／原则——代码是否真正强制执行了它，还是只做了断言？标出与代码矛盾或缺乏代码支持的声明。
- 概述／原因——是否与已交付的内容一致，使用现在时，且不遗留“将会”“下一步”或切片编号？
- 视觉出处——所引用的基准图／灵感图是否仍存在于代码库中，README 是否说明了每张图的来源和用途？标出没有说明所依据标准的成果。
将缺乏依据、相互矛盾或过时的陈述视为缺陷：修正规范（或指向项），并重新审查修改后的声明。只要还有任何陈述未经验证，规范就不能定稿。
气味测试
- 读者能否通过阅读代码还原这段话？→ 删除它，只保留指向项。
- 是否写了“将会”“下一步”或切片编号？→ 这仍是计划。
- 实际决策是否偏离计划，却未记录？→ 这才是值得保留的内容；将其补充进去。
- 是否有用作对照的基准图或灵感图？→ 保留它，并说明它的用途；没有标准，成果就毫无意义。
完成标准
规范存放在 specs/done/ 下，讲清为何如此及必须满足什么，而非如何实现；指出实现它的代码；保留工作所依据的基准图和灵感图；且每项陈述都经受住了针对代码的公正审查。即使不看代码，新读者也能理解其意图、不变量和视觉标准——了解工作为何完成以及决策如何作出；至于实现机制，则可通过规范中的指向项进一步了解。