analyze

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。）

覆盖摘要表：

需求键	有任务?	任务 ID	备注

宪章对齐问题：（如有）

未映射任务：（如有）

指标：

• 总需求数
• 总任务数
• 覆盖率%（有 >=1 任务的需求）
• 歧义数量
• 重复数量
• 关键问题数量

7. 提供下一步操作

在报告末尾，输出简洁的下一步操作块：

• 如果存在关键问题：建议在 /implement 之前解决
• 如果只有低/中：用户可以继续，但提供改进建议
• 提供明确的命令建议：例如，"运行 /specify 进行细化"、"运行 /plan 调整架构"、"手动编辑 tasks.md 为 'performance-metrics' 添加覆盖"

8. 提供修复

询问用户："你希望我为前 N 个问题建议具体的修复编辑吗？"（不要自动应用。）

操作原则

上下文效率

• 最少高信号令牌：聚焦于可操作的发现，而非详尽的文档
• 渐进式披露：增量加载产物；不要将所有内容转储到分析中
• 令牌高效输出：限制发现表 50 行；总结溢出
• 确定性结果：无更改重新运行应产生一致的 ID 和计数

分析准则

• 永远不要修改文件（这是只读分析）
• 永远不要臆造缺失章节（如缺失，准确报告）
• 优先处理宪章违规（这些始终关键）
• 使用示例而非详尽规则（引用具体实例，而非通用模式）
• 优雅地报告零问题（发出带覆盖统计的成功报告）

上下文

$ARGUMENTS