关于 spec-driven-development
帮助开发者在实现功能时同步维护规格说明的技能，将 `.claude/specs/` 作为架构决策和 API 契约的依据，并提供反复核对代码与规格的流程。
主要功能
- 01以规格为先的实现流程
- 02缺少规格时的处理指引
- 03跟踪实现 TODO
- 04实现后的对齐检查
- 05结构化检查偏差与缺口
适用场景
- 01着手实现复杂功能
- 02代码变更后同步更新规格
- 03依据 API 契约核验代码
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/spec-driven-development确认已加载。
详细介绍
规范驱动开发
规范存放在 .claude/specs/ 中。它们是架构决策、API 契约和实现范围的事实依据。实现与规范必须保持同步——两者都不能单方面主导。
核心循环
Read spec → Implement → Verify alignment → Update spec or code → Repeat
开始工作前
- 查找规范。 在
.claude/specs/中搜索与该功能匹配的文件：
ls .claude/specs/
-
通读规范。 编写代码前，先了解范围、决策、API 契约和未决问题。
-
如果没有规范， 且任务并非简单任务（例如新增模块、新增 API、架构变更），请询问用户是否要先创建规范。
实现期间
- 参考规范中的决策——不要重新决定规范已经确定的事项。
- 当实现偏离规范时（找到更好的方案、用户要求变更、发现约束），请在同一会话中立即更新规范。不要让规范和代码不同步。
- 完成 TODO 项后勾选复选框（
- [ ]→- [x]）。 - 对于有意跳过或替换的项目， 请划掉或添加注释，并简要说明原因：
- [x] ~~OpenRouter proxy~~ → Direct execution: nodes call OpenRouter directly
完成工作后
执行规范验证：
- 重新阅读规范， 并对照实现检查。
- 检查各个部分：
- 规范中的 API 端点是否与控制器一致？
- 规范中的配置项和环境变量是否与配置类一致？
- 规范中的模块结构是否与实际文件树一致？
- 规范中的类型定义是否与
@n8n/api-types一致？ - 所有 TODO 项的勾选状态是否正确？
- 更新规范， 修正发现的任何偏差。常见偏差包括：
- 新增了文件，但结构部分未列出
- 实现过程中更改了 API 响应结构
- 调整了配置默认值
- 细化了架构决策
- 向用户指出未解决的问题——即规范承诺但实现尚未交付的事项（MVP 阶段可以接受，但应予以说明）。
规范文件约定
- 每个功能在
.claude/specs/中对应一个或多个 Markdown 文件。 - 保持规范简洁。使用表格呈现映射关系，使用代码块展示结构。
- 使用
## Implementation TODO和复选框跟踪进度。 - 在有帮助时拆分为多个文件（例如，分别拆分后端和前端），但不要强制采用固定的命名规则。
用户要求“自我审查”或“根据规范验证”时
- 阅读所有相关规范。
- 阅读所有实现文件。
- 生成结构化对比：
- 一致：规范与代码匹配的项目
- 偏差：规范与代码不一致的项目（立即修复）
- 缺漏：尚未实现的规范项目（注明为后续工作）
- 修正偏差、更新规范，并向用户报告缺漏。
评论
支持 Markdown