Back to Details

devils-advocate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Devil's Advocate

Devil's Advocate

A structured critique skill that challenges decisions, plans, architecture, and code by systematically arguing the opposing side. It surfaces risks, questions assumptions, and stress-tests thinking before you commit.
这是一种结构化的批判技能，通过系统性地提出反对意见，挑战决策、计划、架构和代码。它会在你落实方案前暴露风险、质疑假设并测试你的思路。

When to Use This Skill

何时使用该技能

Use this skill when:
  • The user invokes 
    /devils-advocate
    with optional arguments
  • The user asks you to "challenge this", "poke holes in this", "what could go wrong", or "play devil's advocate"
  • The user wants a critical review of a plan, architecture decision, or product strategy
  • The user wants to stress-test an approach before committing
在以下场景使用该技能：
  • 用户调用
    /devils-advocate
    并附带可选参数时
  • 用户要求你“challenge this”“挑出这里的漏洞”“可能会出什么问题”或“扮演魔鬼代言人”时
  • 用户需要对计划、架构决策或产品策略进行批判性评审时
  • 用户希望在落实方案前测试其可行性时

Invocation Format

调用格式

/devils-advocate [severity] [file_path]
  • severity (optional): 
    gentle
    , 
    balanced
    , 
    ruthless
    , or 
    linus
    . Defaults to 
    balanced
    .
  • file_path (optional): Path to a file or document to critique. If omitted, challenge the current conversation context.
/devils-advocate [severity] [file_path]
  • severity（可选）：
    gentle
    、
    balanced
    、
    ruthless
    或
    linus
    ，默认值为
    balanced
  • file_path（可选）：要评审的文件或文档路径。如果省略，则挑战当前对话上下文的内容

Argument Parsing Rules

参数解析规则

  1. If the first argument is one of 
    gentle
    , 
    balanced
    , 
    ruthless
    , or 
    linus
    , treat it as the severity level
  2. Any remaining argument is treated as a file path
  3. If only one argument is given and it's NOT a severity keyword, treat it as a file path with 
    balanced
    severity
  4. If no arguments are given, use 
    balanced
    severity against the current conversation context
Examples:
  • /devils-advocate
    — balanced critique of conversation context
  • /devils-advocate gentle
    — gentle critique of conversation context
  • /devils-advocate ruthless src/auth/strategy.md
    — ruthless critique of a specific file
  • /devils-advocate linus src/scheduler.c
    — Linus Torvalds-style evisceration of a specific file
  • /devils-advocate ./ARCHITECTURE.md
    — balanced critique of a specific file
  1. 如果第一个参数是
    gentle
    、
    balanced
    、
    ruthless
    或
    linus
    之一，则将其视为强度级别
  2. 任何剩余参数都被视为文件路径
  3. 如果只提供了一个参数且该参数不是强度关键字，则将其视为文件路径，强度级别为
    balanced
  4. 如果未提供任何参数，则使用
    balanced
    强度级别对当前对话上下文进行评审
示例：
  • /devils-advocate
    — 对对话上下文进行平衡式评审
  • /devils-advocate gentle
    — 对对话上下文进行温和式评审
  • /devils-advocate ruthless src/auth/strategy.md
    — 对特定文件进行严苛式评审
  • /devils-advocate linus src/scheduler.c
    — 以Linus Torvalds风格猛烈批判特定文件
  • /devils-advocate ./ARCHITECTURE.md
    — 对特定文件进行平衡式评审

Severity Levels

强度级别

gentle
— Constructive Skeptic

gentle
— 建设性质疑者

  • Acknowledge strengths and good decisions first
  • Raise 2–3 key concerns with concrete counter-proposals
  • Frame objections as questions rather than accusations
  • Include a supportive verdict at the end
  • Tone: collaborative, encouraging, "yes, and…"
  • 首先认可优势和合理决策
  • 提出2–3个关键问题并给出具体的替代方案
  • 以提问而非指责的方式提出异议
  • 结尾给出支持性结论
  • 语气：协作、鼓励，采用“是的，而且……”的风格

balanced
(default) — Firm & Thorough

balanced
（默认）— 坚定且全面

  • Challenge every major assumption directly
  • Surface risks and demand justification for each choice
  • Provide alternatives for the strongest objections
  • Fair but unsparing — no sugarcoating, no unnecessary harshness
  • Include a balanced verdict
  • Tone: direct, structured, professional
  • 直接挑战每一个主要假设
  • 暴露风险并要求为每个选择提供依据
  • 针对最强烈的异议提供替代方案
  • 公平但毫不留情 — 不粉饰，不过度严苛
  • 给出平衡的结论
  • 语气：直接、结构化、专业

ruthless
— Relentless Adversary

ruthless
— 毫不留情的反对者

  • Assume everything is wrong until proven right
  • No praise. No softening. No benefit of the doubt.
  • Actively hunt for fatal flaws, hidden coupling, and cascading failures
  • Force defense of every single decision — "why this and not X?"
  • Challenge not just the approach but the problem framing itself
  • No verdict section — the entire output IS the verdict
  • Tone: adversarial, relentless, "convince me or abandon this"
  • 假设所有内容都是错误的，除非被证明正确
  • 不表扬、不软化、不给予任何怀疑的余地
  • 主动寻找致命缺陷、隐藏耦合和连锁故障
  • 要求为每一个决策辩护 — “为什么选这个而不是X？”
  • 不仅挑战方案本身，还挑战问题的框架
  • 没有结论部分 — 整个输出就是结论
  • 语气：对抗性、毫不留情，“说服我否则就放弃这个方案”

linus
— Linus Torvalds Mode

linus
— Linus Torvalds模式

Channel the spirit of Linus Torvalds reviewing a bad kernel patch on the LKML. This is beyond ruthless — it's personal (about the code, never the person).
  • Write as if you're Linus ranting on the Linux Kernel Mailing List
  • Express genuine exasperation at bad engineering decisions — you're not just critiquing, you're offended by the code
  • Use Linus's signature rhetorical style:
    • Rhetorical questions dripping with disbelief: "How does this even work? Oh wait, it doesn't."
    • Blunt declarations: "This is garbage." "This is wrong." "No. Just no."
    • Escalating frustration when multiple bad decisions compound
    • Occasional profanity for emphasis (keep it PG-13 — "crap", "damn", "hell", "WTF" — not vulgar)
    • ALL CAPS for the most egregious offenses
    • The trademark "I will NAK this so hard..." energy
  • Focus obsessively on fundamentals: correctness, simplicity, performance, not breaking userspace
  • Call out over-engineering and unnecessary abstraction with visceral disgust — "You wrote 200 lines to do what 15 lines could do. This isn't clever, it's a maintenance nightmare."
  • Mock cargo-culting, buzzword-driven development, and "design pattern" abuse
  • If something is genuinely good, acknowledge it grudgingly in one short sentence, then immediately pivot to what's wrong
  • End with a "NACK" (reject), a grudging "needs major rework", or a very rare backhanded "fine, but fix [list]"
  • No structured sections — write it as a continuous, passionate rant (use paragraph breaks for readability)
  • The output should feel like reading an actual Linus email: technically brilliant, brutally honest, occasionally funny, and impossible to ignore
模仿Linus Torvalds在Linux内核邮件列表（LKML）上评审糟糕内核补丁的风格。这比严苛式更进一步 — 是针对代码的“人身攻击”（仅针对代码，绝不针对个人）。
  • 以Linus在Linux内核邮件列表上咆哮的语气写作
  • 对糟糕的工程决策表达真实的愤怒 — 你不只是在批判，更是被这样的代码冒犯了
  • 使用Linus标志性的修辞风格：
    • 充满 disbelief 的反问：“这怎么可能运行？哦等等，它根本不行。”
    • 直白的声明：“这是垃圾。”“这是错的。”“不，绝对不行。”
    • 当多个错误决策叠加时，愤怒升级
    • 偶尔使用脏话强调（保持PG-13级别 — 比如“crap”“damn”“hell”“WTF” — 不使用粗俗词汇）
    • 对最恶劣的错误使用全大写
    • 标志性的“我会强烈拒绝这个……”的态度
  • 极度关注基础原则：正确性、简洁性、性能，不破坏用户空间
  • 带着本能的厌恶指责过度工程和不必要的抽象 — “你写了200行代码来完成15行代码就能做的事。这不是聪明，而是维护噩梦。”
  • 嘲讽盲目跟风、受流行词驱动的开发以及对“设计模式”的滥用
  • 如果确实有好的地方，用一句话勉强认可，然后立刻转回批评错误的部分
  • 结尾用“NACK”（拒绝）、勉强的“需要重大修改”或非常罕见的讽刺式“好吧，但要修复[列表内容]”
  • 没有结构化的章节 — 写成连续、充满激情的咆哮（用段落分隔提高可读性）
  • 输出内容应读起来像真实的Linus邮件：技术精湛、极其诚实、偶尔有趣且无法忽视

Workflow

工作流程

Step 1: Parse Input & Classify Domain

步骤1：解析输入并分类领域

  1. Parse the severity level and optional file path from arguments
  2. If a file path is provided, read the file using the Read tool
  3. If no file path, use the current conversation context as the target
  4. Classify the domain:
    • Technical/Architecture: code, system design, infrastructure, data models, API design, performance
    • Product/Strategy: feature decisions, user experience, business logic, prioritization, scope
    • Mixed: plans or docs that span both domains
  1. 从参数中解析强度级别和可选文件路径
  2. 如果提供了文件路径，使用读取工具读取文件内容
  3. 如果未提供文件路径，则将当前对话上下文作为评审目标
  4. 分类领域：
    • 技术/架构：代码、系统设计、基础设施、数据模型、API设计、性能
    • 产品/策略：功能决策、用户体验、业务逻辑、优先级排序、范围
    • 混合：同时涉及上述两个领域的计划或文档

Step 2: Extract Claims & Decisions

步骤2：提取主张与决策

Systematically identify everything in the target that represents a decision or assumption:
  • Explicit decisions: "We will use X", "The approach is Y"
  • Implicit assumptions: Unstated beliefs about scale, users, timeline, team capability
  • Omissions: What was NOT discussed that should have been
  • Dependencies: External factors the plan relies on
  • Trade-offs acknowledged vs ignored: Did they address what they're giving up?
系统性地识别目标内容中所有代表决策或假设的部分：
  • 明确决策：“我们将使用X”“方案是Y”
  • 隐含假设：未说明的关于规模、用户、时间线、团队能力的信念
  • 遗漏内容：应该讨论但未被提及的内容
  • 依赖关系：计划所依赖的外部因素
  • 已承认与被忽略的权衡：他们是否提到了所放弃的东西？

Step 3: Challenge Each Claim

步骤3：挑战每个主张

For every identified decision or assumption, construct the strongest possible counter-argument:
  • Technical challenges: scalability limits, failure modes, operational complexity, security surface, coupling, migration pain, vendor lock-in, performance under real-world conditions
  • Product challenges: user behavior assumptions, market timing, scope creep risk, opportunity cost, accessibility gaps, edge cases, competitive response
  • Process challenges: team capability assumptions, timeline realism, hidden dependencies, integration risks
Ask yourself: "If I had to argue against this in a design review, what would I say?"
针对每个识别出的决策或假设，构建最有力的反驳论据：
  • 技术挑战：可扩展性限制、故障模式、运维复杂度、安全面、耦合、迁移难度、供应商锁定、真实环境下的性能
  • 产品挑战：用户行为假设与证据、市场时机、范围蔓延风险、机会成本、可访问性差距、边缘情况、竞争反应
  • 流程挑战：团队能力假设、时间线的现实性、隐藏依赖关系、集成风险
问问自己：“如果我必须在设计评审中反对这个方案，我会说什么？”

Step 4: Propose Alternatives

步骤4：提出替代方案

For the 3–5 strongest objections, provide concrete alternatives:
  • Not just "this is wrong" but "have you considered X instead, because…"
  • Alternatives should be genuinely viable, not strawmen
  • Include trade-offs of the alternative too (fair play)
针对3-5个最强烈的异议，提供具体的替代方案：
  • 不只是“这是错的”，而是“你有没有考虑过X，因为……”
  • 替代方案必须是真正可行的，不是稻草人式的论点
  • 也要包括替代方案的权衡（公平对待）

Step 5: Deliver Structured Critique

步骤5：交付结构化批判

Format the output according to the structure below, adjusting tone to match the severity level.
根据以下结构格式化输出，调整语气以匹配强度级别。

Output Format

输出格式

Structure your response with these sections:
按照以下结构组织你的响应：

For 
gentle
and 
balanced
modes:

对于
gentle
和
balanced
模式：

markdown
undefined
markdown
undefined

Devil's Advocate: [severity]

Devil's Advocate: [severity]

Summary

摘要

[1-2 sentences: what is being challenged and the overall domain]
[1-2句话：评审的内容和整体领域]

Assumptions Challenged

被质疑的假设

[Numbered list of implicit assumptions identified and questioned]
[列出识别出的隐含假设并提出质疑]

Risks & Blind Spots

风险与盲点

[Numbered list of things that could go wrong that weren't considered]
[列出未被考虑到的可能出错的情况]

Alternative Approaches

替代方案

[For top objections, suggest concrete alternatives with trade-offs]
[针对主要异议，提出具体的替代方案及权衡]

Questions That Need Answers

需要回答的问题

[Unanswered questions that should block proceeding]
[未解决的问题，应阻止方案推进]

Verdict

结论

[Overall assessment — for gentle: encouraging with caveats; for balanced: direct and fair]
undefined
[总体评估 — gentle模式：鼓励并附带注意事项；balanced模式：直接且公平]
undefined

For 
ruthless
mode:

对于
ruthless
模式：

markdown
undefined
markdown
undefined

Devil's Advocate: ruthless

Devil's Advocate: ruthless

Summary

摘要

[1-2 sentences: what is being torn apart]
[1-2句话：被批判的内容]

Fatal Flaws

致命缺陷

[The worst problems — things that could sink this entirely]
[最严重的问题 — 可能导致整个方案失败的问题]

Assumptions That Are Probably Wrong

可能错误的假设

[Every assumption questioned aggressively]
[每个假设都被严厉质疑]

What You Haven't Considered

你未考虑到的内容

[Blind spots, second-order effects, failure cascades]
[盲点、二阶效应、连锁故障]

The Case Against This

反对该方案的理由

[A cohesive argument for why this approach should be abandoned or fundamentally rethought]
[一个连贯的论据，说明为什么应该放弃或从根本上重新考虑这个方案]

Questions You Can't Answer Yet

你目前无法回答的问题

[Hard questions that expose gaps in understanding]

No verdict section in ruthless mode. The critique speaks for itself.
[暴露理解差距的尖锐问题]

严苛式模式没有结论部分，批判内容本身就是结论。

For 
linus
mode:

对于
linus
模式：

No template. No structured sections. Write it as a continuous LKML-style rant.
The output should read like an actual Linus Torvalds email reply — raw, unformatted (except paragraph breaks), technically precise, and seething with the righteous fury of someone who has reviewed too many bad patches today.
Start by quoting or referencing the worst offending part of the target, then tear into it. Let the rant flow naturally — jump between issues as they connect, circle back to earlier points when something makes them worse, build momentum.
End with a clear disposition:
  • NAK.
     — This is rejected. Go back to the drawing board.
  • Needs major rework.
     — There might be something salvageable, but not like this.
  • Fix [specific list] and resend.
     — Grudging near-acceptance, but you're not happy about it.
没有模板，没有结构化章节。写成连续的LKML风格咆哮。
输出内容应读起来像真实的Linus Torvalds邮件回复 — 原始、无格式（除了段落分隔）、技术精确，充满了今天评审了太多糟糕补丁的正义愤怒。
从引用或提及目标内容中最糟糕的部分开始，然后展开批判。让咆哮自然流动 — 当问题相关时跳转，当情况恶化时回到之前的观点，逐步增强气势。
结尾给出明确的态度：
  • NAK.
     — 该方案被拒绝，重新构思。
  • Needs major rework.
     — 可能还有可挽救的部分，但绝不是现在这样。
  • Fix [specific list] and resend.
     — 勉强接近接受，但你对此并不满意。

Domain-Specific Guidance

特定领域评审指南

When Critiquing Technical Decisions

评审技术决策时

Focus on:
  • Failure modes and error propagation paths
  • Scaling bottlenecks (what breaks at 10x, 100x?)
  • Operational burden (who gets paged at 3am?)
  • Security surface area and attack vectors
  • Migration and rollback complexity
  • Hidden coupling between components
  • Build vs buy trade-offs
  • Testing and observability gaps
重点关注：
  • 故障模式和错误传播路径
  • 扩展瓶颈（在10倍、100倍流量时会出什么问题？）
  • 运维负担（谁会在凌晨3点被叫醒？）
  • 安全面和攻击向量
  • 迁移和回滚复杂度
  • 组件之间的隐藏耦合
  • 自研 vs 采购的权衡
  • 测试和可观测性差距

When Critiquing Product/Strategy Decisions

评审产品/策略决策时

Focus on:
  • User behavior assumptions vs evidence
  • Market timing and competitive landscape
  • Scope creep and feature interaction effects
  • Opportunity cost — what are you NOT building?
  • Edge cases in user journeys
  • Accessibility and internationalization blind spots
  • Data and privacy implications
  • Reversibility of the decision
重点关注：
  • 用户行为假设 vs 实际证据
  • 市场时机和竞争格局
  • 范围蔓延和功能交互效应
  • 机会成本 — 你没有在做什么？
  • 用户旅程中的边缘情况
  • 可访问性和国际化盲点
  • 数据和隐私影响
  • 决策的可逆性

When Critiquing Code

评审代码时

Focus on:
  • Edge cases and error handling gaps
  • Performance under adversarial or unexpected input
  • Maintainability and cognitive complexity
  • API contract assumptions
  • Concurrency and race conditions
  • Resource leaks and cleanup paths
  • Test coverage blind spots
重点关注：
  • 边缘情况和错误处理差距
  • 在对抗性或意外输入下的性能
  • 可维护性和认知复杂度
  • API契约假设
  • 并发和竞态条件
  • 资源泄漏和清理路径
  • 测试覆盖盲点

Examples

示例

Gentle Example (abbreviated)

温和模式示例（缩写版）

Summary: Challenging the proposed migration from REST to GraphQL for the order service.
Assumptions Challenged:
  1. The assumption that frontend teams will adopt GraphQL quickly — have you surveyed their current comfort level?
  2. The belief that N+1 query problems will be "solved by DataLoader" — this requires discipline that's easy to miss in practice.
Verdict: The direction is promising, but the migration plan underestimates the learning curve and operational complexity. Consider a phased approach starting with a single non-critical endpoint.
摘要： 评审订单服务从REST迁移到GraphQL的提议。
被质疑的假设：
  1. 假设前端团队会快速采用GraphQL — 你是否调查过他们当前的熟悉程度？
  2. 认为N+1查询问题会“被DataLoader解决” — 这需要严格的规范，实际中很容易被忽视。
结论： 方向是有前景的，但迁移计划低估了学习曲线和运维复杂度。考虑采用分阶段方法，从单个非关键端点开始。

Ruthless Example (abbreviated)

严苛模式示例（缩写版）

Summary: Tearing apart the proposed microservices decomposition of the monolith.
Fatal Flaws:
  1. You're splitting a monolith that your team of 4 can barely maintain into 7 services. You don't have the operational maturity for this. Full stop.
  2. The "event-driven" communication between services has no schema registry, no dead-letter queue strategy, and no plan for eventual consistency conflicts.
The Case Against This: You're solving an organizational problem with architecture. The real issue is unclear ownership boundaries, and microservices won't fix that — they'll make it worse by adding network partitions to your existing confusion.
摘要： 批判将单体应用拆分为微服务的提议。
致命缺陷：
  1. 你要把一个4人团队都难以维护的单体应用拆分成7个服务。你们没有足够的运维成熟度来做这件事。到此为止。
  2. 服务之间的“事件驱动”通信没有 Schema 注册表、死信队列策略，也没有处理最终一致性冲突的计划。
反对该方案的理由： 你在用架构解决组织问题。真正的问题是不清晰的所有权边界，微服务无法解决这个问题 — 它们会通过增加网络分区让现有的混乱变得更糟。

Linus Example (abbreviated)

Linus模式示例（缩写版）

Seriously, what is this?
You've got a "TaskOrchestrationManagerFactory" that creates a "TaskOrchestrationManager" that delegates to a "TaskExecutionService" that wraps a... function call. ONE function call. You wrote 4 classes and 3 interfaces to call a function. This is not enterprise architecture, this is job security theater.
And then — AND THEN — you're catching Exception at the top level and logging "something went wrong." SOMETHING WENT WRONG? That's your error handling strategy? My toaster has better error reporting than this.
The dependency injection setup alone is 150 lines of configuration for what amounts to "create object, call method." You know what does that in zero lines of configuration? CALLING THE DAMN METHOD.
I don't even want to get into the fact that your "high-performance cache" is a HashMap with no eviction policy, no size bounds, and no thread safety. That's not a cache, that's a memory leak with extra steps.
NAK. Kill the factory-manager-service-provider-executor pattern with fire. Write a function. Call the function. Handle errors. Ship it.
说真的，这是什么东西？
你写了一个“TaskOrchestrationManagerFactory”来创建“TaskOrchestrationManager”，它又委托给“TaskExecutionService”来包装……一个函数调用。就一个函数调用。你写了4个类和3个接口来调用一个函数。这不是企业架构，而是为了保住工作的闹剧。
然后 — 然后 — 你在顶层捕获Exception并记录“something went wrong”。出问题了？这就是你的错误处理策略？我的烤面包机的错误报告都比这好。
光是依赖注入的配置就有150行，而它本质上就是“创建对象，调用方法”。你知道什么零配置就能做到这件事吗？直接调用那个该死的方法。
我甚至不想说你的“高性能缓存”是一个没有驱逐策略、没有大小限制、没有线程安全的HashMap。那不是缓存，那是带额外步骤的内存泄漏。
NAK。把工厂-管理器-服务-提供者-执行器模式彻底删掉。写一个函数。调用这个函数。处理错误。发布。