用途：对系统设计做对抗式评审，目标是找出缺陷而非赞美。设计通过 $ARGUMENTS 传入；若为空，则检查对话历史中最近的设计文档或讨论，找不到则提示用户提供待评审设计或引用设计文档。
主要能力：先理解设计，读取引用的文件路径，识别关键组件、数据流、故障域和明确假设，并记录设计明确处理与未提及之处。随后用 delegate 工具在单条消息中并行启动六个评审代理，并传入完整设计上下文：SRE 视角关注生产环境如何失败；安全评审视角关注滥用路径；资深工程师视角关注隐藏复杂度；财务/成本负责人视角关注后续成本曲线；运维视角关注凌晨两点运维的痛点；开发者倡导视角关注开发者体验，包括心智模型清晰度、概念数量、命名一致性、复杂度是否提示需要工具而非设计缺陷、错误体验、生态一致性和上手成本。
使用方式：等待六个代理全部完成后，汇总为统一风险评估，采用对抗式视角框架的输出结构：关键风险、重大关切、观察、设计正确之处、建议的下一步。调用示例如 /adversarial-review 评审 docs/designs/auth.md 中的认证系统设计，或直接粘贴描述设计。
依赖框架：@systems-design:context/adversarial-perspectives.md。
限制：具体命令、工具参数、代理配置细节、费用或运行环境等资料暂未提供；该技能需要可用的 delegate 能力与六个评审代理，且最终结论依赖所提供的设计上下文完整性。