用途：审查设计工件，检查内部一致性、跨工件对齐和明显缺口。把需求视为既定事实，只标记工件之间的冲突，而非对产品决策的异议。
流程：一、发现与分类：递归读取目录内所有 .md 文件，按路径启发式分类（先匹配者优先）：proposal.md 或 motivation.md → 动机/提案；design.md 或 architecture.md → 设计/架构；spec.md 或 specs/**/spec.md → 需求/规格；tasks.md 或 tasks/*.md → 任务/计划。回退时按内容（标题、结构）推断角色，模糊时归于最接近角色并注明。工件可兼具多角色，先记主要角色；缺失工件不算错误。
二、审查检查（跳过不适用项，每个问题须引用确切工件、章节与文本）：跨工件一致性——比较重叠主题工件，标记矛盾、范围漂移、遗漏项、术语漂移。需求质量——仅检查可测试性与完整性，不评估产品意图：每条需求至少有一个可测试场景；场景覆盖边界与错误条件；无应填未填的占位符（TBD、TODO 等）。任务质量——任务自包含；引用其他工件须含文件路径与具体章节标题或需求 ID；验收标准忠实于来源；描述构建内容而非逐行实现；无未解析占位符（如 <path>）；无无独立行为价值的纯基础设施、纯测试或纯文档任务。内部一致性——工件内无自相矛盾，交叉引用一致，未决事项明确标注。
三、呈现发现：直接向用户报告，引用确切路径与文本；有多种合理修复时推荐最小安全修复；仅在需决定产品行为、范围或架构时提问。
限制：不批评需求，仅标记不可测试、不完整、占位符或冲突；不重写工件、不审查代码、不虚构缺失工件。