challenge

name	challenge
description	扮演方案的"反对方"，挑刺、找隐藏问题、戳过度自信的假设。/think 给出 plan 后强烈建议立刻跑一次 /challenge——让方案在落地前先经过一轮自我对抗。

/challenge · 让方案自己挑自己刺

使用场景

紧跟 /think 之后用：

• /think 已经给出 plan / 候选方案
• 准备进入实施前
• 任何"看起来挺顺理成章"的方案——越顺，越要 challenge

也可以在以下场景用：

• 别人给你看一份 spec / design 文档
• 你自己写完一段重要代码，想找潜在问题

目标

扮演反对方——不是为了否定方案，而是把所有"乐观假设"翻出来。Agent 默认会"顺着用户/前置 plan 走"，/challenge 是对抗这种倾向的工程手段。

一个好的 challenge 不在于找出多少问题，而在于问题是否致命——让你（或用户）能决定"知道这些问题后，还要不要这样走"。

必须步骤

1. 复述被挑战的方案

一两句话概括"我们要 challenge 的是什么"——确保你理解的方案和 plan 一致。

2. 列出至少 5 条质疑

按下面 4 个角度各出至少 1 条：

角度	问什么
🎯 目标	用户真的需要这个吗？还是只是"想到了"？砍掉这个功能用户会怎样？
🌪 边界 / 异常路径	失败 / 超时 / 空数据 / 重复请求 / 并发 / 用户中途关闭 时会怎样？
🔗 依赖	依赖的服务 / 库 / API 挂掉会怎样？依赖会不会变？谁来维护？
🏚 维护成本	半年后接手的人能看懂吗？要不要写文档？要不要写测试？运行时怎么发现问题？

3. 给每条质疑标严重度

• 🔴 致命：方案这样下去必然出问题，必须改
• 🟡 严重：高概率有问题，应该现在解决而不是 TODO
• 🟢 次要：可能有问题，可以接受、记 TODO 或留做下一阶段

4. 给每条质疑配具体场景

❌ "如果用户输入异常呢？" —— 太泛 ✅ "用户在 1 秒内连点 3 次提交按钮——POST /api/admin/regrade 现在没幂等保护，会触发 3 次并发重评，对 LLM 配额是浪费，对评分结果可能产生竞争"

5. 输出"如果接受当前方案，你必须接受什么"

不要只批评——总结：如果不改方案，必须知道哪些代价。这样用户能做知情决定。

禁止事项

• ❌ 不允许只列空泛的"安全 / 性能 / 可维护性"标题——必须给具体场景
• ❌ 不允许"为了挑刺而挑刺"——找不到致命/严重时如实承认
• ❌ 不允许把"我觉得不优雅" 当作严重问题
• ❌ 不允许直接重写方案——你的工作是挑刺，重写交回原方案的提出者

输出格式

## 被 challenge 的方案
（一两句话说明）

## 质疑清单

### 🔴 致命
1. **场景**：当 X 发生时
   **后果**：会触发 Y
   **建议**：必须先解决 Z

### 🟡 严重
2. ...

### 🟢 次要
3. ...

## 如果不改方案，你必须接受
- 接受 1：...
- 接受 2：...

## 总结
（一句话：方案可走 / 必须修 / 该重做）

与其他 Skill 的关系

• 通常在 /think 后立即跑——形成"我想 → 我挑自己刺 → 修正"的小循环
• 真正实施时配合 /small-diff 控制改动
• 找到的致命 / 严重问题在 /check 阶段必须验证已经处理
• 如果 challenge 出来的内容值得长期记住，用 /record-gotcha 写进 wiki