spec-kit-analyse

在任务列表生成后，进行只读一致性分析。

输入：可选择指定变更名称。若未指定，请根据上下文推断或询问。

此技能不会修改任何文件。

为什么需要全新的视角

编写计划的会话知道自己写下每一行的原因，因此，它自行解决的歧义，或偏离了规范的计划，在它看来仍然前后一致。 如果 Agent 可以在全新上下文中启动子 Agent（而非从当前会话分叉），请让它执行分析，并且只提供变更目录、此技能的说明和项目根目录。 不要向它解释相关产物、总结内容，也不要告诉它你预期会发现什么。 如果无法使用全新的 Agent，请自行执行分析，并在报告中说明这一点。

步骤

1. 加载产物

   加载 specs/changes/<name>/ 下的变更产物：

   • spec.md（必需）
   • plan.md（必需）
   • tasks.md（必需）

   如果缺少任何文件，请停止，并指出负责生成该文件的技能（spec-kit-specify、spec-kit-plan 或 spec-kit-tasks）。

   同时加载 FRAMEWORK.md（以及 FRAMEWORK.local.md 和它链接的能力文档），作为规范基线；还要加载此变更涉及的现行规范和决策记录。

2. 建立清单

   • 需求：每个 FR-nn（包括边界情况需求）、每个需要可构建工作的 SC-nn（不包括发布后衡量的结果指标）以及每个 US-n。
   • 任务：每项任务的 ID、阶段、引用项、[P] 标记和文件路径。
   • 规则：变更涉及的规范中所有 MUST 和 SHOULD 声明。

3. 执行一致性检查

   跨以下维度进行分析：

   维度	检查内容
   覆盖度	每项需求和用户故事都有对应任务；文档任务与其他任务同等计入
   结构	每个故事和需求都带有标识符；每项需求都有 WHEN/THEN 场景；变更涉及的每个界面都已明确边界状态，或说明为何不会出现此类状态；plan.md 包含 ## Exceptions 和 ## Record Search；tasks.md 的最后一个阶段是 Documentation 阶段
   一致性	计划中的架构符合规范目标和约束
   符合 FRAMEWORK.md	不违反依赖规则；领域模型不贫血；外部依赖都有端口；变更涉及的每项强制规则（测试、文档、现行规范）都有对应任务；只有当 ## Exceptions 记录了规则、权衡、被拒绝的替代方案和验证方式，且权衡合理时，才接受例外
   重复	是否存在重叠的需求或任务，以及是否提出了代码已经具备的测试或检查
   歧义	是否存在缺乏可衡量标准的模糊术语；两个可观察结果不同的实现是否都可能声称满足某项标准
   术语漂移	同一概念在不同产物中是否使用了不同名称
   孤立项	是否存在没有引用任何内容的任务，或 spec.md 中不存在的标识符；是否有未分配任务的需求；是否引用了不存在的标题
   顺序	测试任务是否排在其驱动的实现任务之后；任务指定的路径是否既不存在，也不会由较早的任务创建；产物中是否残留占位符（TODO、TBD、??? 或未解决的问题）
   读者	任务变更路径之外的测试，是否读取了计划要更改的标识符、消息、格式、标志或端点，而任务中没有提及该测试
   记录	需求或计划中的变更是否与现行规范或决策记录相矛盾，而计划的 ## Record Search 又未对此作出处理
   对每项都遵守以下规则：

   • 覆盖情况要依据规范中的文字核查，而不只是用户故事。 如果某项要求列出了某种能力，而计划将其拆分为清单，就从代码中枚举具体实例并进行对比。
   • 计划中提及的风险也属于覆盖核查范围： 如果某项已提及的风险没有对应任务，且该任务的检查能在风险发生时失败，那么这就是未覆盖的工作。
   • **如果没有用户记录的决定，却撤销或推翻了决策记录中的决定，**则应列为问题。

4. 核查计划对代码的陈述

   列出计划中所有依赖于现有代码范围或设计的陈述，包括某项内容存在、不存在或当前行为如何。 对照代码本身逐项核查，不要依据计划对代码的描述进行判断。 要确认某项内容不存在，除非计划说明了更窄的范围，否则应按代码中的写法搜索整个代码库。 如果代码与某项陈述矛盾，则应列为问题；如果无法核查，则记录为未核查，并说明需要什么证据才能确认。

5. 生成问题报告

   输出结构化报告：

   ## Analysis: <change-name>
   
   ### Findings
   | ID | Severity | Dimension | Description | Location | Recommendation |
   |----|----------|-----------|-------------|----------|----------------|
   
   ### Coverage Summary
   | Requirement | Task IDs | Notes |
   |-------------|----------|-------|
   
   ### Claims
   | Claim | Search or read | Result |
   |-------|----------------|--------|
   
   ### FRAMEWORK.md Violations
   <List any violations. CRITICAL severity — must be fixed before proceeding.>
   
   ### Metrics
   - Requirements: N | Tasks: N | Coverage: N% (requirements with at least one task)
   - Claims checked: N (contradicted: N, unchecked: N)
   - Total findings: N
   - Critical: N | High: N | Medium: N | Low: N
   
   ### Recommended Next Actions
   <Ordered list of what to fix, and with which skill.>
   

   每项要求和用户故事都要单独列出一行覆盖情况；即使没有发现问题，也始终显示覆盖情况表和陈述核查表。 为问题分配稳定 ID，并以其所属维度的首字母作为前缀，以确保对未变更的材料重新运行时，生成相同的 ID。 最多报告 50 个问题，按严重程度从高到低排列，并概述其余问题。

   严重程度按以下标准判定：假设按照材料所述构建变更，该问题会造成什么后果：

   • CRITICAL — 违反 FRAMEWORK.md（其架构、安全或数据规则，或工作执行方式，例如先测试再实现）；缺少核心产物；P1 要求没有对应任务；变更会导致仍有效的规范或决策记录失实，且 ## Record Search 中没有说明如何处置；或未经用户决定就推翻已记录的决定。
   • HIGH — 要求被遗漏或与之矛盾；关于代码的陈述不成立；要求相互冲突；安全或性能属性含糊不清；验收标准无法测试；记录的例外缺少四列中的任意一列。
   • MEDIUM — 实施者必须自行猜测或返工，但最终结果仍可能满足所有要求：术语不一致、边缘情况规定不足、缺少非功能性任务。
   • LOW — 措辞、重复、命名或可追溯性问题，不影响变更交付的任何内容。

输出

分析结束后：

• 如果存在 CRITICAL 问题：「修复 FRAMEWORK.md 违规项和关键问题后再继续。在这些问题解决之前，请勿使用 spec-kit-implement 技能。」
• 如果只有 HIGH、MEDIUM 或 LOW 问题：用户可以继续，但建议优先修复 HIGH 问题，并为每项问题注明对应技能（规范问题使用 spec-kit-specify 或 spec-kit-clarify，计划问题使用 spec-kit-plan，任务清单问题使用 spec-kit-tasks）。
• 如果没有 CRITICAL 问题：「使用 spec-kit-implement 技能执行已验证的任务清单。」
• 为最重要的问题提供具体的修复建议；未经用户批准，不要应用任何修改。

防护原则

• 只读。绝不修改任何文件。
• 绝不臆造缺失的章节：应报告其缺失。
• 违反 FRAMEWORK.md 的问题一律为 CRITICAL，绝不降低严重程度或忽略。若某项原则本身需要变更，应在本次分析之外，通过 FRAMEWORK.local.md 或已安装的标准明确进行变更。
• 确保结果具有确定性：对相同材料重新运行时，生成相同的问题。
• 绝不将规划者的推理传递给新的评估者。