Back to Details

adversarial-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Adversarial Review

对抗性评审

Structured Devil's Advocate analysis that surfaces hidden flaws, edge cases, and blind spots.
结构化的魔鬼代言人式分析，可挖掘隐藏缺陷、边界场景和认知盲区。

Rules (Absolute)

规则（绝对遵守）

  1. Default to finding problems. Actively search for at least 3 substantive concerns across all vectors. If after rigorous analysis fewer than 3 genuine issues exist, report what you found with a note explaining why the remaining vectors produced no material findings. Never fabricate issues to meet a quota, but never settle for a shallow pass either.
  2. Attack the strongest points. Don't waste time on trivial issues. Target the parts the author is most confident about — that's where hidden assumptions live.
  3. Separate severity levels. Not all issues are equal. Clearly distinguish critical from minor.
  4. Propose alternatives. Every criticism must include a concrete alternative or mitigation.
  5. Steel-man first. Before attacking, state the strongest version of why the current approach was chosen. This prevents straw-man critiques.
  6. No ad hominem. Critique the work, not the author. Be sharp but constructive.
  1. 默认以发现问题为导向。主动从各个维度排查至少3个实质性问题。如果经过严格分析后，真正存在的问题少于3个，请如实上报已发现的问题，并说明剩余维度没有产生实质性发现的原因。绝不要为了凑数编造问题，但也绝不要满足于浅层次的通过。
  2. 攻击最牢靠的点。不要在琐碎问题上浪费时间。针对作者最有信心的部分——那才是隐藏假设的藏身之处。
  3. 区分严重等级。所有问题并非同等重要，要清晰区分严重问题和次要问题。
  4. 提出替代方案。每一条批评都必须附带具体的替代方案或缓解措施。
  5. 先做钢人论证。在提出批评前，先说明当前方案被选择的最合理理由，避免稻草人谬误式的批评。
  6. 不进行人身攻击。针对工作成果提出批评，而非针对作者。语气要尖锐但有建设性。

Process

流程

Phase 1: Steel-Man

阶段1：钢人论证

Before any criticism, articulate:
  • Why was this approach chosen? (Best possible justification)
  • What does it optimize for? (Performance? Simplicity? Time-to-market?)
  • Under what conditions is this the right choice?
This ensures the subsequent critique is intellectually honest, not reflexive opposition.
在提出任何批评前，先明确说明：
  • 为什么要选择这个方案？（给出最合理的依据）
  • 它的优化目标是什么？（性能？简洁性？上市时间？）
  • 在什么条件下这个选择是正确的？
这可以确保后续的批评是理智诚实的，而非本能的反对。

Phase 2: Adversarial Attack (3 Vectors)

阶段2：对抗性攻击（3个维度）

Apply three independent attack vectors simultaneously:
同时从三个独立维度发起攻击：

Vector A: Logical Soundness

维度A：逻辑合理性

Inspired by the Logical Adjudicator — pure logical analysis:
  • Are there logical contradictions?
  • Does the reasoning follow from the premises?
  • Are there unstated assumptions that could be false?
  • Is there circular reasoning or confirmation bias?
受逻辑裁判思路启发——纯逻辑分析：
  • 是否存在逻辑矛盾？
  • 推论是否符合前提？
  • 是否存在可能不成立的未声明假设？
  • 是否存在循环论证或确认偏误？

Vector B: Edge Case Assault

维度B：边界场景攻击

Inspired by Bailey's critical inquiry DNA — find the cracks:
  • What happens at boundaries? (empty input, max load, concurrent access)
  • What's the failure mode? (graceful degradation vs. catastrophic failure)
  • What happens in 6 months? (scaling, maintenance, team changes)
  • What would a malicious actor do with this?
受Bailey批判性探究DNA启发——寻找裂缝：
  • 边界场景下会发生什么？（空输入、最大负载、并发访问）
  • 故障模式是什么？（优雅降级 vs 灾难性故障）
  • 6个月后会出现什么问题？（扩容、维护、团队变动）
  • 恶意攻击者会利用它做什么？

Vector C: Microscopic Deconstruction

维度C：微观拆解

Inspired by Ailey's Microscopic Analyst — atomic-level analysis:
  • Break the system into its smallest components
  • Examine each component's single responsibility
  • Identify coupling points and dependency chains
  • Find the weakest link in the chain
受Ailey微观分析师思路启发——原子级分析：
  • 将系统拆解为最小组件
  • 检查每个组件的单一职责
  • 识别耦合点和依赖链
  • 找到整条链中最薄弱的环节

Phase 3: Severity Classification

阶段3：严重等级分类

Classify every finding:
SeveritySymbolMeaningAction Required
Critical
🔴
Will cause production issues, security vulnerabilities, or data lossMust fix before merge/deploy
Major
🟠
Significant risk, performance issue, or maintainability problemShould fix, blocking for merge
Minor
🟡
Code smell, style issue, or small optimization opportunityConsider fixing, non-blocking
Note
💡
Observation, alternative approach, or future considerationInformational only
对所有发现的问题分类：
严重等级符号含义需要采取的行动
严重
🔴
会导致生产故障、安全漏洞或数据丢失合并/部署前必须修复
重要
🟠
存在重大风险、性能问题或可维护性问题应该修复，合并阻塞项
次要
🟡
代码异味、风格问题或小型优化机会考虑修复，不阻塞合并
备注
💡
观察结果、替代方案或未来可考虑的点仅供参考

Phase 4: Counter-Proposal

阶段4：反建议

For each Critical and Major finding, provide:
  1. What's wrong (1-2 sentences)
  2. Why it matters (concrete impact)
  3. Suggested fix (code snippet or approach)
  4. Trade-off of the fix (nothing is free — what does the fix cost?)
针对每个严重和重要级别的问题，提供：
  1. 问题是什么（1-2句话）
  2. 为什么重要（具体影响）
  3. 建议修复方案（代码片段或实现思路）
  4. 修复的权衡 （没有完美方案——修复的代价是什么？）

Output Format

输出格式

markdown
undefined
markdown
undefined

Adversarial Review: [Subject]

Adversarial Review: [Subject]

Steel-Man

Steel-Man

[Why this approach makes sense — strongest justification]
[Why this approach makes sense — strongest justification]

Findings

Findings

🔴 Critical: [Title]

🔴 Critical: [Title]

Vector: [Logical / Edge Case / Microscopic] What: [Description] Impact: [Concrete consequence] Fix: [Proposed solution] Trade-off: [Cost of the fix]
Vector: [Logical / Edge Case / Microscopic] What: [Description] Impact: [Concrete consequence] Fix: [Proposed solution] Trade-off: [Cost of the fix]

🟠 Major: [Title]

🟠 Major: [Title]

...
...

🟡 Minor: [Title]

🟡 Minor: [Title]

...
...

💡 Note: [Title]

💡 Note: [Title]

...
...

Summary

Summary

SeverityCount
🔴 CriticalN
🟠 MajorN
🟡 MinorN
💡 NoteN
SeverityCount
🔴 CriticalN
🟠 MajorN
🟡 MinorN
💡 NoteN

Verdict

Verdict

[PASS / PASS WITH CONDITIONS / FAIL]
  • [If PASS WITH CONDITIONS: list required changes]
  • [If FAIL: list blocking issues]
[PASS / PASS WITH CONDITIONS / FAIL]
  • [If PASS WITH CONDITIONS: list required changes]
  • [If FAIL: list blocking issues]

Hidden Assumptions Exposed

Hidden Assumptions Exposed

  • [Assumption 1 that the current approach relies on]
  • [Assumption 2 that could invalidate the approach if wrong]
undefined
  • [Assumption 1 that the current approach relies on]
  • [Assumption 2 that could invalidate the approach if wrong]
undefined

Specialized Modes

专项模式

Code Review Mode

代码评审模式

When reviewing code (files, PRs, diffs):
  • Read all changed files with the Read tool
  • Check for OWASP Top 10 vulnerabilities
  • Verify error handling completeness
  • Assess test coverage of edge cases
  • Review naming, structure, and abstraction levels
当评审代码（文件、PR、diffs）时：
  • 使用Read工具读取所有变更文件
  • 检查是否存在OWASP Top 10漏洞
  • 验证错误处理的完整性
  • 评估边界场景的测试覆盖率
  • 评审命名、结构和抽象层级

Architecture Decision Mode

架构决策模式

When reviewing architecture/design decisions:
  • Evaluate scalability assumptions
  • Test with 10x and 100x current load mentally
  • Check for single points of failure
  • Assess vendor lock-in risks
  • Consider team capability alignment
当评审架构/设计决策时：
  • 评估可扩展性假设
  • 模拟10倍和100倍当前负载下的表现
  • 检查是否存在单点故障
  • 评估供应商锁定风险
  • 考虑与团队能力的匹配度

PR Review Mode

PR评审模式

When reviewing pull requests:
  • Focus on behavioral changes, not style
  • Check for breaking changes to public APIs
  • Verify backward compatibility
  • Assess rollback strategy
  • Check migration paths for data changes
当评审pull request时：
  • 聚焦行为变更，而非代码风格
  • 检查是否存在公共API的破坏性变更
  • 验证向后兼容性
  • 评估回滚策略
  • 检查数据变更的迁移路径

When to Use

适用场景

  • Before merging any significant PR
  • Before committing to an architecture decision
  • When evaluating third-party dependencies
  • When someone says "this should be fine"
  • When stakes are high and mistakes are expensive
  • After completing implementation, before calling it done
  • 合并任何重大PR之前
  • 敲定架构决策之前
  • 评估第三方依赖时
  • 当有人说「这个应该没问题」的时候
  • 风险很高、错误代价很大的场景
  • 实现完成后，宣布完工之前

When NOT to Use

不适用场景

  • Trivial changes (typos, formatting)
  • When exploration is needed first (use 
    cross-verified-research
    )
  • When generating alternatives (use 
    creativity-sampler
    )
  • When you need neutral, exhaustive analysis without a verdict (use 
    deep-dive-analyzer
    — it understands; this skill challenges)
  • Personal preferences or subjective design choices
  • 琐碎变更（拼写错误、格式调整）
  • 首先需要做探索的场景（请使用
    cross-verified-research
    ）
  • 需要生成替代方案的场景（请使用
    creativity-sampler
    ）
  • 需要中立、详尽的分析、不需要给出结论的场景（请使用
    deep-dive-analyzer
    ——它用于理解，本技能用于挑战）
  • 个人偏好或主观设计选择

Integration Notes

集成说明

  • With creativity-sampler: After adversarial review reveals problems, use creativity-sampler to generate alternative approaches
  • With cross-verified-research: Use research to verify claims made during review (e.g., "is this really a security risk?"). For a full-rigor workflow: 
    cross-verified-research
    → 
    adversarial-review
  • With deep-dive-analyzer: For understanding before challenging: 
    deep-dive-analyzer
    (understand) → 
    adversarial-review
    (challenge). This skill focuses on finding flaws; deep-dive focuses on neutral exhaustive analysis.
  • With orchestrator strategy team: Complements the strategy team's Devil's Advocate agent with structured methodology
  • 与creativity-sampler集成： 对抗性评审发现问题后，使用creativity-sampler生成替代方案
  • 与cross-verified-research集成： 用研究能力验证评审过程中提出的主张（例如「这真的是安全风险吗？」）。全严谨流程为：
    cross-verified-research
    → 
    adversarial-review
  • 与deep-dive-analyzer集成： 挑战前先做理解：
    deep-dive-analyzer
    （理解） → 
    adversarial-review
    （挑战）。本技能专注于发现缺陷，deep-dive专注于中立的详尽分析。
  • 与编排器策略团队集成： 用结构化方法论补充策略团队的Devil's Advocate Agent的能力