在 spec-kit 项目生成 tasks.md 后，对…

当 spec-kit 项目已有完整的 spec.md、plan.md、tasks.md，需要在动手实现前找出跨文档的不一致、重复、歧义与覆盖缺口时使用。

适用场景

解决思路

1. 执行前先检查扩展 hook：查看项目根目录是否存在 `.specify/extensions.yml`；存在则读取并查找 `hooks.before_analyze` 下的条目。
2. 若该 YAML 无法解析或无效，不要静默跳过：明确告知用户文件读取失败（附上解析器错误），说明未检查任何 hook（包括其中注册的强制 hook，`optional: false`），然后照常继续。
3. 过滤掉 `enabled` 显式为 `false` 的 hook；没有 `enabled` 字段的默认视为启用。
4. 对剩余 hook 不要自行解释或求值 `condition`：无 `condition` 字段或为 null/空 → 视为可执行；定义了非空 `condition` → 跳过，交给 HookExecutor 实现求值。
5. 由 hook 命令名构造调用时，把点号 `.` 替换为连字符 `-`（如 `speckit.git.commit` → `/speckit-git-commit`）。
6. 对每个可执行 hook 按 `optional` 标志输出块：可选 hook 输出 “Optional Pre-Hook” 块（extension、command、description、prompt、执行提示）；强制 hook 输出 “Automatic Pre-Hook” 块，并必须真正调用该 hook、等待其结束再继续；调用方式按本 agent/session 运行命令的方式（如 skills 模式用 `/skill:speckit-...` 或 `$speckit-...`），只输出块不算执行。
7. 若没有注册 hook 或 `.specify/extensions.yml` 不存在，静默跳过。
8. 确认运行时机：只在 `/speckit-tasks` 已成功产出完整 `tasks.md` 之后运行本分析。
9. 全程严格只读：不修改任何文件，只输出结构化分析报告；修复方案仅在用户明确批准后才由用户手动执行后续编辑命令。
10. 把项目宪法 `.specify/memory/constitution.md` 视为不可协商：宪法冲突自动判为 CRITICAL，须调整 spec/plan/tasks，而不是稀释、曲解或静默忽略原则；若原则本身要改，必须在 `/speckit-analyze` 之外单独显式更新宪法。
11. 初始化分析上下文：在仓库根目录运行一次 `.specify/scripts/bash/check-prerequisites.sh --json --require-spec --require-tasks --include-tasks`，解析 JSON 得到 FEATURE_DIR 与 AVAILABLE_DOCS，推导绝对路径 SPEC=FEATURE_DIR/spec.md、PLAN=FEATURE_DIR/plan.md、TASKS=FEATURE_DIR/tasks.md；任一必需文件缺失就报错中止，并提示用户运行相应的前置命令。
12. 参数含单引号时用转义语法，如 `'I'\''m Groot'`；能双引号就直接双引号。
13. 渐进式加载工件，只取最小必要上下文：spec.md 取 Overview/Context、Functional Requirements、Success Criteria（可度量结果，如性能、安全、可用性、用户成功、业务影响）、User Stories、Edge Cases（如有）。
14. plan.md 取 Architecture/stack 选择、Data Model 引用、Phases、Technical constraints。
15. tasks.md 取 Task IDs、描述、Phase 分组、并行标记 [P]、引用的文件路径。
16. 加载 `.specify/memory/constitution.md` 用于原则校验。
17. 构建语义模型（仅内部表示，不把原始工件放进输出）：为每个 FR-### 与 SC-### 记录稳定键，优先用显式 FR-/SC- 标识符，也可另派生命令式短语 slug（如 "User can upload file" → `user-can-upload-file`）；SC 只纳入需要可构建工作的项（如压测基础设施、安全审计工具），排除发布后结果指标和业务 KPI（如“把支持工单减少 50%”）。
18. 建立用户故事/动作清单：离散用户动作及其验收标准。
19. 建立任务覆盖映射：把每个任务映射到一个或多个需求/故事（按关键词推断或显式引用模式，如 ID、关键短语）。
20. 提取宪法规则集：原则名称与 MUST/SHOULD 规范性陈述。
21. 检测 A 重复检测：找出近似重复的需求，标记质量较低的措辞以待合并。
22. 检测 B 歧义检测：标记缺少可度量标准的模糊形容词（fast、scalable、secure、intuitive、robust）以及未解决的占位符（TODO、TKTK、???、`<placeholder>` 等）。
23. 检测 C 规格不足：有动词但缺对象或可度量结果的需求；缺少验收标准对齐的用户故事；引用了 spec/plan 中未定义的文件夹或组件的任务。
24. 检测 D 宪法一致性：与 MUST 原则冲突的任何需求或计划元素；宪法要求但缺失的章节或质量门。
25. 检测 E 覆盖率缺口：零任务关联的需求；未映射到任何需求/故事的任务；需要可构建工作的成功标准（性能、安全、可用性）未体现在任务中。
26. 检测 F 不一致：术语漂移（同一概念在不同文件中叫法不同）；plan 引用了 spec 中没有（或反之）的数据实体；任务顺序矛盾（如无依赖说明就把集成任务排在基础搭建任务之前）；需求冲突（如一个要求 Next.js、另一个指定 Vue）。
27. 按启发式分配严重度：CRITICAL=违反宪法 MUST、缺失核心 spec 工件，或阻塞基线功能的零覆盖需求；HIGH=重复或冲突需求、含糊的安全/性能属性、不可测试的验收标准；MEDIUM=术语漂移、缺失的非功能性任务覆盖、规格不足的边界情况；LOW=风格/措辞改进、不影响执行顺序的轻微冗余。
28. 输出 Markdown 分析报告（不写文件）：主表每行一条发现，列为 ID、Category、Severity、Location(s)、Summary、Recommendation；ID 稳定并按类别首字母加前缀（如 A1）。
29. 报告中附 Coverage Summary Table（Requirement Key、Has Task?、Task IDs、Notes）。
30. 报告中附 Constitution Alignment Issues（如有）与 Unmapped Tasks（如有）。
31. 报告中附指标：总需求数、总任务数、覆盖率%（至少有一个任务的需求占比）、歧义数、重复数、严重问题数。
32. 控制规模：发现最多列 50 条，其余用溢出汇总概括；重跑无改动时 ID 与计数保持一致。
33. 报告末尾给出简洁的 Next Actions：存在 CRITICAL 时建议在 `/speckit-implement` 之前解决；只有 LOW/MEDIUM 时用户可继续但给出改进建议；给出明确命令建议，如 "Run /speckit-specify with refinement"、"Run /speckit-plan to adjust architecture"、"Manually edit tasks.md to add coverage for 'performance-metrics'"。
34. 询问用户："Would you like me to suggest concrete remediation edits for the top N issues?"，并且不要自动应用这些修改。
35. 报告后检查 `hooks.after_analyze`：同样读取 `.specify/extensions.yml`、处理解析失败（告知用户并说明包括强制 hook 在内的 hook 未被检查）、过滤 `enabled: false`、跳过带非空 `condition` 的 hook、点号转连字符、可选 hook 输出块供用户执行、强制 hook 输出块后必须真正调用并等待完成；无 hook 或文件不存在则静默跳过。
36. 分析准则：绝不臆造缺失章节（缺失就如实报告）；优先处理宪法违规；用具体实例而非泛化模式说明问题；零问题时也优雅地输出成功报告及覆盖率统计。

适用边界 · 注意事项

• 项目不具备 spec-kit 结构（缺少 `.specify/` 目录、`.specify/memory/constitution.md`、`.specify/scripts/bash/check-prerequisites.sh` 等）时不适用。
• `tasks.md` 尚未由 `/speckit-tasks` 成功生成完整版本，或 spec.md/plan.md 缺失时不能运行，应先补齐前置命令。
• 需要直接修改/修复工件时不适用：本技能严格只读，修复只能由用户明确批准后手动执行。