用途：SpecOps 主张规格先于代码，规格声明软件应达到的完整状态，实现只是让代码与规格保持一致。核心循环为：提出规格变更、评审接受、实现、对照运行中的软件验证。没有对应规格的代码属于未指定行为，没有对应代码的规格则是已知缺口。
主要能力：给出规格的写法与粒度建议，规格应声明必须为真的事实而非实现方式，覆盖显示规则、数据需求、动作、导航、业务规则与 API 契约，不覆盖视觉设计、组件拆分、测试用例、变量名与文件路径。提供规格目录结构（architecture.md、data-model.md、api/、screens/、behaviors/）及屏幕、行为、API 三类规格模板。计划协议用 plans/ 目录记录进行中的工作，计划文件含 status、depends、specs、upstream-specs、issues、pr 等 frontmatter，正文模板含 Scope、Implements、Approach、Validation、Risks、Notes、Follow-ups。提供零依赖 Node.js 脚本 scripts/plans-dag 与 scripts/plans-next 查询计划 DAG 与就绪顺序。还提供规格漂移审计智能体与 /audit-spec-drift 命令的配置方式。
使用方式：在新项目创建 specs/ 目录并编写 README、architecture 等规格，在 CLAUDE.md 中引用；实现前先读规格，规格含糊则修改规格而非猜测；新功能先写或更新规格，评审通过后再实现并验证；修 bug 时先判断行为是否已被规格覆盖。计划脚本从技能安装目录对项目的 plans/ 目录调用，如 <specops-skill-path>/scripts/plans-dag plans/。
适用场景：AI 辅助开发、多智能体协作同一系统、需要以规格作为验收标准的代码审查。
限制：资料未提供具体收费、价格、支持平台与效果数据；审计器只检查计划文件的 specs 字段与 specs/ 树，不检查 upstream-specs。