| 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 的关系
