Back to Details

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:
HatFocusKey Questions
🔴 SkepticEvidence & proof"What evidence supports this? Has this been validated? Are we guessing?"
🟡 PragmatistCost/benefit"Is this the simplest fix? What's the maintenance burden? Is it worth it?"
🟢 Edge Case HunterFailure modes"What breaks this? What's the worst case? What did we miss?"
🔵 Structural CriticArchitecture"Is this the right location? Does it fit the existing design? Will it cause problems elsewhere?"
🟣 Root Cause AnalystProblem diagnosis"Is the problem correctly identified? Are we treating symptoms? What's the actual cause?"
每个视角从不同维度提出质疑：
视角关注重点核心问题
🔴 怀疑者证据与证明“有哪些证据支持这一方案？是否经过验证？我们是在猜测吗？”
🟡 实用主义者成本收益“这是最简单的解决方案吗？维护负担有多大？是否值得投入？”
🟢 极端情况猎手失效模式“什么会导致方案失效？最坏的情况是什么？我们遗漏了什么？”
🔵 结构批评者架构适配“这是合适的定位吗？是否契合现有设计？会在其他地方引发问题吗？”
🟣 根源分析师问题诊断“问题是否被正确识别？我们是在治标还是治本？真正的原因是什么？”

Behavior

运行机制

When 
/challenge-that
is invoked:
  1. Identify what was just accepted/proposed
  2. State it clearly: "Challenging: [the proposal/decision]"
  3. Analyze from each of the five perspectives
  4. Synthesize into actionable concerns
  5. Ask: "Which concerns should we address before proceeding?"
当调用
/challenge-that
时：
  1. 识别刚刚被接受或提出的内容
  2. 清晰表述：“质疑对象：[提案/决策内容]”
  3. 从五大视角逐一进行分析
  4. 整合为可落地的关注点
  5. 提问：“在推进之前，我们应该解决哪些关注点？”

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:
  1. [Most significant concern]
  2. [Second concern]
  3. [Third concern]
Which of these should we address before proceeding?
undefined
[从问题诊断视角提出的质疑]
核心关注点：
  1. [最关键的关注点]
  2. [次要关注点]
  3. [第三关注点]
在推进之前，我们应该解决哪些关注点？
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阶段，也就是实际编写测试的环节——而非测试已经通过之后。

🟣 Root Cause Analyst

🟣 根源分析师

The actual problem was insufficient edge case consideration during test writing. The proposal treats the symptom (bugs shipped) not the cause (incomplete test planning). Moving this to PLANNING would address the root cause.
Key Concerns:
  1. GREEN is structurally the wrong location—no recovery path exists
  2. Root cause is in PLANNING, not GREEN
  3. No evidence this will be used effectively at GREEN stage
Which of these should we address before proceeding?
真正的问题是测试编写阶段对极端情况的考虑不足。该提案只是在处理症状（上线的bug），而非根源（测试规划不完整）。将清单移至PLANNING阶段才能解决根本问题。
核心关注点：
  1. GREEN阶段在结构上定位错误——没有对应的回退路径
  2. 问题根源在PLANNING阶段，而非GREEN阶段
  3. 没有证据表明在GREEN阶段使用该清单会有效
在推进之前，我们应该解决哪些关注点？