analyze

用户输入

$ARGUMENTS

继续之前，必须考虑用户输入（如非空）。

目标

在实施之前，找出三个核心文档（spec.md、plan.md、tasks.md）中的不一致、重复、歧义和未充分说明之处。此技能必须在 bb-tasks 技能成功生成完整的 tasks.md 后运行。

操作限制

严格只读：请勿修改任何文件。输出结构化分析报告。可提供可选的修正计划（用户必须明确批准，之后才能手动执行任何后续编辑命令）。

宪法权威性：在本分析范围内，项目宪法（constitution.md，位于项目根目录或 docs/ 目录）不可妥协。与宪法相冲突的内容一律视为严重问题，必须调整规范、计划或任务，不得削弱、重新解释或默默忽略相关原则。如果原则本身需要更改，必须在此技能之外单独、明确地更新宪法。

执行步骤

1. 初始化分析上下文

定位当前功能目录，并确认所需文档存在。推导绝对路径：

• 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]
• 引用的文件路径

从宪法加载：

• 加载项目根目录或 docs/ 目录中的 constitution.md，用于验证原则

3. 构建语义模型

创建内部表示（不要在输出中包含原始文档）：

• 需求清单：为每项功能需求和非功能需求分配稳定键（根据祈使短语生成 slug；例如，“用户可以上传文件” → user-can-upload-file）
• 用户故事/操作清单：列出离散的用户操作及其验收标准
• 任务覆盖映射：将每项任务映射到一项或多项需求或用户故事（通过关键词推断或显式引用模式进行映射，例如 ID 或关键词短语）
• 宪法规则集：提取原则名称以及 MUST/SHOULD 规范性陈述

4. 检测轮次（高信号、节省 Token 的分析）

重点关注高信号问题。问题总数限制为 50 项；其余问题汇总到溢出摘要中。

A. 重复检测

• 找出近似重复的需求
• 标记措辞质量较低、需要整合的内容

B. 歧义检测

• 标记缺乏可衡量标准的模糊形容词（快速、可扩展、安全、直观、健壮）
• 标记尚未解决的占位符（TODO、TKTK、???、<placeholder> 等）

C. 说明不足

• 标记有动词但缺少对象或可衡量结果的需求
• 标记缺少验收标准对应关系的用户故事
• 标记引用了规范/计划中未定义文件或组件的任务

D. 宪法一致性

• 标记任何与 MUST 原则冲突的需求或计划内容
• 标记缺失的强制章节或质量门禁

E. 覆盖缺口

• 标记没有关联任务的需求
• 标记没有映射到需求/用户故事的任务
• 标记任务中未体现的非功能需求（例如性能、安全）

F. 不一致

• 术语漂移（同一概念在不同文件中的名称不一致）
• 计划中引用的数据实体未出现在规范中（或反之）
• 任务顺序矛盾（例如，未注明依赖关系，却将集成任务排在基础设置任务之前）
• 要求冲突（例如，一个要求使用 Next.js，另一个则指定 Vue）

5. 严重程度分配

使用以下启发式规则确定问题优先级：

• CRITICAL：违反宪章中的 MUST 要求、缺少核心规范文档，或零覆盖且会阻碍基线功能的要求
• HIGH：重复或冲突的要求、含糊的安全性／性能属性、无法测试的验收标准
• MEDIUM：术语漂移、缺少非功能性任务覆盖、边缘情况说明不充分
• LOW：风格／措辞改进、不影响执行顺序的轻微冗余

6. 生成精简的分析报告

输出一份 Markdown 报告（不写入文件），结构如下：

规范分析报告

ID	类别	严重程度	位置	摘要	建议
A1	重复	HIGH	spec.md:L120-134	两项相似要求……	合并措辞；保留更清晰的版本

（每项发现占一行；生成以类别首字母为前缀的稳定 ID。）

覆盖率汇总表：

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

宪章一致性问题：（如有）

未映射的任务：（如有）

指标：

• 需求总数
• 任务总数
• 覆盖率（至少有一项任务的需求所占比例）
• 歧义数量
• 重复数量
• 严重问题数量

7. 提供后续行动

在报告末尾输出简洁的后续行动部分：

• 如果存在 CRITICAL 问题：建议先解决问题，再使用 bb-implement 技能
• 如果只有 LOW／MEDIUM 问题：用户可以继续，但请提供改进建议
• 提供明确建议，例如：“使用细化流程运行 bb-specify 技能”、“运行 bb-plan 技能以调整架构”、“手动编辑 tasks.md，为‘performance-metrics’添加覆盖”

8. 提供修复建议

询问用户：“您希望我针对前 N 个问题提出具体的修复编辑建议吗？”（不要自动应用这些建议。）

操作原则

高效利用上下文

• 尽量使用精简且高价值的内容：聚焦可执行的发现，而非详尽文档
• 渐进式呈现：逐步加载材料；不要在分析中倾倒所有内容
• 输出精简：发现表最多列出 50 行；超出部分汇总
• 结果确定：未作任何更改时，重复运行应生成一致的 ID 和计数

分析指南

• 绝不修改文件（这是只读分析）
• 绝不臆造缺失章节（若章节缺失，应如实报告）
• 优先处理违反宪章的问题（此类问题始终为 CRITICAL）
• 使用示例而非穷举规则（引用具体实例，而非泛泛而谈）
• 妥善报告零问题的情况（输出包含覆盖率统计的成功报告）

上下文

{ARGS}