From red-team
对文章内容、技术方案、用户提问进行批判性红队审查,找出时效问题、逻辑漏洞、错误假设和幻觉引用。触发场景:用户说「红队」「挑战我的方案」「反驳一下」「质疑一下」「帮我找问题」「我说的有没有问题」「这个方案靠谱吗」「有没有更好的方案」,或提交文章/方案/技术设计请求审查时。支持三种模式:A内容审查(文章可靠性)、B方案审查(逻辑漏洞/安全问题)、C前提审查(挑战错误假设/认知偏差)。
How this skill is triggered — by the user, by Claude, or both
Slash command
/red-team:red-teamThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**模式 A / B(内容审查、方案审查):建议以 subagent 方式调用。**
模式 A / B(内容审查、方案审查):建议以 subagent 方式调用。 这两种模式需要大量 WebSearch,搜索结果会显著污染主 agent 的 context window。以 subagent 运行可保持主对话上下文干净,主 agent 只接收最终报告。
模式 C(前提审查):主 agent 可接受。 若审查以推理为主、无需多轮搜索,主 agent 直接执行不会产生明显熵增。
以下任意词触发,立即进入红队模式:
红队 / red team / redteam挑战我的方案 / 反驳一下 / 质疑一下帮我找问题 / 我说的有没有问题这个方案靠谱吗 / 有没有更好的方案根据上下文判断属于哪种模式:
模式 A:内容审查
用户提供了一篇文章、笔记、知识点,需要验证其可靠性
模式 B:方案审查
用户提供了 PRD、技术方案、Coding Plan、架构设计,需要找逻辑问题
模式 C:前提审查
用户的问题或陈述本身包含潜在错误假设,需要挑战用户的前提
三问的目的不是走流程,而是让分析建立在正确前提上。基于错误前提写出的反驳是双倍浪费。
如果用户已经提供了足够上下文,可以直接推断三问的答案——但推断结果必须写进输出,让用户可以纠正。格式见 Step 4 的「前置确认」区块。
如果缺少关键信息,先轻快地问,不要让用户感觉在填表:
"我先快速确认 3 件事,然后马上开始分析——[问题1]?[问题2]?[问题3]?"
根据模式选择检索策略:
必做:
WebSearch: "{核心主张} site:official-docs OR github.com"
WebSearch: "{核心主张} 2025 OR 2026"(查是否有更新版本)
WebSearch: "{核心主张} wrong OR outdated OR deprecated"(查是否已被推翻)
必做:
WebSearch: "{方案技术名} limitations OR pitfalls OR failure cases"
WebSearch: "{方案技术名} vs alternatives {当前年}"
WebFetch: 官方文档(验证 API / 功能是否真实存在)
可选(如涉及具体框架):
验证关键依赖的版本兼容性
检查是否有 known breaking changes
必做:
WebSearch: "{用户核心假设} consensus OR research"
WebSearch: "{用户方法论} better approach OR modern practice {当前年}"
如果涉及技术:检索是否已有官方反驳或社区共识
## 🔴 红队报告
### 审查模式
[A 内容审查 / B 方案审查 / C 前提审查]
### 前置确认
> 我基于以下理解展开分析,如有出入请纠正:
- **[三问问题1]**:[推断或用户回答]
- **[三问问题2]**:[推断或用户回答]
- **[三问问题3]**:[推断或用户回答]
### 被审查内容摘要
(1-2 句话总结用户的核心主张/方案/假设)
---
### 发现的问题
#### 问题 1:[问题标题]
**类型**:[逻辑错误 / 时效过期 / 幻觉引用 / 假设不成立 / 有更优方案]
**具体描述**:[详细说明问题在哪里]
**证据**:[来源 URL 或具体文档引用]
**影响**:[如果不修正会发生什么]
#### 问题 2:...
---
### 核心假设验证
| 假设 | 状态 | 说明 |
|------|------|------|
| [方案/内容的核心假设 1] | ✅ 成立 / ⚠️ 存疑 / ❌ 不成立 | 说明 |
| [假设 2] | ... | ... |
---
### 替代方案(如有)
> 仅在有证据支持更优方案时才列出,不列没有根据的建议
1. **[替代方案名]** — [一句话说明为何更好] → [参考链接]
---
### 总结判断
**整体评估**:[可用但需注意 X / 需要重做 Y 部分 / 前提有误建议重新思考 / 方案已过时建议调研 Z]
**最重要的一条修改建议**:(只说最重要的一条,不列清单)
| 失效类型 | 识别信号 |
|---|---|
| 时效过期 | 内容 > 1 年且涉及快速迭代的技术领域 |
| 来源不可靠 | 无原始来源 / 来自二手转述 / 作者身份不明 |
| 内部不一致 | 文章前后结论矛盾 / 示例与说明不符 / 数据和结论方向相反 |
| 社区分析误差 | 标注为「源码分析」但无具体行号/版本 |
| 以偏概全 | 基于特定场景得出普适性结论 |
| 失效类型 | 识别信号 |
|---|---|
| 幻觉引用 | 引用了不存在的 API / 已废弃的功能 |
| 空中楼阁 | 依赖「假设条件 X 成立」但未验证 X |
| 逻辑断层 | 步骤 2 的输出无法作为步骤 3 的输入 |
| 复杂度陷阱 | 用复杂方案解决了可以简单解决的问题 |
| 技术栈错配 | 方案和约束条件(团队能力/时间/成本)不匹配 |
| 失效类型 | 识别信号 |
|---|---|
| 过时理论 | 基于 > 2 年前的最佳实践,领域已发展 |
| 错误归因 | 把现象 A 的原因归结为 B,但实际是 C |
| 虚假二分 | 「只有 A 或 B」但实际还有 C、D |
| 工具崇拜 | 「用 X 就能解决」但忽略了 X 的适用前提 |
| 可用 ≠ 最优 | 方案可以工作,但存在显著更优的路径 |
| 确认偏误 | 只看支持自己结论的证据,忽略反例 |
| 幸存者偏差 | 「XX 公司用了成功」— 但失败的没曝光 |
| 权威诉诸 | 「大厂都这么做」— 但上下文完全不同 |
| 沉没成本 | 「已经投入了 X」— 作为继续的理由而非分析依据 |
每一条「证据」在写进报告前,必须通过以下检查:
| 证据类型 | 要求 |
|---|---|
| 官方文档链接 | 必须是真实 URL,用 WebFetch 验证页面存在且内容支持你的结论 |
| 统计数字(百分比/倍数) | 必须附带来源 URL,没有 URL 就不写这个数字 |
| CVE 编号 | 必须格式正确(CVE-YYYY-NNNNN),且与当前审查的漏洞类型直接相关 |
| 案例引用(如「亚马逊的做法」) | 必须能找到原始报道或官方博客链接 |
禁止写入报告的内容:
找不到 URL 时的处理方式: WebSearch 后仍无法找到原始来源 URL,使用以下格式标注,而非省略数字:
42% 的组织正在将微服务合并回更大的部署单元(来源:CNCF 2025 年度调查,URL 待验证)
正确示范:
"OWASP Session Management Cheat Sheet 要求 Session ID 至少 128 位熵 → https://cheatsheetseries.owasp.org/..."
错误示范:
"研究表明,42% 的组织已从微服务回迁单体" ← 无来源,禁止
"用户说的内容听起来合理" — 合理 ≠ 正确。运行检索。 "我觉得这个方案可行" — 觉得 ≠ 验证过。找证据。 "用户坚持这个方向" — 坚持 ≠ 对。保持立场,说明依据。 "找不到反驳证据" — 找不到 ≠ 没问题。标注为「暂未发现问题,建议关注 X 风险」。 "这个数字听起来真实" — 听起来真实 ≠ 可引用。先找来源再写。
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub gopherlinzy/skill-hub --plugin red-team