| name | analyze |
| description | 在任务生成后对 spec.md、plan.md 和 tasks.md 执行非破坏性的跨产物一致性和质量分析。 |
| disable-model-invocation | true |
| allowed-tools | ["Bash(node */check-prerequisites.mjs*)"] |
用户输入
$ARGUMENTS
你必须在继续之前考虑用户输入(如果不为空)。
目标
在实现之前识别三个核心产物(spec.md、plan.md、tasks.md)之间的不一致、重复、歧义和未充分说明的项目。此命令必须在 /tasks 成功产生完整 tasks.md 后运行。
操作约束
严格只读:不要修改任何文件。输出结构化分析报告。提供可选的修复计划(用户必须在手动调用任何后续编辑命令之前明确批准)。
宪章权威:项目宪章(!node -e "console.log(require('fs').existsSync('.specify/memory/constitution.md') ? require('path').resolve('.specify/memory/constitution.md') : require('path').resolve('${WAVE_PLUGIN_ROOT}/memory/constitution.md'))")在此分析范围内是不可协商的。宪章冲突自动为关键,需要调整规格、计划或任务——而不是稀释、重新解释或静默忽略原则。如果原则本身需要更改,必须在 /analyze 之外的单独、明确的宪章更新中进行。
执行步骤
1. 初始化分析上下文
从仓库根目录运行 node ${WAVE_PLUGIN_ROOT}/scripts/check-prerequisites.mjs --json --require-tasks --include-tasks 一次并解析 JSON 获取 FEATURE_DIR 和 AVAILABLE_DOCS。派生绝对路径:
- SPEC = FEATURE_DIR/spec.md
- PLAN = FEATURE_DIR/plan.md
- TASKS = FEATURE_DIR/tasks.md
如果缺少任何必需文件则中止并显示错误消息(指示用户运行缺失的前置命令)。
对于参数中的单引号如 "I'm Groot",使用转义语法:例如 'I'''m Groot'(或尽可能使用双引号:"I'm Groot")。
2. 加载产物(渐进式披露)
从每个产物仅加载最少的必要上下文:
从 spec.md:
- 概述/上下文
- 功能需求
- 非功能需求
- 用户故事
- 边界情况(如存在)
从 plan.md:
从 tasks.md:
- 任务 ID
- 描述
- 阶段分组
- 并行标记 [P]
- 引用的文件路径
从宪章:
- 加载 !
node -e "console.log(require('fs').existsSync('.specify/memory/constitution.md') ? require('path').resolve('.specify/memory/constitution.md') : require('path').resolve('${WAVE_PLUGIN_ROOT}/memory/constitution.md'))" 用于原则验证
3. 构建语义模型
创建内部表示(不在输出中包含原始产物):
- 需求清单:每个功能 + 非功能需求带有稳定键(基于祈使短语派生 slug;例如,"用户可以上传文件" →
user-can-upload-file)
- 用户故事/操作清单:带验收标准的离散用户操作
- 任务覆盖映射:将每个任务映射到一个或多个需求或故事(通过关键词/显式引用模式如 ID 或关键短语推断)
- 宪章规则集:提取原则名称和必须/应该规范性陈述
4. 检测过程(令牌高效分析)
聚焦于高信号发现。限制总共 50 个发现;其余聚合在溢出摘要中。
A. 重复检测
B. 歧义检测
- 标记缺乏可衡量标准的模糊形容词(快速、可扩展、安全、直观、健壮)
- 标记未解决的占位符(TODO、TKTK、???、
<placeholder> 等)
C. 未充分说明
- 有动词但缺少对象或可衡量结果的需求
- 缺少验收标准对齐的用户故事
- 引用规格/计划中未定义的文件或组件的任务
D. 宪章对齐
- 任何与必须原则冲突的需求或计划元素
- 缺少宪章强制章节或质量门
E. 覆盖缺口
- 零关联任务的需求
- 无映射需求/故事的任务
- 未在任务中反映的非功能需求(例如性能、安全)
F. 不一致
- 术语漂移(同一概念在文件间命名不同)
- 计划中引用但规格中不存在的数据实体(或反之)
- 任务顺序矛盾(例如集成任务在基础设置任务之前没有依赖说明)
- 冲突需求(例如一个需要 Next.js 而另一个指定 Vue)
5. 严重性分配
使用此启发式方法优先级排序发现:
- 关键:违反宪章必须、缺少核心规格产物或零覆盖且阻塞基线功能的需求
- 高:重复或冲突需求、模糊的安全/性能属性、不可测试的验收标准
- 中:术语漂移、缺少非功能任务覆盖、未充分说明的边界情况
- 低:风格/措辞改进、不影响执行顺序的次要冗余
6. 生成紧凑分析报告
输出 Markdown 报告(无文件写入),结构如下:
规格分析报告
| ID | 类别 | 严重性 | 位置 | 摘要 | 建议 |
|---|
| A1 | 重复 | 高 | spec.md:L120-134 | 两个相似的需求... | 合并措辞;保留更清晰的版本 |
(每个发现一行;生成以类别首字母为前缀的稳定 ID。)
覆盖摘要表:
宪章对齐问题:(如有)
未映射任务:(如有)
指标:
- 总需求数
- 总任务数
- 覆盖率%(有 >=1 任务的需求)
- 歧义数量
- 重复数量
- 关键问题数量
7. 提供下一步操作
在报告末尾,输出简洁的下一步操作块:
- 如果存在关键问题:建议在
/implement 之前解决
- 如果只有低/中:用户可以继续,但提供改进建议
- 提供明确的命令建议:例如,"运行 /specify 进行细化"、"运行 /plan 调整架构"、"手动编辑 tasks.md 为 'performance-metrics' 添加覆盖"
8. 提供修复
询问用户:"你希望我为前 N 个问题建议具体的修复编辑吗?"(不要自动应用。)
操作原则
上下文效率
- 最少高信号令牌:聚焦于可操作的发现,而非详尽的文档
- 渐进式披露:增量加载产物;不要将所有内容转储到分析中
- 令牌高效输出:限制发现表 50 行;总结溢出
- 确定性结果:无更改重新运行应产生一致的 ID 和计数
分析准则
- 永远不要修改文件(这是只读分析)
- 永远不要臆造缺失章节(如缺失,准确报告)
- 优先处理宪章违规(这些始终关键)
- 使用示例而非详尽规则(引用具体实例,而非通用模式)
- 优雅地报告零问题(发出带覆盖统计的成功报告)
上下文
$ARGUMENTS