关于 sync-spec
sync-spec 是用于校准单个功能规格的工作流技能，核对需求、设计、任务、测试和索引是否与现状一致。它保留需求历史，并要求状态变更有证据支持。
主要功能
- 01比对需求、设计与任务
- 02编辑前后运行追踪检查
- 03保留不可变的需求 ID
- 04标出需决策的孤立引用
- 05仅凭证据更新状态
- 06同步规格索引
适用场景
- 01代码变更后校准功能规格
- 02查找缺少任务或设计覆盖的需求
- 03检查测试是否支持完成状态
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/sync-spec确认已加载。
详细介绍
同步规格说明
让一个功能的规格三件套（docs/specs/<date>-<feature>/{requirements,design,tasks}.md）与实际情况保持一致——包括代码、测试和任务。变更后未重新同步的规格说明会变成虚构内容，而虚构内容比没有规格说明更糟。
一次处理一个功能。先确定规格目录（由用户提供、从当前分支获取，或查看 docs/specs/INDEX.md）。
铁律
- 绝不重新编号需求 ID。 ID 一经批准便不可更改；所有下游内容都会引用它们。
- 绝不删除需求。 将其标记为退役：
~~**CODE-N.M**~~ <reason>——删除线标记的 ID 不再计为已定义，但历史记录仍清晰可辨。 - 新需求使用其所属用户故事下一个可用的编号；新任务必须与现有任务格式完全一致。
步骤
a. 基线。 运行追踪检查（必需子技能：使用 trace）并记录发现项——这就是“变更前”的情况。
b. 需求 ↔ 任务。 对比 requirements.md 和 tasks.md：
- 有效需求没有被任何任务引用 → 按文件其余部分使用的格式追加一项覆盖该需求的任务，并以
_Requirements: CODE-N.M_页脚结尾。 - 已能验证完成（已实现且存在验证证据），但任务框尚未勾选 → 勾选该框。
c. 需求 ↔ 设计。 将需求 ID 与 design.md 中的 Satisfies: 行进行对比。任何未出现在 Satisfies: 行中的有效需求都要标记给用户——要么为设计补充章节（扩展设计），要么该需求只是愿景（考虑将其退役）。不要悄悄臆造设计内容。
d. 孤立项。 列出每个任务页脚和测试注释中引用已删除线标记或不存在 ID 的条目。将清单及每项的建议处理方式提交给用户（改为引用有效 ID、退役测试，或恢复需求）——孤立项需要作出决定，不是单纯的清理工作。
e. 状态转换——只依据证据。
| 转换 | 所需证据 |
|---|---|
| Draft → Approved | 用户明确批准了规格说明——绝不能推断 |
| Approved → Implemented | 所有任务框均已勾选，且追踪检查显示每项有效需求都有测试覆盖 |
| Implemented → Shipped | 功能已随某个版本发布（通常由 release 步骤调用） |
应用所有有证据支持的状态转换：更新 requirements.md 中的 Status: 行和 docs/specs/INDEX.md 中该功能的行。如果证据不完整，应准确说明缺少什么，而不是进行状态转换。
f. 变更后检查。 重新运行追踪检查，并将两组发现并排输出——说明已解决的错误和警告、仍未解决的内容，以及为达到当前状态所做的更改。确认 docs/specs/INDEX.md 反映每份规格说明当前的 Status: 行，并将其暂存到同一次提交中。
完成条件： 变更后的报告在错误方面不比变更前更差；每个标记项都已修改，或明确列为待用户决定；并且 INDEX.md 与每份规格说明的 Status: 行一致。