challenge-that

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Challenge That

质疑分析

Force critical evaluation by analyzing from multiple adversarial perspectives.

通过从多个对抗性视角进行分析，强制开展批判性评估。

When to Use

适用场景

Invoke

/challenge-that

when:

Claude accepted a proposal without critical evaluation
You want to stress-test a decision before committing
Requirements feel under-examined
Something seems off but you can't articulate why

当以下情况出现时，可调用

/challenge-that

：

Claude未经过批判性评估就接受了提案
你想在做出承诺前对决策进行压力测试
需求看似未被充分审视
感觉有问题但无法明确表述原因

The Five Hats

五大视角

Each perspective challenges from a different angle:

Hat	Focus	Key Questions
🔴 Skeptic	Evidence & proof	"What evidence supports this? Has this been validated? Are we guessing?"
🟡 Pragmatist	Cost/benefit	"Is this the simplest fix? What's the maintenance burden? Is it worth it?"
🟢 Edge Case Hunter	Failure modes	"What breaks this? What's the worst case? What did we miss?"
🔵 Structural Critic	Architecture	"Is this the right location? Does it fit the existing design? Will it cause problems elsewhere?"
🟣 Root Cause Analyst	Problem diagnosis	"Is the problem correctly identified? Are we treating symptoms? What's the actual cause?"

每个视角从不同维度提出质疑：

视角	关注重点	核心问题
🔴 怀疑者	证据与证明	“有哪些证据支持这一方案？是否经过验证？我们是在猜测吗？”
🟡 实用主义者	成本收益	“这是最简单的解决方案吗？维护负担有多大？是否值得投入？”
🟢 极端情况猎手	失效模式	“什么会导致方案失效？最坏的情况是什么？我们遗漏了什么？”
🔵 结构批评者	架构适配	“这是合适的定位吗？是否契合现有设计？会在其他地方引发问题吗？”
🟣 根源分析师	问题诊断	“问题是否被正确识别？我们是在治标还是治本？真正的原因是什么？”

Behavior

运行机制

When

/challenge-that

is invoked:

Identify what was just accepted/proposed
State it clearly: "Challenging: [the proposal/decision]"
Analyze from each of the five perspectives
Synthesize into actionable concerns
Ask: "Which concerns should we address before proceeding?"

当调用

/challenge-that

时：

识别刚刚被接受或提出的内容
清晰表述：“质疑对象：[提案/决策内容]”
从五大视角逐一进行分析
整合为可落地的关注点
提问：“在推进之前，我们应该解决哪些关注点？”

Output Format

输出格式

undefined

undefined

Challenging: [proposal/decision being challenged]

质疑对象：[待质疑的提案/决策]

🔴 Skeptic

🔴 怀疑者

[Challenge from evidence/proof perspective]

[从证据与证明视角提出的质疑]

🟡 Pragmatist

🟡 实用主义者

[Challenge from cost/benefit perspective]

[从成本收益视角提出的质疑]

🟢 Edge Case Hunter

🟢 极端情况猎手

[Challenge from failure modes perspective]

[从失效模式视角提出的质疑]

🔵 Structural Critic

🔵 结构批评者

[Challenge from architecture perspective]

[从架构适配视角提出的质疑]

🟣 Root Cause Analyst

🟣 根源分析师

[Challenge from problem diagnosis perspective]

Key Concerns:

[Most significant concern]
[Second concern]
[Third concern]

Which of these should we address before proceeding?

undefined

[从问题诊断视角提出的质疑]

核心关注点：

[最关键的关注点]
[次要关注点]
[第三关注点]

在推进之前，我们应该解决哪些关注点？

undefined

Critical Rules

核心规则

🚨 Be genuinely adversarial. Don't softball the challenges. If a perspective finds nothing wrong, say so—but look hard first.

🚨 Challenge the proposal, not the person. Focus on the idea's weaknesses, not who suggested it.

🚨 Provide actionable output. Each challenge should point to something that could be investigated or changed.

🚨 保持真正的对抗性。不要弱化质疑力度。如果某个视角未发现问题，可如实说明，但需先深入排查。 🚨 针对提案而非个人。聚焦于方案的缺陷，而非提出者。 🚨 输出可落地内容。每一项质疑都应指向可调查或可改进的点。

Example

示例

User:

/challenge-that

Context: Claude just accepted a proposal to add edge case validation to TDD's GREEN state.

Output:

用户：

/challenge-that

上下文： Claude刚刚接受了一项在TDD的GREEN阶段添加极端情况验证的提案。

输出：

Challenging: Add edge case validation checklist to TDD GREEN state

质疑对象：在TDD的GREEN阶段添加极端情况验证清单

🔴 Skeptic

🔴 怀疑者

What evidence shows that GREEN state is the right location? The proposal assumes this will catch bugs, but has anyone tested whether developers actually use checklists at this stage? GREEN means "tests pass"—adding a review step here changes what GREEN means.

有哪些证据表明GREEN阶段是合适的定位？该提案假设这一举措能发现bug，但有没有人测试过开发者在这个阶段是否真的会使用清单？GREEN意味着“测试通过”——在此处添加审查步骤会改变GREEN阶段的定义。

🟡 Pragmatist

🟡 实用主义者

This adds friction to every TDD cycle. Is the bug frequency high enough to justify the overhead? The PR mentioned 3 bugs in one PR—is that representative or an outlier? What's the cost of false negatives (checklist fatigue)?

这会在每个TDD周期中增加流程阻力。当前的bug发生率是否足以证明这种额外开销是合理的？PR中提到某一个PR里出现了3个bug——这是普遍情况还是个例？出现清单疲劳导致的假阴性成本有多高？

🟢 Edge Case Hunter

🟢 极端情况猎手

What happens when the checklist reveals missing tests? There's no GREEN → PLANNING transition. The developer would need to either ignore the finding or break the state machine. This creates a dead end.

当清单发现缺失测试时会发生什么？当前没有GREEN→PLANNING的过渡流程。开发者要么忽略发现的问题，要么打破状态机，这会导致流程陷入死胡同。

🔵 Structural Critic

🔵 结构批评者

GREEN state is about code quality assessment, not test coverage. Test writing happens in PLANNING. This checklist belongs in PLANNING state where tests are actually written—not after they've already passed.

GREEN阶段的核心是代码质量评估，而非测试覆盖率。测试编写是在PLANNING阶段进行的。这份清单应该放在PLANNING阶段，也就是实际编写测试的环节——而非测试已经通过之后。