description: 在生成 tasks.md 之后，对 spec.md、plan.md、tasks.md 做一次非破坏性的跨文件一致性与质量分析。
用户输入
$ARGUMENTS
在继续之前，你必须先考虑用户输入（如果不为空）。
目标
在开始实现之前，识别三份核心产物（spec.md、plan.md、tasks.md）之间的不一致、重复、歧义和说明不足之处。本命令必须在 /speckit.tasks 成功生成完整的 tasks.md 之后才运行。
运行约束
严格只读：不要修改任何文件。输出结构化的分析报告。可以提供可选的修复方案（用户必须明确同意后，才可以人工触发后续的编辑命令）。
宪法优先级：在本分析范围内，项目宪法（.specify/memory/constitution.md）不可协商。任何与宪法冲突的问题都自动视为 CRITICAL，并要求调整 spec/plan/tasks，而不是淡化、重新解释或悄悄忽略原则。如果确实需要修改原则本身，必须在 /speckit.analyze 之外，通过单独、明确的宪法更新来完成。
执行步骤
1. 初始化分析上下文
在仓库根目录只运行一次 .specify/scripts/bash/check-prerequisites.sh --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]
- 引用到的文件路径
来自宪法：
- 加载
.specify/memory/constitution.md用于原则校验
3. 构建语义模型
创建内部表示（输出中不要包含原始产物全文）：
-
需求清单：每条功能/非功能需求都要有稳定的 key（根据祈使句短语生成 slug；例如 “用户可以上传文件” →
user-can-upload-file） - 用户故事/动作清单：离散的用户动作及其验收标准
- 任务覆盖映射：将每个任务映射到一个或多个需求/故事（通过关键字推断或显式引用模式，比如 ID、关键短语）
- 宪法规则集：提取原则名称以及 MUST/SHOULD 等规范性语句
4. 检测遍历（Token 高效分析）
聚焦高信号问题。总计最多输出 50 条发现；其余聚合到溢出摘要中。
A. 重复检测
- 识别近似重复的需求
- 标记表达质量较低的需求，建议合并收敛表述
B. 歧义检测
- 标记缺少可度量标准的模糊形容词（fast、scalable、secure、intuitive、robust 等）
- 标记未解决的占位符（TODO、TKTK、???、
<placeholder>等）
C. 说明不足
- 有动词但缺少对象或可度量结果的需求
- 用户故事缺少与验收标准对齐的说明
- 任务引用了 spec/plan 中未定义的文件或组件
D. 宪法对齐
- 任意与宪法 MUST 原则冲突的需求或计划要素
- 缺失宪法要求的必填章节或质量门禁
E. 覆盖缺口
- 没有关联任务的需求
- 未映射到任何需求/故事的任务
- 未在任务中体现的非功能需求（例如性能、安全）
F. 不一致
- 术语漂移（同一概念在不同文件中用不同名称）
- plan 引用的数据实体在 spec 中缺失（或反之）
- 任务顺序自相矛盾（例如未注明依赖却在基础初始化之前安排集成任务）
- 需求相互冲突（例如一处要求 Next.js，另一处指定 Vue）
5. 严重级别判定
使用以下启发式规则为发现排序：
- CRITICAL: 违反宪法 MUST、缺失核心产物，或关键需求零覆盖导致基线功能无法实现
- HIGH: 重复或冲突的需求、含糊的安全/性能属性、不可测试的验收标准
- MEDIUM: 术语漂移、缺少非功能需求的任务覆盖、边界情况说明不足
- LOW: 风格/措辞改进、不影响执行顺序的轻微冗余
6. 产出精简分析报告
按以下结构输出 Markdown 报告（不写文件）：
规格说明分析报告
| ID | 类别 | 严重级别 | 位置 | 摘要 | 建议 |
|---|---|---|---|---|---|
| A1 | 重复 | HIGH | spec.md:L120-134 | 两条相似需求…… | 合并表述；保留更清晰的版本 |
（每条发现一行；生成稳定 ID，并以类别首字母作为前缀。）
覆盖摘要表：
| 需求 Key | 是否有任务 | 任务 ID | 备注 |
|---|
宪法对齐问题：（如有）
未映射任务：（如有）
指标：
- 需求总数
- 任务总数
- 覆盖率（至少关联 1 个任务的需求占比）
- 歧义数量
- 重复数量
- 严重问题数量
7. 给出下一步动作
在报告末尾输出精炼的“下一步动作”区块：
- 若存在 CRITICAL：建议在进入
/speckit.implement之前先解决 - 若只有 LOW/MEDIUM：可继续推进，但应给出改进建议
- 给出明确命令建议：例如“用更精炼描述重新运行 /speckit.specify”“运行 /speckit.plan 调整架构”“手动编辑 tasks.md 为 ‘performance-metrics’ 补齐覆盖”
8. 提供修复建议
询问用户：“你希望我为前 N 个问题给出具体的修复编辑建议吗？”（不要自动应用。）
运行原则
上下文效率
- 最小高信号 token：聚焦可执行发现，不做穷举式文档复述
- 渐进式披露：逐步加载产物，不把全文倾倒进分析
- token 高效输出：发现表最多 50 行，其余做溢出摘要
- 确定性结果：在无变更前提下重复运行应得到一致的 ID 与统计
分析准则
- 禁止修改文件（严格只读分析）
- 禁止臆造缺失章节（缺失就如实报告）
- 优先处理宪法违规则（一律 CRITICAL）
- 用例子胜过穷举规则（引用具体实例而不是泛泛而谈）
- 零问题也要输出报告（给出覆盖统计并明确通过）
上下文
$ARGUMENTS