用途：以规格（spec）作为“要构建什么、如何判定完成”的共享事实来源，指导智能体按阶段推进开发，避免在需求含糊时静默补全。
主要能力：按问题规模分级——Trivial 跳过正式流程；Small 为“起草规格→实现”；Medium 为“起草规格→分析→计划→实现→评审”；Large 先做研究再走完整流程。支持需求优先与设计优先两种写法，需求建议用 REQ-XXX 编号并可测试；非显而易见的缺陷修复采用 Current/Expected/Unchanged 结构。Medium 及以上包含跨需求冲突、歧义与缺口分析，以及可验证任务拆解；Large 或架构不明确时要求架构包与 tracer bullet 垂直切片。评审阶段实行生成者≠评估者，做反驳式检查，覆盖规格符合性、回归防护、安全敏感路径、测试与文档漂移。
使用方式：按 SIZE → SPECIFY → ANALYZE（Medium+）→ PLAN（Medium+）→ CLEAR → IMPLEMENT → REVIEW 推进，未达到阶段产物质量前不进入下一阶段。写规格前先列出假设并请用户纠正，把模糊目标改写为可度量成功标准。规格与计划需保持同步，重大需求或设计变更后重跑计划。产物存放位置需先确认：用户显式路径、项目既有约定，或默认 docs/specs 与 docs/plans（Cursor 环境为 .cursor/...）。斜杠命令为可选薄封装。完成前必须运行项目验证命令，未配置验证不得声称完成。
适用场景：中大型功能开发、架构或集成边界不清的改动、高风险缺陷修复、棕地代码的既有行为文档化与改造。
限制：资料未提供具体安装命令、收费与价格、支持平台及效果数据；多会话交接、评审细则等需按需读取对应 references 文件。