用途
该技能用于对技术设计文档（TECH-DESIGN.md）及其架构决策记录（ADR）执行对抗式复审。其核心目标是主动挑战已有设计，寻找缺口、缺少依据的决策以及未被考虑的风险，而非验证设计是否正确。技能默认不做认可，先提出不同意见，只有在确实找不到真实问题时才承认某项决策成立。
为什么需要这样做
如果让产出设计的同一段对话回答“你确定吗？”，往往得到的是一种辩护，而不是批评；模型存在谄媚倾向（RLHF 训练会奖励认同）和自偏好偏差（模型会更正面地评价自己先前的输出）。因此，尽可能从一段没有设计产出历史的崭新对话中运行本技能。如果必须在生成该技术设计文档的同一对话中运行，应在开始前明确告知用户，因为在这种情况下复审会较弱。
所需输入
- TECH-DESIGN.md 及其 adrs/*.md 文件——必需。
- PRD.md 和 Design.md（如果存在）——用于交叉检查，确认没有决策与已声明的范围或界面需求相矛盾。不是运行复审的必需项，但跳过它们会缩小复审范围；如果跳过，应说明这一点。
工作流程
-
完整阅读 TECH-DESIGN.md 以及每一个 ADR。
-
对每个 ADR，按以下标准检查——缺少或不足任何一项即不通过：
- 上下文是否真正支撑该决策（不是通用套话）。
- 考虑的替代方案是否是真正可行的选项，而不是虚假选择（同一件事的两个名字不算）。
- 后果是否至少包含一项真实成本或权衡，而不仅仅是收益。
- 该决策是否与项目的实际规模相称——既要指出过度工程，也要指出工程不足。
-
跨文档检查：
- 是否有任何决策与 PRD 的范围或明确的“No alcance”相矛盾？（如果 PRD.md 可用）
- Design.md 中每个涉及数据的元素是否在数据模型中都有覆盖？（如果 Design.md 可用）
- 是否完全缺少某些决策领域——组件、数据模型、API 契约、技术栈、状态管理、弹性——项目明显需要但没有 ADR 涉及这些内容？
-
主动寻找缺失的内容：未处理的失败模式、PRD 隐含但未写明的非功能需求（性能、并发、离线使用），以及某项决策自身 ADR 未提及的二阶后果。
-
产出一份发现报告——不要直接编辑 TECH-DESIGN.md 或任何 ADR。该技能只负责报告；由人类决定要改什么。
输出
一份发现报告，按严重程度从高到低排序：
- Crítico（严重）——如果不处理，设计很可能失败或与已声明需求相矛盾。
- Advertencia（警告）——真实缺口或依据薄弱的决策，值得在实现前修复。
- Sugerencia（建议）——较小的改进，不阻塞。
每条发现应包含：针对哪个 ADR 或章节、具体问题是什么、为什么重要——而不是含糊的“考虑复核一下”。如果在某个领域确实认真尝试后没有发现真实问题，应直说，而不是为了显得全面而编造一个小问题。
质量门
返回结果前，静默检查：
- 每一个 ADR 都确实被挑战过——没有任何一个被跳过或盖章通过。
- 至少有一条发现指出了原 ADR 遗漏的真实权衡，或者报告明确说明该设计经受住了审视——绝不能是没有任何具体内容的泛泛“看起来没问题”。
- 没有任何一条发现是为了凑报告而编造的。