用途
swing-review 是一个对抗性审查技能，扮演“魔鬼代言人”角色，对代码、架构、PR 和决策进行压力测试。其目标不是确认方案可行，而是主动寻找隐藏缺陷、边界情况和盲点，帮助在问题进入生产环境前发现它们。
主要能力
该技能围绕四个阶段展开：
阶段一：钢铁人论证（Steel-Man） 在提出任何批评之前，先阐述当前方案被选择的最强理由：它优化了什么（性能、简洁性、上市时间等），以及在什么条件下这是正确选择。这确保后续批评是智识上诚实的，而非条件反射式的反对。
阶段二：对抗性攻击（三个向量） 同时应用三个独立的攻击向量：
- 向量 A：逻辑严谨性——检验推理是否成立，包括前提、结论、逻辑流、未言明的假设和确认偏误。
- 向量 B：边界情况攻击——检验方案能否在现实中存活，包括边界条件（空输入、最大负载、并发访问、零状态）、失败模式、六个月后的可扩展性与维护负担、以及恶意行为者可能利用的漏洞。
- 向量 C：结构完整性——检验架构与设计是否健全，包括组件职责是否单一清晰、耦合点与依赖链、最薄弱的结构环节、以及哪个组件变更会导致最多级联失败。
阶段三：严重程度分类 每个发现按四级分类：严重（🔴，会导致生产问题、安全漏洞或数据丢失，合并/部署前必须修复）、重要（🟠，重大风险、性能问题或可维护性问题，应修复，阻塞合并）、次要（🟡，代码异味、风格问题或小优化机会，可考虑修复，非阻塞）、提示（💡，观察、替代方案或未来考虑，仅供参考）。
阶段四：反提案 对每个严重和重要发现，提供：问题是什么（1-2 句）、为什么重要（具体影响）、建议修复（代码片段或方法）、修复的权衡代价（没有免费的修复）。
使用方式
该技能定义了明确的输出格式，包括钢铁人论证、按严重程度分组的发现列表、汇总表格、结论（通过/有条件通过/失败）以及暴露的隐藏假设。结论标准为：失败——存在无可行短期缓解措施的严重发现，或 3 个以上重要发现；有条件通过——存在有可行缓解措施的严重发现，或 1-2 个重要发现；通过——无严重发现、无重要发现，仅有次要和提示。
该技能还提供三种专门模式：代码审查模式（读取所有变更文件、检查 OWASP Top 10 漏洞、验证错误处理完整性、评估边界情况测试覆盖）、架构决策模式（评估可扩展性假设、以 10 倍和 100 倍当前负载进行推演、检查单点故障、评估供应商锁定风险、考虑团队能力匹配）、PR 审查模式（关注行为变更而非风格、检查公共 API 破坏性变更、验证向后兼容性、评估回滚策略、检查数据变更的迁移路径）。
适用场景
- 合并任何重要 PR 之前
- 确定架构决策之前
- 评估第三方依赖时
- 当有人说“这应该没问题”时
- 当风险高、错误代价昂贵时
- 完成实现后、宣布完成之前
限制与注意事项
不适用于：琐碎变更（拼写错误、格式调整）；需要先探索的场景（应使用 swing-research）；生成替代方案的场景（应使用 swing-options）；需要中立、详尽分析而不需要结论的场景；个人偏好或主观设计选择。
关键注意事项：必须始终先做钢铁人论证，否则会产生被作者驳回的稻草人批评；不要用风格挑剔来填充发现；结论必须遵循阈值规则，不能凭感觉升级；每个批评都需要修复方案和权衡代价；审查前必须阅读代码，不能仅凭文件名或描述进行批评。
该技能可与其他技能集成：对模糊请求先运行 swing-clarify；对抗性审查揭示问题后使用 swing-options 生成替代方案；使用 swing-research 验证审查中提出的主张。