用途：让实现与规格保持同步。规格文件存放于 .claude/specs/，是架构决策、API 契约和实现范围的唯一事实来源，代码与规格互不单方面主导，而是持续对齐。适用时机包括：处理已有规格的功能、用户说出 /spec、或开始新任务时。
核心循环：阅读规格 → 实现 → 校验一致性 → 更新规格或代码 → 重复。
开始前：先用 ls .claude/specs/ 查找与功能匹配的规格文件，完整阅读，理解范围、决策、API 契约和待定问题。若没有规格且任务不简单（新模块、新 API、架构改动），先询问用户是否创建。
实现中：引用规格已定的决策，不重复决策。一旦偏离规格（发现更好方案、用户要求变更、遇到新约束），须在同一会话内立即更新规格，避免不同步。完成 TODO 时把 - [ ] 改为 - [x]；有意跳过或替换的项用删除线或注明简短原因，例如：- [x] OpenRouter proxy → Direct execution: nodes call OpenRouter directly。
完成后做规格校验：重读规格与实现，逐节核对 API 端点是否匹配控制器、配置/环境变量是否匹配配置类、模块结构是否匹配文件树、类型定义是否匹配 @n8n/api-types、TODO 勾选是否正确。发现漂移立即更新规格，常见漂移包括：新增文件未列入结构章节、实现中 API 响应结构变化、配置默认值调整、架构决策细化。同时向用户标记规格承诺但尚未实现的缺口（MVP 可接受，但应注明）。
规格文件约定：每个功能一个或多个 markdown 文件，保持简洁，映射用表格、结构用代码块；用 ## Implementation TODO 加复选框跟踪进度；可按需拆分（如前后端分开），不强制固定命名。
当用户要求“自审”或“对照规格验证”时：阅读所有相关规格与实现文件，输出结构化对比——一致（规格与代码相符）、漂移（立即修复）、缺口（规格项尚未实现，记为后续工作）；修复漂移、更新规格并向用户报告缺口。限制：仅面向使用 .claude/specs/ 的规范驱动工作流，其他事实暂未提供。