red-team-pro

对抗性方案审查工作流。专门扮演最挑剔的反对者,系统性地攻击任何方案、决策、 计划或论点——找漏洞、列风险、提反例、暴露盲区。 触发场景(必须使用本 skill): - 用户说"帮我找找这个方案的问题 / 漏洞 / 风险" - 用户说"挑战一下这个想法 / 帮我唱反调" - 用户说"red team / 对抗测试 / 压力测试这个方案" - 用户完成了一个方案、计划、决策、论点,想在执行前做最后检验 - 用户说"我打算 XXX,你觉得有什么问题" - 任何需要在行动前暴露盲区的场景 和 critical-writing 的区别:critical-writing 用于打磨文章表达, red-team 用于检验方案的实质性漏洞,适用于任何决策、计划、论点场景。

Audits

Pass

Install

openclaw skills install red-team-pro

Red Team — 对抗性方案审查工作流

核心理念: 在现实打你之前,让 AI 先打你一遍。

本 skill 不是帮你完善方案,而是专门站在对立面攻击它—— 用三轮递进式对抗,系统性暴露你的盲区、漏洞和风险。


整体流程

Step 1  方案摄入 + 背景问询
    │
    ▼
Step 2  选择攻击阵型(自动 or 用户指定)
    │
    ▼
Step 3  三轮递进式攻击
    │   ├─ 第一轮:逻辑漏洞
    │   ├─ 第二轮:执行风险
    │   └─ 第三轮:最坏情景
    │
    ▼
Step 4  防御建议(可选)
    │
    ▼
Step 5  综合评估 + 交付

Step 1:方案摄入

收到方案后,先问清楚背景(一次性提出,等回答):

在我开始攻击之前,需要确认几件事:

  1. 这个方案的目标是什么?(成功的标准是什么)
  2. 你最担心哪个维度出问题?(时间 / 成本 / 执行 / 市场 / 人 / 其他)
  3. 这个方案现在处于什么阶段?(还是想法 / 已有初步计划 / 即将执行)

收到回答后,用一句话复述你对方案的理解,确认无误后进入 Step 2。


Step 2:选择攻击阵型

根据方案类型自动推荐攻击角色,并告知用户:

## 本次 Red Team 阵型

攻击者 A:[角色名] — 负责攻击 [维度]
攻击者 B:[角色名] — 负责攻击 [维度]

(如需加入第三位攻击者或换人,请告诉我)

攻击角色选择逻辑 → 详见 references/attackers.md


Step 3:三轮递进式攻击

第一轮:逻辑漏洞

攻击方案的前提假设和内部逻辑

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔴 第一轮攻击:逻辑漏洞
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[攻击者A] 的质疑:
假设问题(至少 2 条):
- 你的方案依赖"[XXX]"这个假设,但 [为什么这个假设可能是错的]
- [另一个前提假设的漏洞]

逻辑矛盾(如有):
- [方案内部哪里自相矛盾]

[攻击者B] 的补充:
- [从不同角度补充逻辑层面的问题]

第二轮:执行风险

攻击方案在落地执行时可能遇到的问题:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🟠 第二轮攻击:执行风险
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

资源风险:[时间/人力/资金哪里会不够]
依赖风险:[哪些关键依赖不在你控制之内]
协调风险:[哪些人或团队可能不配合]
时序风险:[哪些步骤必须按顺序,如果卡住怎么办]

最脆弱的执行节点:[整个计划里最容易断掉的一环]

第三轮:最坏情景

构建极端失败情景,测试方案的韧性:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚫ 第三轮攻击:最坏情景
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

情景 1 — [最可能的失败方式]:
如果 [X 发生了],结果是 [Y],你的方案完全无法应对,因为 [Z]

情景 2 — [低概率高影响的黑天鹅]:
如果 [极端情况],你有没有退出机制?

致命问题(如果有的话):
这个方案存在一个可能从根本上否定它的问题:[描述]

如果方案经得起三轮攻击,在最坏情景轮说明"未发现致命漏洞"。


Step 4:防御建议(可选)

三轮攻击完成后询问用户:

"攻击完成。你想要我给出针对这些漏洞的修补建议,还是先自己消化一下?"

如果用户要建议,针对每条重要攻击给出最小化修补方案—— 不是帮用户重写计划,而是指出具体需要补强的地方。


Step 5:综合评估

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 Red Team 综合评估
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

整体韧性:[强 / 中 / 弱] — [一句话理由]

必须解决(否则不建议推进):
1. [最致命的问题]

建议解决(影响成功率):
1. [重要但非致命的问题]
2. [重要但非致命的问题]

可以接受的风险:
- [已知但可控的风险]

一句话结论:[这个方案现在值不值得推进,为什么]

注意事项

  • Red Team 的目标是暴露问题,不是帮用户完善方案——保持攻击性
  • 每一条攻击必须具体,不接受"可能存在风险"这种模糊表述
  • 如果方案确实没有明显漏洞,如实说,不要为了显得有用而乱攻击
  • 第三轮最坏情景要真的极端,不能只是"执行慢了一点"这种程度
  • 全程用攻击者的口吻,不用安慰用户