用途
Spec-Critique 的核心用途是在实现开始之前，对规格文档（specification）进行批判性审查，检查其准确性、完整性和可行性。其核心原则是：使用扩展思考（extended thinking）做深度分析，在实现之前找出问题。
何时使用
以下情况应当使用：规格编写完成之后、实现规划开始之前、规格涉及外部集成时、包含多个组件的复杂功能。
以下情况属于例外：琐碎改动的简单规格、已由其他代理审查过的规格。
铁律
对于复杂任务（外部集成、多服务变更），没有经过规格审查就不允许进入实现。
所需输入
审查之前需要具备：spec.md（待审查的规格）、需求文档（原始用户需求）、项目上下文（技术栈、模式）。文档中给出了读取示例命令：
# 读取 spec
cat .claude/context/specs/[task-name]-spec.md
# 读取原始需求
cat .claude/context/requirements/[task-name].md
# 读取项目上下文
cat .claude/context/tech-stack.md
工作流程
阶段 1：加载全部上下文
理解规格声称了什么、用户最初要求了什么、代码库中存在哪些模式。
阶段 2：深度分析（使用扩展思考）
这是关键阶段，需从五个方面深入思考：
- 技术准确性：对比规格与需求及代码库，检查包名是否正确、import 语句是否匹配 API 模式、API 调用签名是否匹配文档、配置项和环境变量是否正确。常见错误包括包名错误（如 "react-query" 与 "@tanstack/react-query"）、过时的 API 模式（如使用已弃用函数）、错误的函数签名（如参数顺序错误）、缺少必要配置（如缺少环境变量）。
- 完整性：检查是否覆盖全部需求、验收标准是否可测试、边界情况是否处理（错误条件、空状态、超时）、集成点是否清晰。
- 一致性：检查包名是否一致、文件路径是否一致、模式是否一致、术语是否一致。
- 可行性：检查依赖是否可用（所有包是否存在并维护）、基础设施是否现实、实现顺序是否合理（依赖先于被依赖项）、范围是否恰当（不过度设计也不欠规范）。
- 需求对齐：检查是否使用了已验证的信息、未验证的声明是否标注清楚、已知问题是否处理、需求建议是否被采纳。
阶段 3：编目问题
列出所有发现的问题，格式示例：
## 发现的问题
### 1. [严重度：高] 包名不正确
- **规格中写的是**："[错误值]"
- **应为**："[正确值]"
- **位置**：第 45 行，Requirements 章节
### 2. [严重度：中] 缺少边界情况
- **需求**："处理连接失败"
- **规格**：未指定错误处理
- **位置**：Implementation Notes 章节
### 3. [严重度：低] 术语不一致
- **问题**：同一概念同时使用 "memory" 和 "episode"
- **位置**：全文
阶段 4：修复问题
对每个发现的问题直接在 spec 中修复，并验证修改已应用、记录修改内容。
阶段 5：创建审查报告
报告结构包含：摘要（按技术准确性、完整性、一致性、可行性、需求对齐五个类别给出 PASS/FAIL 与问题数量）、已发现并修复的问题（按高/中/低严重度分组）、未发现问题（如适用）、置信度（高/中/低）、建议。
报告模板片段：
# Spec 审查报告
**Spec**：[spec-name]
**日期**：[timestamp]
## 摘要
| 类别 | 状态 | 问题 |
| ------------------ | ------- | ----- |
| Technical Accuracy | PASS/FAIL | [count] |
阶段 6：验证修复
修改后验证 spec 仍为有效 markdown，并检查关键章节是否存在：
# 验证 spec 仍是有效 markdown
head -50 .claude/context/specs/[task-name]-spec.md
# 检查关键章节是否存在
grep -E "^##? Overview" spec.md
grep -E "^##? Requirements" spec.md
grep -E "^##? Success Criteria" spec.md
严重度指南
- 高：会导致实现失败，如错误包名、错误 API 签名、缺少关键需求、无效配置。
- 中：可能引发问题，如缺少边界情况、错误处理不完整、集成点不清晰、模式不一致。
- 低：次要改进，如术语不一致、文档缺口、样式问题、次要优化。
类别定义
- 准确性：技术正确性（包、API、配置）
- 完整性：需求与边界情况的覆盖
- 一致性：文档内部的自洽
- 可行性：实际可实现性
- 对齐：与原始需求的匹配
验证清单
完成规格审查前需确认：所有章节已用扩展思考分析、技术准确性已验证、完整性已对照需求检查、一致性已在全文中验证、可行性已评估、所有问题已按严重度编目、所有高/中问题已修复、审查报告已创建、修复后 spec 仍然有效。
扩展思考提示词
文档提供了一段分析时使用的思考提示词模板，示例开头为：
"Looking at this spec, I need to deeply analyze it against the requirements...
其思路是逐项检查包名、API 模式、完整性、一致性、可行性，最后汇总需要修复的问题数量。
常见错误
- 表面化审查：略读会漏掉关键问题；应使用扩展思考深入分析每个章节。
- 只报告不修复：仅列出问题不会改进 spec；应直接修复问题，让 spec 更好。
与其他技能的集成
可与 spec-writing（提供待审查的规格）、complexity-assessment（帮助确定是否需要审查）、debugging（如果规格审查暴露代码问题时使用）配合。
铁律
- 绝不容忍包含矛盾的规格，哪怕矛盾很小。
- 始终显式暴露隐藏假设——它们与已声明的需求同等重要。
- 绝不让范围蔓延在规格审查中不被质疑。
- 批准前始终验证边界情况和错误场景。
- 绝不审查实现方式——只关注规格的完整性和一致性。
反模式
反模式表格列出了以下错误做法与正确做法：批准含矛盾的规格（会导致下游实现错误解决矛盾；应在批准前标出所有矛盾，哪怕很小）、遗漏隐藏假设（假设会在实现中变成不匹配的需求；应显式暴露 spec 依赖的每一个假设）、跳过边界情况审查（错误场景在实现中才发现太晚；应验证 spec 中所有边界条件和错误路径）、审查实现细节（偏离规格质量，spec 定义 WHAT 而非 HOW；应聚焦完整性、一致性和可测试性）、接受模糊的成功标准（交付无法验证是否完成；应为每个需求要求可度量、可测试的验收标准）。
记忆协议
开始前读取 .claude/context/memory/learnings.md。完成后：新模式写入 learnings.md，发现问题写入 issues.md，做出的决定写入 decisions.md。原则是“假设中断：如果没写进记忆，就等于没发生过（ASSUME INTERRUPTION: If it's not in memory, it didn't happen.）”。