claude-skills 中的 The Fool用 5 种结构化推理模式对任何想法发起红队式挑战【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skillsThe Fool愚者是 claude-skills 仓库中一个与领域无关的结构化批判推理技能它根植于宫廷小丑是唯一敢向国王说真话的人这一原型以 5 种可切换的推理模式对想法、计划、架构与技术选型进行压力测试。本文以 docs/skill-ideas/the-fool.md 的设计计划为主线结合 skills/the-fool/SKILL.md 与 6 个参考文件的完整实现系统讲解其工作流、模式选择交互、各模式方法论与输出模板并给出与仓库验证脚本衔接的落地检查方式。读完本文你将掌握如何在 Claude Code 会话中用 play the fool 触发该技能对任何决策执行苏格拉底式提问、辩证法反方论证、灾前尸检、红队攻击与证据审计并最终得到一份强化后的决策结论。技能定位为什么需要一名愚者The Fool 的角色定义来自宫廷小丑的隐喻——唯一可以不受礼节、等级与政治束缚向国王说出真相的人。它不是天真幼稚的角色而是战略性地不受惯例、层级与客套约束的批判者使用 5 种结构化推理模式对任何想法、计划或决策进行压力测试。在 skills/the-fool/SKILL.md 的元数据中它的定位被精确定义为role: expert、scope: review、output-format: report、domain: workflow即一个评审范围的专家级报告型工作流技能。适用时机When to Use根据 skills/the-fool/SKILL.md 的When to Use This Skill一节在以下场景应主动调用在提交方案之前对计划、架构或策略进行压力测试挑战技术选型、供应商选择或方案路线评估商业提案、价值主张或策略在实现之前对设计进行红队演练审计证据是否真的支撑结论发现盲点与未言明的假设。从 SKILLS_GUIDE.md 的Critical Thinking批判性思维决策树可以看到它在整个技能体系中的位置Surface Assumptions表层假设→ Common Ground 命令Challenge Decisions挑战决策→ The FoolEvaluate Code评估代码→ Code ReviewerAudit Security安全审计→ Security Reviewer。也就是说The Fool 是决策挑战环节的指定工具与代码评审、安全审计形成互补而非重叠。触发机制与 Frontmatter 设计技能通过自然语言触发器在会话中途被有机调用play the fool 是强制触发器。原始设计文档 docs/skill-ideas/the-fool.md 列出的完整触发器集合为play the fool devils advocate challenge this stress test poke holes what could go wrong red team pre-mortem test my assumptions这些触发器在实现版本中完整落入 skills/the-fool/SKILL.md 的 frontmattermetadata.triggers。从仓库的验证逻辑看触发器不是可有可无的装饰在 scripts/validate-skills.py 中DescriptionFormatChecker强制要求技能的description必须包含 Use when 触发子句以便 Claude 在对话中自动识别调用时机MetadataFieldsChecker则要求triggers、role、scope、output-format、domain、related-skills全部存在且格式合法。这说明触发短语的设计直接决定了 Agent 能否在正确时机自动唤起技能。设计文档中的 frontmatter 计划与最终实现略有演进设计版将triggers放在顶层实现版skills/the-fool/SKILL.md将其归入metadata子结构并补充了license: MIT与metadata.author、metadata.version: 1.0.0与仓库现行的技能规范保持一致。核心工作流从论题到综合的五步闭环The Fool 的核心工作流固定为 5 步skills/the-fool/SKILL.md每一步都有明确的职责与产出约束Identify识别论题从对话上下文中提取用户的立场将其复述为一份钢人化steelmanned的论题并请求用户确认Select选择模式使用AskUserQuestion让用户选择推理模式或由技能根据上下文信号自动推荐Challenge发起挑战应用所选模式的方法加载对应的 reference 文件获取深度指引Engage引导对话展示 35 条最强挑战点在继续之前请用户回应Synthesize综合收敛把洞察整合为一份被强化的立场并主动提议用另一种模式进行第二轮检验。值得注意的是仓库的验证脚本对工作流步骤数有硬性约束CoreWorkflowStepCountCheckerscripts/validate-skills.py会解析 ## Core Workflow 一节并统计编号列表项期望值恰好为 5。这一校验体现了该仓库对技能结构规范化的追求——工作流的 5 步闭环不是随意设计而是被纳入自动化质量门槛的契约。最终输出必须包含的五要素无论选择哪种模式最终输出都要包含skills/the-fool/SKILL.mdSteelmanned thesis—— 用户立场的最强形式复述Challenges—— 所选模式下 35 条最强挑战点User response—— 为用户在综合前预留的回应空间Synthesis—— 整合挑战后得到强化的立场Next steps—— 如适用提议用另一模式进行第二轮检验。交互设计AskUserQuestions 驱动的两阶段模式选择设计文档明确提出模式选择必须通过AskUserQuestions完成绝不允许技能擅自假设模式也禁止在能用结构化选项时把模式选择输出为纯文本这一约束同时出现在 MUST DO 与 MUST NOT DO 中。设计版给出的是单题五选项Expose my assumptions / Argue the other side / Find the failure modes / Attack this / You choose而实现版在 skills/the-fool/SKILL.md 中演进为两步选择交互更轻第 1 步 —— 选择类别4 个选项选项描述Question assumptions探查被想当然的内容Build counter-arguments论证最强的对立立场Find weaknesses预判它如何失败或被利用You choose根据上下文自动推荐第 2 步 —— 精化模式仅当类别映射到 2 个模式时Question assumptions → 追问Expose my assumptions苏格拉底式 vs Test the evidence证伪式Find weaknesses → 追问Find failure modes灾前尸检 vs Attack this红队Build counter-arguments → 跳过第 2 步直接进入辩证法综合You choose → 跳过第 2 步加载 references/mode-selection-guide.md 自动推荐。这种两步式设计的精妙之处在于用户不需要在第一次提问时就理解全部 5 种方法论只需先表达意图我怀疑什么系统再在必要时做一对一的细化。这一交互模式在仓库中并非孤例——skills/feature-forge/SKILL.md 同样依赖AskUserQuestions进行结构化引导如用户类型、优先级的结构化选择并使用开放式问题作为补充设计文档也明确将 feature-forge 列为AskUserQuestions集成模式的参考对象。若用户选择 You choose技能将分析上下文信号后推荐 12 个模式并附理由再用一次AskUserQuestions确认。推荐的呈现格式references/mode-selection-guide.md为Based on [specific context signal], I recommend **[Mode Name]** because [1-sentence rationale]. [If a secondary mode is relevant:] After that, a follow-up with **[Secondary Mode]** would [1-sentence benefit].随后用AskUserQuestion确认选项 1 为推荐模式标注 (Recommended)选项 2 为次要模式选项 3 为 Let me pick返回完整模式选择。五大推理模式总览设计文档用一张表定义了 5 种模式及其方法与产出docs/skill-ideas/the-fool.md实现版在 skills/the-fool/SKILL.md 中完整保留模式方法产出Expose My Assumptions苏格拉底式提问按主题分组的探究性问题Argue the Other Side黑格尔辩证法 钢人化反方论证与综合提案Find the Failure Modes灾前尸检 二阶思维按优先级排序的失败叙事与缓解措施Attack This红队演练对手画像、攻击向量、防御方案Test the Evidence证伪主义 证据加权带证伪标准的声明审计每个模式对应一个 reference 文件通过参考路由表按需加载skills/the-fool/SKILL.md主题参考文件加载时机苏格拉底式提问references/socratic-questioning.md选择 Expose my assumptions辩证法与综合references/dialectic-synthesis.md选择 Argue the other side灾前尸检references/pre-mortem-analysis.md选择 Find the failure modes红队对抗references/red-team-adversarial.md选择 Attack this证据审计references/evidence-audit.md选择 Test the evidence模式选择指南references/mode-selection-guide.md选择 You choose 或需要自动推荐这种SKILL.md 定义流程 references/ 按需加载深度方法论的结构使主文件保持精简仓库对 SKILL.md 有 80100 非空行的长度约束见 scripts/validate-skills.py而各模式的方法论细节沉淀在独立的 reference 文件中。下文逐一展开各模式。模式一Expose My Assumptions —— 苏格拉底式提问苏格拉底式提问的核心原则是它不辩论它发问。目标是让用户通过自己被揭示的未审视之处自己发现推理中的缺口——每一问都应制造一个我从没想过这一点的瞬间references/socratic-questioning.md。五类问题框架类别核心模式示例定义性问题挑战含糊或过载的术语你说 可扩展指的是 10 倍用户还是 1000 倍证据性问题探查信念的根据什么证据表明用户真的想要这个功能逻辑性问题检验推理链条加了缓存就一定改善用户体验吗视角转换问题强制考虑他人视角负责值班的工程师会怎么看这个架构后果性问题追踪影响迁移之后第一个坏掉的东西是什么假设检测信号文献中总结了会隐藏假设的典型语言信号这是该模式最有操作价值的部分听到 Obviously...说话者没有质疑过、Everyone knows...共识未经核实、It just makes sense...推理链从未被言明、We always...历史模式被默认为最优、Theres no other way...备选方案未被探索、Its simple...复杂度被低估、Users want...用户研究可能缺失或过时、The standard approach is...惯例未针对当前情境验证时应立刻警觉背后存在未言明的假设。领域自适应题库与输出模板该模式为三类场景预置了问题库技术决策你在优化什么维度确定这是正确的维度吗哪个约束被你当作固定不变、实际却可松动、商业决策这个决策的客户是谁你确定吗和什么都不做相比如何、战略决策这个战略要成立必须满足什么条件哪些是失败前最后的退路信号。输出模板references/socratic-questioning.md分三部分Assumption Inventory假设清单标注类型 Stated/Unstated 与置信度 High/Medium/Low→Probing Questions按主题分组的问题如 User Behavior、Technical Feasibility、Business Viability→Suggested Experiments为最危险假设设计实验标注 Effort 与 Signal。模式二Argue the Other Side —— 辩证法与钢人化辩证法的核心原则是目的不是赢而是产出比论题或反题单独都更强的立场。愚者的职责是把对方立场论证得足够好迫使用户要么完善自己的立场要么承认一个真实的权衡references/dialectic-synthesis.md。钢人化技术Steel Manning钢人化是稻草人谬误的反面在反驳之前先把用户立场复述为最强形式。四步法为① 剥离薄弱表述提取核心主张我们应该用微服务 → 组件的独立部署与独立扩缩将加速团队交付速度② 补上用户隐含的最强证据③ 点明真实收益④ 与用户确认这个复述是否公平。配套的钢人化清单要求自检是否把立场变得更强而非更弱用户能否认出这是他的观点或更好是否包含对方的最强证据是否在攻击这个版本而非一个更易击破的版本反题构建与归谬法反题的构建秘诀是自问如果一位聪明且知情的人反对他最好的论点会是什么反题来源包括对立的权衡现在的速度 vs 未来的可维护性、隐藏成本迁移成本在 18 个月内超过预期收益、解决同一问题的替代方案模块化单体用 20% 的成本拿到 80% 的收益、同类先例某公司试过并在 2 年后回滚、以及论题未服务的利益相关者初级开发者会被新增复杂度难倒。**归谬法Reductio ad Absurdum**作为辅助技术把论题推向逻辑极端以揭示隐含边界——例如我们应该优化开发者体验归谬到那我们永远别上线了测试越多越好归谬到100% 覆盖率连 getter/setter 都覆盖。设计文档特别强调归谬要节制使用它揭示的是原则的边界而非原则的无效。五类综合模式Synthesis Patterns挑战完成后必须收敛出综合立场参考文件给出 5 种可复用的综合模式条件综合当条件 A 成立时 X 为真当条件 B 成立时 Y 为真。例支付服务适合微服务——独立扩缩与合规边界管理后台留在单体——低流量、快速迭代。范围切分X 应用于领域 AY 应用于领域 B。例审计追踪用事件溯源用户资料用标准 CRUD。时序综合先用 X当触发器 Z 出现时迁移到 Y。例先单体团队超过 3 个 squad 或部署频率出现每周冲突时再拆服务。风险缓解综合继续 X但加入来自 Y 的保障。例采用新框架但保留抽象层两个 sprint 内可换回。混合抽取从两侧各取最强要素。例采用微服务的部署模型——独立容器但保留共享数据库加 schema 所有权——避开分布式数据复杂度。置信度评估与反模式综合产出必须给出置信度评级HIGH综合明显强于任何单侧可执行、MEDIUM可行但未经验证找出最危险假设并设计实验、LOW双方都有强且不可调和的诉求明确命名真实权衡交由用户决策、PIVOT反题强于论题建议用户重新考虑原始立场。需警惕的五个反模式假综合两个都要却未解决张力、弱反题反题本身是稻草人、论题偏差综合可疑地接近原始立场、复杂度膨胀综合比任一原始方案更复杂、骑墙看情况却不说清看什么情况。模式三Find the Failure Modes —— 灾前尸检灾前尸检Pre-mortem颠覆提问方向不问这会成功吗而问六个月后这事已经失败了。为什么这个心理切换通过让失败成为起点而非待反驳的对象绕过了乐观偏差references/pre-mortem-analysis.md。六步流程设定场景——想象 [时间跨度] 后这个计划已经失败。不是小挫折是明确的失败。生成失败叙事——写具体的失败故事按可能性与影响排序——并非所有失败都等价追踪后果链——一阶 → 二阶 → 三阶效应识别早期预警信号——失败之前会看到什么设计缓解措施——具体行动而非模糊的小心点。失败叙事的构造标准失败叙事必须具体。它没扩展不是叙事而5 万并发用户时数据库连接池耗尽导致所有服务级联超时触发熔断器在高峰期的 4 分钟内拒绝全部请求才是。具体性清单要求命名具体触发器而非出了点事、包含数字或阈值、描述事件链而非仅终态、指明受影响者、确实可能发生。参考文件给出了标准叙事模板与完整示例其中最典型的迁移失败案例失败迁移数据丢失。3 个月后从 PostgreSQL 迁移到新 schema 的批处理任务静默丢弃了含特殊字符legacy_id的记录约 2%。团队在迁移 2 周后因客户报告订单历史缺失才发现问题此时旧库已退役、备份已轮换过迁移日期。根因迁移脚本只在剔除了特殊字符的清洗过的暂存数据集上测试过。二阶后果链每个失败的影响都超越直接冲击至少要追踪两层触发器关键工程师在迁移期间离职 → 一阶迁移时间表延误 4 周 → 二阶与旧系统并行期延长运营成本翻倍 → 三阶预算超支触发高管审查项目被缩减范围参考文件还列出了常见二阶模式如功能延期交付 → 销售错失季度目标 → 工程团队失去信任、被加强管控。反转技术与领域失败模式反转技术问什么能保证这个必然失败然后检查这些条件是否已存在——例如人的层面单点知识、无利益相关者认同、流程层面无回滚计划、全有或全无部署、技术层面未在目标规模测试、文档化缺失的依赖、版本锁定、时间线层面无未知缓冲、依赖无 SLA 的外部团队、数据层面无验证的迁移、无数据质量检查。参考文件为三个领域预置了失败模式库技术失败集成悬崖、规模惊讶、迁移陷阱、依赖腐烂、配置漂移、商业失败采用悬崖、竞争对手抢先、时机错配、利益相关者逆转、隐藏成本、流程失败时间线幻想、依赖链、知识孤岛、范围蔓延、反馈真空。同时给出了 7 条早期预警信号例如「我们以后再说」重复出现 3 次以上意味着关键决策在被拖延而非解决、没人能说清回滚计划意味着回滚从未被设计。模式四Attack This —— 红队对抗红队模式的核心问题是如果有人想破坏、利用或玩弄这个东西他会怎么做愚者采纳对手的心智——不是造成伤害而是在真实对手之前发现漏洞。其适用面超越安全领域竞争对手、心怀不满的用户、反常激励与监管挑战都是对抗力量references/red-team-adversarial.md。对手画像构建流程为识别资产 → 构建对手画像 → 映射攻击向量 → 按可能性 × 影响排序 → 为最高排名向量设计防御。参考文件强调泛泛的攻击者产生泛泛的发现具体的画像产生可操作的洞察。画像模板包含 Role / Motivation / Capability / Access / Constraints 五个字段。常见对手画像包括外部攻击者金钱或数据动机、竞争对手市场优势动机、心怀不满的内部人复仇动机、粗心用户非恶意、监管者合规动机、机会主义玩家薅羊毛、刷推荐返利、活动人士意识形态动机。参考文件还提供了领域特化画像电商平台的欺诈者支付绕过、优惠券滥用、虚假退货、SaaS 的免费层滥用者绕过限流、多开账号、囤积资源、API 平台的爬虫绕过限流、数据收割、逆向工程。攻击向量分类与攻击树攻击向量按六类组织技术类注入、认证绕过、竞态条件、SSRF、业务逻辑类流程绕过、状态篡改、价格篡改——如通过 API 重放应用过期优惠券、社会工程类钓鱼、假冒、权威利用、运营类供应链、依赖投毒、内部威胁、信息类数据泄露、元数据暴露、时序攻击——如通过登录错误消息做用户枚举、经济类资源耗尽、拒绝支付、不对称成本——如 Lambda 调用洪泛造成 5 万美元账单。对复杂系统构建攻击树来映射通往目标的路径。参考文件给出了窃取用户支付数据目标的攻击树示例路径 1 攻陷数据库搜索端点 SQL 注入 / 日志中环境变量凭证窃取 / 利用未修补的数据库 CVE路径 2 传输中拦截错误配置的 CDN 降级 TLS / 内部服务网格中间人路径 3 滥用应用逻辑导出功能访问控制不足 / 默认凭证的管理后台。反常激励检测与竞争响应系统创造激励有时激励会奖励错误行为。参考文件给出的检测问题是人们会怎么钻这个空子这个系统奖励了我们不想要的行为吗不付出努力就能拿到奖励的最便宜路径是什么如果我们衡量 X什么 Y 会被牺牲Goodhart 定律谁从这个失败中获益。典型的反常激励模式包括指标博弈以代码行数衡量生产力 → 冗长难维护的代码、奖励黑客无验证的推荐奖金 → 自建小号自荐、逐底竞争最快响应时间作为 SLA → 团队回避复杂工单、眼镜蛇效应为报 bug 发奖金 → 团队自己制造 bug 领赏。当对手是竞争者时参考文件提供了分析框架功能对等他们能复制什么多快我们的护城河是什么、价格战他们能维持低价吗成本结构如何、人才挖角哪些岗位关键可替代性如何、平台风险我们依赖他们的平台吗切换成本多高、FUD 运动他们可能提出什么主张哪些最难反驳。模式五Test the Evidence —— 证伪主义与证据审计证据审计建立在卡尔·波普尔的核心洞见上一个主张只有当你能指明什么会推翻它时才有意义。该模式从提案中抽取声明、设计证伪标准、评估证据质量并浮现竞争性解释——目的不是证伪而是确定证据是否真的支撑结论references/evidence-audit.md。声明抽取与证伪标准提案中的声明往往隐含。按类型可分为因果性X 导致 Y、预测性X 会发生、比较性X 比 Y 好、存在性X 存在/不存在、普遍性X 总是成立、定量性X 等于 N。抽取方法是对提案中的每个陈述依次回答这是声明还是定义若是声明属何类型引用了什么证据什么会使它为假证伪标准即为每个声明设计一个能推翻它的检验参考文件的示例包括声明用户想要功能 X→ 证伪标准30 天内参与率低于 10%→ 测试功能开关测量采用率声明这能扩展到 10 万用户→ 证伪标准5 万用户时响应时间超过 500ms→ 测试在目标规模做负载测试。同时要警惕不可证伪声明红旗信号模糊结果这会改善情况——无衡量标准、移动球门柱迟早会成——无时间边界、循环论证这是最好的因为专家推荐——证据即主张的复述、不可证伪的含糊在某些情况下可能有帮助——按定义恒真。遇到时应追问什么具体的、可衡量的结果能告诉我们这成没成证据质量矩阵与分级每个证据按六个维度评估样本量大而具代表性 vs 单案例/轶事、时效性12 个月内 vs 2 年以上、相关性同领域同规模 vs 不同领域规模、独立性多个独立来源 vs 单一来源或供应商提供、方法论受控可复现 vs 临时不可复现、具体性精确指标 vs 模糊定性。证据分级采用 A–F 量表A受控实验、大样本、可复现——高置信、B观察数据、合理样本、与其他证据一致——中等置信、C案例研究、小样本或单一来源——低置信需佐证、D轶事、观点或供应商营销材料——不足不能单独支撑决策、F未引用证据——主张无支撑。常见弱证据模式包括幸存者偏差用 X 的公司都成功了——忽略了失败者、挑选指标响应时间改善 40%——错误率、吞吐量可能恶化、供应商基准我们的工具快 3 倍——基准针对供应商优势优化、诉诸权威谷歌就这么干——谷歌的约束不是你的约束、锚定行业平均是 X我们在 Y——平均未必是正确的基准。认知偏差检查与竞争性解释参考文件列出八种需检查的认知偏差及其检测信号确认偏差只引用正面证据、幸存者偏差所有成功的公司都做 X、锚定首个估算被新数据刷新后仍不变、沉没成本谬误我们已经投入 6 个月了、可得性启发凭一个难忘事件做决策、从众效应人人都在做、达克效应在陌生领域过度自信、现状偏差一直如此。**竞争性解释溯因推理**要求对每个结论追问还有什么能解释这个证据——方法为陈述证据 → 陈述提出的解释 → 生成 23 个替代解释 → 比较解释力。参考文件示例证据采用工具 X 后部署失败率下降 50%提出的解释工具 X 更好替代解释包括同期团队开始了更多代码评审、上个月退役了一个特别易错的服务、团队积累的经验用任何工具都能改善结果。模式自动推荐模式选择指南的映射逻辑当用户选择 You choose 时references/mode-selection-guide.md 提供三套映射帮助技能自动推荐。信号→模式映射用户语言线索用户信号推荐模式理由这是正确的方法吗苏格拉底式探索假设尚未承诺我正打算敲定 X辩证法综合承诺前需要最强反方论证什么可能出错灾前尸检明确询问失败模式这安全吗红队安全与对抗框架数据显示……证据审计基于证据的主张需要证伪大家都同意……苏格拉底式共识信号 未检验的假设我们在 X 和 Y 中选了 X辩证法综合权衡决策需要最强反方这肯定能成灾前尸检过度自信需要失败想象没人会……红队关于对手行为的假设研究表明……证据审计引用的证据需要质量评估决策类型映射与领域映射决策类型映射给出主/次模式组合技术选型辩证法综合 灾前尸检、架构决策灾前尸检 红队、商业战略辩证法综合 证据审计、安全设计红队 灾前尸检、数据驱动结论证据审计 苏格拉底式、流程/工作流设计灾前尸检 苏格拉底式、供应商选择灾前尸检 辩证法综合。领域映射则给出各领域的默认模式安全红队、基础设施灾前尸检、数据/分析证据审计、产品/UX苏格拉底式、商业辩证法综合、架构灾前尸检、法律/合规证据审计。多模式串行与边界情况某些情境适合串行运行两种模式苏格拉底 → 辩证法想法未经验证先浮出假设再论证反方、灾前尸检 → 红队高风险系统上线先找内部失败再找外部攻击、证据审计 → 苏格拉底数据驱动提案先审计证据再质询解读、辩证法 → 灾前尸检战略决策先论证反方再压力测试存活立场。建议第二遍的条件是第一遍揭示了用户未考虑的风险类别、论题基本完好存活可能需要更难的检验、或领域横跨两个映射类别。不建议多模式的场景问题狭窄具体、第一遍已浮现可操作的变更、用户表示想继续前进。边界情况处理规则上下文含糊 → 默认苏格拉底式它让重要的事浮现出来多关注点 → 默认灾前尸检天然覆盖广度用户情绪化/沮丧 → 默认辩证法综合钢人化在挑战前先确认其立场技术与商业混杂 → 匹配用户强调的那一侧。纪律约束MUST DO 与 MUST NOT DO设计文档与实现版skills/the-fool/SKILL.md用两组约束定义该技能的纪律边界。MUST DO在挑战前先钢人化论题以最强形式复述用AskUserQuestion选择模式——绝不擅自假定模式把挑战建立在具体、确定的推理上而非含糊的如果……保持智识诚实——经得起检验的观点要承认驱动向综合或可操作输出收敛绝不只留反对意见挑战深度适配领域与风险等级只保留 35 条最强挑战点深度优先于广度在综合之前要求用户参与回应。MUST NOT DO稻草人化用户的立场为反对而反对虚无主义或纯粹破坏堆砌小反对意见制造虚假的脆弱印象跳过综合绝不只丢给用户一堆问题用泛泛的怀疑覆盖领域专长在AskUserQuestion能提供结构化选项时把模式选择输出为纯文本。在技能生态中的协作定位设计文档明确给出了 The Fool 的上下游协作关系skills/the-fool/SKILL.md 的related-skills元数据与之一致Common Groundcommands/common-ground/COMMAND.md—— 浮现隐藏假设应在The Fool 之前使用。它是以交互式多阶段对话为模式的命令级技能恰好承接先浮出假设、再发起挑战的链路Architecture Designer—— 将精化后的决策记录为 ADR应在The Fool 之后使用Code Reviewer—— 对实现的结构化评审是战术层面的对应技能Feature Forge—— 需求获取规范应在锻造之后再由 The Fool 挑战。在 SKILLS_GUIDE.md 中这一协作被固化为Decision Validation决策验证组合流程Common Ground浮现假设→ The Fool压力测试决策→ Architecture Designer记录精化决策。工程质量与验证技能如何通过自动化检查作为一份设计文档docs/skill-ideas/the-fool.md 在 Verification 一节给出了实现后的验收标准这些标准与仓库脚本一一对应python scripts/validate-skills.py --skill the-fool—— 验证 YAML、描述格式与 references 引用。该脚本实现了完整的检查器体系scripts/validate-skills.pyYamlChecker校验 frontmatter 可解析RequiredFieldsChecker要求name、description存在DescriptionFormatChecker要求描述含 Use when 触发子句MetadataFieldsChecker要求triggers、role、scope、output-format、domain、related-skills齐全并校验相关技能引用是否存在ReferencesDirectoryChecker与ReferenceFileCountChecker校验references/目录存在且至少含 1 个参考文件NonStandardHeadersChecker检查参考文件头部是否残留过时的 Reference for: / Load when: 头ReferencePathChecker会逐一解析技能文件正文中以反引号或 Markdown 链接引用的.md路径确保其能相对包含文件或技能根目录解析成功python scripts/update-docs.py --check—— 验证技能计数同步手动验证触发短语与自然调用模式匹配审查每个参考文件保持在 100600 行范围内。设计文档中的 Implementation Order先建 SKILL.md再依次创建 6 个参考文件最后更新 SKILLS_GUIDE.md在仓库中已全部完成且实现严格遵循了参考文件 100600 行的设计约束——这正是该仓库把设计文档 → 实现 → 自动化验证作为闭环流程的体现。小结The Fool 是 claude-skills 中一个设计精良、实现完整的批判性推理技能以 play the fool 为强制触发点通过AskUserQuestion两阶段交互选择模式用苏格拉底提问、辩证法综合、灾前尸检、红队对抗、证据审计五种方法论对任意想法进行结构化压力测试最终收敛为带置信度评估的综合结论。它的价值不仅在于找茬更在于纪律——钢人化、具体化、克制化、收敛化的挑战配合 SKILLS_GUIDE.md 中的 Critical Thinking 决策树与 Decision Validation 组合流程可以在决策提交之前把盲点、假设与脆弱点系统性地暴露出来。对于任何希望让 Claude Code 扮演敢于说真话的诤友的开发者深入阅读 skills/the-fool/SKILL.md 及其 6 个参考文件是掌握这套方法论最直接的路径。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 claude-skills 中的 The Fool：用 5 种结构化推理模式对任何想法发起红队式挑战
claude-skills 中的 The Fool用 5 种结构化推理模式对任何想法发起红队式挑战【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skillsThe Fool愚者是 claude-skills 仓库中一个与领域无关的结构化批判推理技能它根植于宫廷小丑是唯一敢向国王说真话的人这一原型以 5 种可切换的推理模式对想法、计划、架构与技术选型进行压力测试。本文以 docs/skill-ideas/the-fool.md 的设计计划为主线结合 skills/the-fool/SKILL.md 与 6 个参考文件的完整实现系统讲解其工作流、模式选择交互、各模式方法论与输出模板并给出与仓库验证脚本衔接的落地检查方式。读完本文你将掌握如何在 Claude Code 会话中用 play the fool 触发该技能对任何决策执行苏格拉底式提问、辩证法反方论证、灾前尸检、红队攻击与证据审计并最终得到一份强化后的决策结论。技能定位为什么需要一名愚者The Fool 的角色定义来自宫廷小丑的隐喻——唯一可以不受礼节、等级与政治束缚向国王说出真相的人。它不是天真幼稚的角色而是战略性地不受惯例、层级与客套约束的批判者使用 5 种结构化推理模式对任何想法、计划或决策进行压力测试。在 skills/the-fool/SKILL.md 的元数据中它的定位被精确定义为role: expert、scope: review、output-format: report、domain: workflow即一个评审范围的专家级报告型工作流技能。适用时机When to Use根据 skills/the-fool/SKILL.md 的When to Use This Skill一节在以下场景应主动调用在提交方案之前对计划、架构或策略进行压力测试挑战技术选型、供应商选择或方案路线评估商业提案、价值主张或策略在实现之前对设计进行红队演练审计证据是否真的支撑结论发现盲点与未言明的假设。从 SKILLS_GUIDE.md 的Critical Thinking批判性思维决策树可以看到它在整个技能体系中的位置Surface Assumptions表层假设→ Common Ground 命令Challenge Decisions挑战决策→ The FoolEvaluate Code评估代码→ Code ReviewerAudit Security安全审计→ Security Reviewer。也就是说The Fool 是决策挑战环节的指定工具与代码评审、安全审计形成互补而非重叠。触发机制与 Frontmatter 设计技能通过自然语言触发器在会话中途被有机调用play the fool 是强制触发器。原始设计文档 docs/skill-ideas/the-fool.md 列出的完整触发器集合为play the fool devils advocate challenge this stress test poke holes what could go wrong red team pre-mortem test my assumptions这些触发器在实现版本中完整落入 skills/the-fool/SKILL.md 的 frontmattermetadata.triggers。从仓库的验证逻辑看触发器不是可有可无的装饰在 scripts/validate-skills.py 中DescriptionFormatChecker强制要求技能的description必须包含 Use when 触发子句以便 Claude 在对话中自动识别调用时机MetadataFieldsChecker则要求triggers、role、scope、output-format、domain、related-skills全部存在且格式合法。这说明触发短语的设计直接决定了 Agent 能否在正确时机自动唤起技能。设计文档中的 frontmatter 计划与最终实现略有演进设计版将triggers放在顶层实现版skills/the-fool/SKILL.md将其归入metadata子结构并补充了license: MIT与metadata.author、metadata.version: 1.0.0与仓库现行的技能规范保持一致。核心工作流从论题到综合的五步闭环The Fool 的核心工作流固定为 5 步skills/the-fool/SKILL.md每一步都有明确的职责与产出约束Identify识别论题从对话上下文中提取用户的立场将其复述为一份钢人化steelmanned的论题并请求用户确认Select选择模式使用AskUserQuestion让用户选择推理模式或由技能根据上下文信号自动推荐Challenge发起挑战应用所选模式的方法加载对应的 reference 文件获取深度指引Engage引导对话展示 35 条最强挑战点在继续之前请用户回应Synthesize综合收敛把洞察整合为一份被强化的立场并主动提议用另一种模式进行第二轮检验。值得注意的是仓库的验证脚本对工作流步骤数有硬性约束CoreWorkflowStepCountCheckerscripts/validate-skills.py会解析 ## Core Workflow 一节并统计编号列表项期望值恰好为 5。这一校验体现了该仓库对技能结构规范化的追求——工作流的 5 步闭环不是随意设计而是被纳入自动化质量门槛的契约。最终输出必须包含的五要素无论选择哪种模式最终输出都要包含skills/the-fool/SKILL.mdSteelmanned thesis—— 用户立场的最强形式复述Challenges—— 所选模式下 35 条最强挑战点User response—— 为用户在综合前预留的回应空间Synthesis—— 整合挑战后得到强化的立场Next steps—— 如适用提议用另一模式进行第二轮检验。交互设计AskUserQuestions 驱动的两阶段模式选择设计文档明确提出模式选择必须通过AskUserQuestions完成绝不允许技能擅自假设模式也禁止在能用结构化选项时把模式选择输出为纯文本这一约束同时出现在 MUST DO 与 MUST NOT DO 中。设计版给出的是单题五选项Expose my assumptions / Argue the other side / Find the failure modes / Attack this / You choose而实现版在 skills/the-fool/SKILL.md 中演进为两步选择交互更轻第 1 步 —— 选择类别4 个选项选项描述Question assumptions探查被想当然的内容Build counter-arguments论证最强的对立立场Find weaknesses预判它如何失败或被利用You choose根据上下文自动推荐第 2 步 —— 精化模式仅当类别映射到 2 个模式时Question assumptions → 追问Expose my assumptions苏格拉底式 vs Test the evidence证伪式Find weaknesses → 追问Find failure modes灾前尸检 vs Attack this红队Build counter-arguments → 跳过第 2 步直接进入辩证法综合You choose → 跳过第 2 步加载 references/mode-selection-guide.md 自动推荐。这种两步式设计的精妙之处在于用户不需要在第一次提问时就理解全部 5 种方法论只需先表达意图我怀疑什么系统再在必要时做一对一的细化。这一交互模式在仓库中并非孤例——skills/feature-forge/SKILL.md 同样依赖AskUserQuestions进行结构化引导如用户类型、优先级的结构化选择并使用开放式问题作为补充设计文档也明确将 feature-forge 列为AskUserQuestions集成模式的参考对象。若用户选择 You choose技能将分析上下文信号后推荐 12 个模式并附理由再用一次AskUserQuestions确认。推荐的呈现格式references/mode-selection-guide.md为Based on [specific context signal], I recommend **[Mode Name]** because [1-sentence rationale]. [If a secondary mode is relevant:] After that, a follow-up with **[Secondary Mode]** would [1-sentence benefit].随后用AskUserQuestion确认选项 1 为推荐模式标注 (Recommended)选项 2 为次要模式选项 3 为 Let me pick返回完整模式选择。五大推理模式总览设计文档用一张表定义了 5 种模式及其方法与产出docs/skill-ideas/the-fool.md实现版在 skills/the-fool/SKILL.md 中完整保留模式方法产出Expose My Assumptions苏格拉底式提问按主题分组的探究性问题Argue the Other Side黑格尔辩证法 钢人化反方论证与综合提案Find the Failure Modes灾前尸检 二阶思维按优先级排序的失败叙事与缓解措施Attack This红队演练对手画像、攻击向量、防御方案Test the Evidence证伪主义 证据加权带证伪标准的声明审计每个模式对应一个 reference 文件通过参考路由表按需加载skills/the-fool/SKILL.md主题参考文件加载时机苏格拉底式提问references/socratic-questioning.md选择 Expose my assumptions辩证法与综合references/dialectic-synthesis.md选择 Argue the other side灾前尸检references/pre-mortem-analysis.md选择 Find the failure modes红队对抗references/red-team-adversarial.md选择 Attack this证据审计references/evidence-audit.md选择 Test the evidence模式选择指南references/mode-selection-guide.md选择 You choose 或需要自动推荐这种SKILL.md 定义流程 references/ 按需加载深度方法论的结构使主文件保持精简仓库对 SKILL.md 有 80100 非空行的长度约束见 scripts/validate-skills.py而各模式的方法论细节沉淀在独立的 reference 文件中。下文逐一展开各模式。模式一Expose My Assumptions —— 苏格拉底式提问苏格拉底式提问的核心原则是它不辩论它发问。目标是让用户通过自己被揭示的未审视之处自己发现推理中的缺口——每一问都应制造一个我从没想过这一点的瞬间references/socratic-questioning.md。五类问题框架类别核心模式示例定义性问题挑战含糊或过载的术语你说 可扩展指的是 10 倍用户还是 1000 倍证据性问题探查信念的根据什么证据表明用户真的想要这个功能逻辑性问题检验推理链条加了缓存就一定改善用户体验吗视角转换问题强制考虑他人视角负责值班的工程师会怎么看这个架构后果性问题追踪影响迁移之后第一个坏掉的东西是什么假设检测信号文献中总结了会隐藏假设的典型语言信号这是该模式最有操作价值的部分听到 Obviously...说话者没有质疑过、Everyone knows...共识未经核实、It just makes sense...推理链从未被言明、We always...历史模式被默认为最优、Theres no other way...备选方案未被探索、Its simple...复杂度被低估、Users want...用户研究可能缺失或过时、The standard approach is...惯例未针对当前情境验证时应立刻警觉背后存在未言明的假设。领域自适应题库与输出模板该模式为三类场景预置了问题库技术决策你在优化什么维度确定这是正确的维度吗哪个约束被你当作固定不变、实际却可松动、商业决策这个决策的客户是谁你确定吗和什么都不做相比如何、战略决策这个战略要成立必须满足什么条件哪些是失败前最后的退路信号。输出模板references/socratic-questioning.md分三部分Assumption Inventory假设清单标注类型 Stated/Unstated 与置信度 High/Medium/Low→Probing Questions按主题分组的问题如 User Behavior、Technical Feasibility、Business Viability→Suggested Experiments为最危险假设设计实验标注 Effort 与 Signal。模式二Argue the Other Side —— 辩证法与钢人化辩证法的核心原则是目的不是赢而是产出比论题或反题单独都更强的立场。愚者的职责是把对方立场论证得足够好迫使用户要么完善自己的立场要么承认一个真实的权衡references/dialectic-synthesis.md。钢人化技术Steel Manning钢人化是稻草人谬误的反面在反驳之前先把用户立场复述为最强形式。四步法为① 剥离薄弱表述提取核心主张我们应该用微服务 → 组件的独立部署与独立扩缩将加速团队交付速度② 补上用户隐含的最强证据③ 点明真实收益④ 与用户确认这个复述是否公平。配套的钢人化清单要求自检是否把立场变得更强而非更弱用户能否认出这是他的观点或更好是否包含对方的最强证据是否在攻击这个版本而非一个更易击破的版本反题构建与归谬法反题的构建秘诀是自问如果一位聪明且知情的人反对他最好的论点会是什么反题来源包括对立的权衡现在的速度 vs 未来的可维护性、隐藏成本迁移成本在 18 个月内超过预期收益、解决同一问题的替代方案模块化单体用 20% 的成本拿到 80% 的收益、同类先例某公司试过并在 2 年后回滚、以及论题未服务的利益相关者初级开发者会被新增复杂度难倒。**归谬法Reductio ad Absurdum**作为辅助技术把论题推向逻辑极端以揭示隐含边界——例如我们应该优化开发者体验归谬到那我们永远别上线了测试越多越好归谬到100% 覆盖率连 getter/setter 都覆盖。设计文档特别强调归谬要节制使用它揭示的是原则的边界而非原则的无效。五类综合模式Synthesis Patterns挑战完成后必须收敛出综合立场参考文件给出 5 种可复用的综合模式条件综合当条件 A 成立时 X 为真当条件 B 成立时 Y 为真。例支付服务适合微服务——独立扩缩与合规边界管理后台留在单体——低流量、快速迭代。范围切分X 应用于领域 AY 应用于领域 B。例审计追踪用事件溯源用户资料用标准 CRUD。时序综合先用 X当触发器 Z 出现时迁移到 Y。例先单体团队超过 3 个 squad 或部署频率出现每周冲突时再拆服务。风险缓解综合继续 X但加入来自 Y 的保障。例采用新框架但保留抽象层两个 sprint 内可换回。混合抽取从两侧各取最强要素。例采用微服务的部署模型——独立容器但保留共享数据库加 schema 所有权——避开分布式数据复杂度。置信度评估与反模式综合产出必须给出置信度评级HIGH综合明显强于任何单侧可执行、MEDIUM可行但未经验证找出最危险假设并设计实验、LOW双方都有强且不可调和的诉求明确命名真实权衡交由用户决策、PIVOT反题强于论题建议用户重新考虑原始立场。需警惕的五个反模式假综合两个都要却未解决张力、弱反题反题本身是稻草人、论题偏差综合可疑地接近原始立场、复杂度膨胀综合比任一原始方案更复杂、骑墙看情况却不说清看什么情况。模式三Find the Failure Modes —— 灾前尸检灾前尸检Pre-mortem颠覆提问方向不问这会成功吗而问六个月后这事已经失败了。为什么这个心理切换通过让失败成为起点而非待反驳的对象绕过了乐观偏差references/pre-mortem-analysis.md。六步流程设定场景——想象 [时间跨度] 后这个计划已经失败。不是小挫折是明确的失败。生成失败叙事——写具体的失败故事按可能性与影响排序——并非所有失败都等价追踪后果链——一阶 → 二阶 → 三阶效应识别早期预警信号——失败之前会看到什么设计缓解措施——具体行动而非模糊的小心点。失败叙事的构造标准失败叙事必须具体。它没扩展不是叙事而5 万并发用户时数据库连接池耗尽导致所有服务级联超时触发熔断器在高峰期的 4 分钟内拒绝全部请求才是。具体性清单要求命名具体触发器而非出了点事、包含数字或阈值、描述事件链而非仅终态、指明受影响者、确实可能发生。参考文件给出了标准叙事模板与完整示例其中最典型的迁移失败案例失败迁移数据丢失。3 个月后从 PostgreSQL 迁移到新 schema 的批处理任务静默丢弃了含特殊字符legacy_id的记录约 2%。团队在迁移 2 周后因客户报告订单历史缺失才发现问题此时旧库已退役、备份已轮换过迁移日期。根因迁移脚本只在剔除了特殊字符的清洗过的暂存数据集上测试过。二阶后果链每个失败的影响都超越直接冲击至少要追踪两层触发器关键工程师在迁移期间离职 → 一阶迁移时间表延误 4 周 → 二阶与旧系统并行期延长运营成本翻倍 → 三阶预算超支触发高管审查项目被缩减范围参考文件还列出了常见二阶模式如功能延期交付 → 销售错失季度目标 → 工程团队失去信任、被加强管控。反转技术与领域失败模式反转技术问什么能保证这个必然失败然后检查这些条件是否已存在——例如人的层面单点知识、无利益相关者认同、流程层面无回滚计划、全有或全无部署、技术层面未在目标规模测试、文档化缺失的依赖、版本锁定、时间线层面无未知缓冲、依赖无 SLA 的外部团队、数据层面无验证的迁移、无数据质量检查。参考文件为三个领域预置了失败模式库技术失败集成悬崖、规模惊讶、迁移陷阱、依赖腐烂、配置漂移、商业失败采用悬崖、竞争对手抢先、时机错配、利益相关者逆转、隐藏成本、流程失败时间线幻想、依赖链、知识孤岛、范围蔓延、反馈真空。同时给出了 7 条早期预警信号例如「我们以后再说」重复出现 3 次以上意味着关键决策在被拖延而非解决、没人能说清回滚计划意味着回滚从未被设计。模式四Attack This —— 红队对抗红队模式的核心问题是如果有人想破坏、利用或玩弄这个东西他会怎么做愚者采纳对手的心智——不是造成伤害而是在真实对手之前发现漏洞。其适用面超越安全领域竞争对手、心怀不满的用户、反常激励与监管挑战都是对抗力量references/red-team-adversarial.md。对手画像构建流程为识别资产 → 构建对手画像 → 映射攻击向量 → 按可能性 × 影响排序 → 为最高排名向量设计防御。参考文件强调泛泛的攻击者产生泛泛的发现具体的画像产生可操作的洞察。画像模板包含 Role / Motivation / Capability / Access / Constraints 五个字段。常见对手画像包括外部攻击者金钱或数据动机、竞争对手市场优势动机、心怀不满的内部人复仇动机、粗心用户非恶意、监管者合规动机、机会主义玩家薅羊毛、刷推荐返利、活动人士意识形态动机。参考文件还提供了领域特化画像电商平台的欺诈者支付绕过、优惠券滥用、虚假退货、SaaS 的免费层滥用者绕过限流、多开账号、囤积资源、API 平台的爬虫绕过限流、数据收割、逆向工程。攻击向量分类与攻击树攻击向量按六类组织技术类注入、认证绕过、竞态条件、SSRF、业务逻辑类流程绕过、状态篡改、价格篡改——如通过 API 重放应用过期优惠券、社会工程类钓鱼、假冒、权威利用、运营类供应链、依赖投毒、内部威胁、信息类数据泄露、元数据暴露、时序攻击——如通过登录错误消息做用户枚举、经济类资源耗尽、拒绝支付、不对称成本——如 Lambda 调用洪泛造成 5 万美元账单。对复杂系统构建攻击树来映射通往目标的路径。参考文件给出了窃取用户支付数据目标的攻击树示例路径 1 攻陷数据库搜索端点 SQL 注入 / 日志中环境变量凭证窃取 / 利用未修补的数据库 CVE路径 2 传输中拦截错误配置的 CDN 降级 TLS / 内部服务网格中间人路径 3 滥用应用逻辑导出功能访问控制不足 / 默认凭证的管理后台。反常激励检测与竞争响应系统创造激励有时激励会奖励错误行为。参考文件给出的检测问题是人们会怎么钻这个空子这个系统奖励了我们不想要的行为吗不付出努力就能拿到奖励的最便宜路径是什么如果我们衡量 X什么 Y 会被牺牲Goodhart 定律谁从这个失败中获益。典型的反常激励模式包括指标博弈以代码行数衡量生产力 → 冗长难维护的代码、奖励黑客无验证的推荐奖金 → 自建小号自荐、逐底竞争最快响应时间作为 SLA → 团队回避复杂工单、眼镜蛇效应为报 bug 发奖金 → 团队自己制造 bug 领赏。当对手是竞争者时参考文件提供了分析框架功能对等他们能复制什么多快我们的护城河是什么、价格战他们能维持低价吗成本结构如何、人才挖角哪些岗位关键可替代性如何、平台风险我们依赖他们的平台吗切换成本多高、FUD 运动他们可能提出什么主张哪些最难反驳。模式五Test the Evidence —— 证伪主义与证据审计证据审计建立在卡尔·波普尔的核心洞见上一个主张只有当你能指明什么会推翻它时才有意义。该模式从提案中抽取声明、设计证伪标准、评估证据质量并浮现竞争性解释——目的不是证伪而是确定证据是否真的支撑结论references/evidence-audit.md。声明抽取与证伪标准提案中的声明往往隐含。按类型可分为因果性X 导致 Y、预测性X 会发生、比较性X 比 Y 好、存在性X 存在/不存在、普遍性X 总是成立、定量性X 等于 N。抽取方法是对提案中的每个陈述依次回答这是声明还是定义若是声明属何类型引用了什么证据什么会使它为假证伪标准即为每个声明设计一个能推翻它的检验参考文件的示例包括声明用户想要功能 X→ 证伪标准30 天内参与率低于 10%→ 测试功能开关测量采用率声明这能扩展到 10 万用户→ 证伪标准5 万用户时响应时间超过 500ms→ 测试在目标规模做负载测试。同时要警惕不可证伪声明红旗信号模糊结果这会改善情况——无衡量标准、移动球门柱迟早会成——无时间边界、循环论证这是最好的因为专家推荐——证据即主张的复述、不可证伪的含糊在某些情况下可能有帮助——按定义恒真。遇到时应追问什么具体的、可衡量的结果能告诉我们这成没成证据质量矩阵与分级每个证据按六个维度评估样本量大而具代表性 vs 单案例/轶事、时效性12 个月内 vs 2 年以上、相关性同领域同规模 vs 不同领域规模、独立性多个独立来源 vs 单一来源或供应商提供、方法论受控可复现 vs 临时不可复现、具体性精确指标 vs 模糊定性。证据分级采用 A–F 量表A受控实验、大样本、可复现——高置信、B观察数据、合理样本、与其他证据一致——中等置信、C案例研究、小样本或单一来源——低置信需佐证、D轶事、观点或供应商营销材料——不足不能单独支撑决策、F未引用证据——主张无支撑。常见弱证据模式包括幸存者偏差用 X 的公司都成功了——忽略了失败者、挑选指标响应时间改善 40%——错误率、吞吐量可能恶化、供应商基准我们的工具快 3 倍——基准针对供应商优势优化、诉诸权威谷歌就这么干——谷歌的约束不是你的约束、锚定行业平均是 X我们在 Y——平均未必是正确的基准。认知偏差检查与竞争性解释参考文件列出八种需检查的认知偏差及其检测信号确认偏差只引用正面证据、幸存者偏差所有成功的公司都做 X、锚定首个估算被新数据刷新后仍不变、沉没成本谬误我们已经投入 6 个月了、可得性启发凭一个难忘事件做决策、从众效应人人都在做、达克效应在陌生领域过度自信、现状偏差一直如此。**竞争性解释溯因推理**要求对每个结论追问还有什么能解释这个证据——方法为陈述证据 → 陈述提出的解释 → 生成 23 个替代解释 → 比较解释力。参考文件示例证据采用工具 X 后部署失败率下降 50%提出的解释工具 X 更好替代解释包括同期团队开始了更多代码评审、上个月退役了一个特别易错的服务、团队积累的经验用任何工具都能改善结果。模式自动推荐模式选择指南的映射逻辑当用户选择 You choose 时references/mode-selection-guide.md 提供三套映射帮助技能自动推荐。信号→模式映射用户语言线索用户信号推荐模式理由这是正确的方法吗苏格拉底式探索假设尚未承诺我正打算敲定 X辩证法综合承诺前需要最强反方论证什么可能出错灾前尸检明确询问失败模式这安全吗红队安全与对抗框架数据显示……证据审计基于证据的主张需要证伪大家都同意……苏格拉底式共识信号 未检验的假设我们在 X 和 Y 中选了 X辩证法综合权衡决策需要最强反方这肯定能成灾前尸检过度自信需要失败想象没人会……红队关于对手行为的假设研究表明……证据审计引用的证据需要质量评估决策类型映射与领域映射决策类型映射给出主/次模式组合技术选型辩证法综合 灾前尸检、架构决策灾前尸检 红队、商业战略辩证法综合 证据审计、安全设计红队 灾前尸检、数据驱动结论证据审计 苏格拉底式、流程/工作流设计灾前尸检 苏格拉底式、供应商选择灾前尸检 辩证法综合。领域映射则给出各领域的默认模式安全红队、基础设施灾前尸检、数据/分析证据审计、产品/UX苏格拉底式、商业辩证法综合、架构灾前尸检、法律/合规证据审计。多模式串行与边界情况某些情境适合串行运行两种模式苏格拉底 → 辩证法想法未经验证先浮出假设再论证反方、灾前尸检 → 红队高风险系统上线先找内部失败再找外部攻击、证据审计 → 苏格拉底数据驱动提案先审计证据再质询解读、辩证法 → 灾前尸检战略决策先论证反方再压力测试存活立场。建议第二遍的条件是第一遍揭示了用户未考虑的风险类别、论题基本完好存活可能需要更难的检验、或领域横跨两个映射类别。不建议多模式的场景问题狭窄具体、第一遍已浮现可操作的变更、用户表示想继续前进。边界情况处理规则上下文含糊 → 默认苏格拉底式它让重要的事浮现出来多关注点 → 默认灾前尸检天然覆盖广度用户情绪化/沮丧 → 默认辩证法综合钢人化在挑战前先确认其立场技术与商业混杂 → 匹配用户强调的那一侧。纪律约束MUST DO 与 MUST NOT DO设计文档与实现版skills/the-fool/SKILL.md用两组约束定义该技能的纪律边界。MUST DO在挑战前先钢人化论题以最强形式复述用AskUserQuestion选择模式——绝不擅自假定模式把挑战建立在具体、确定的推理上而非含糊的如果……保持智识诚实——经得起检验的观点要承认驱动向综合或可操作输出收敛绝不只留反对意见挑战深度适配领域与风险等级只保留 35 条最强挑战点深度优先于广度在综合之前要求用户参与回应。MUST NOT DO稻草人化用户的立场为反对而反对虚无主义或纯粹破坏堆砌小反对意见制造虚假的脆弱印象跳过综合绝不只丢给用户一堆问题用泛泛的怀疑覆盖领域专长在AskUserQuestion能提供结构化选项时把模式选择输出为纯文本。在技能生态中的协作定位设计文档明确给出了 The Fool 的上下游协作关系skills/the-fool/SKILL.md 的related-skills元数据与之一致Common Groundcommands/common-ground/COMMAND.md—— 浮现隐藏假设应在The Fool 之前使用。它是以交互式多阶段对话为模式的命令级技能恰好承接先浮出假设、再发起挑战的链路Architecture Designer—— 将精化后的决策记录为 ADR应在The Fool 之后使用Code Reviewer—— 对实现的结构化评审是战术层面的对应技能Feature Forge—— 需求获取规范应在锻造之后再由 The Fool 挑战。在 SKILLS_GUIDE.md 中这一协作被固化为Decision Validation决策验证组合流程Common Ground浮现假设→ The Fool压力测试决策→ Architecture Designer记录精化决策。工程质量与验证技能如何通过自动化检查作为一份设计文档docs/skill-ideas/the-fool.md 在 Verification 一节给出了实现后的验收标准这些标准与仓库脚本一一对应python scripts/validate-skills.py --skill the-fool—— 验证 YAML、描述格式与 references 引用。该脚本实现了完整的检查器体系scripts/validate-skills.pyYamlChecker校验 frontmatter 可解析RequiredFieldsChecker要求name、description存在DescriptionFormatChecker要求描述含 Use when 触发子句MetadataFieldsChecker要求triggers、role、scope、output-format、domain、related-skills齐全并校验相关技能引用是否存在ReferencesDirectoryChecker与ReferenceFileCountChecker校验references/目录存在且至少含 1 个参考文件NonStandardHeadersChecker检查参考文件头部是否残留过时的 Reference for: / Load when: 头ReferencePathChecker会逐一解析技能文件正文中以反引号或 Markdown 链接引用的.md路径确保其能相对包含文件或技能根目录解析成功python scripts/update-docs.py --check—— 验证技能计数同步手动验证触发短语与自然调用模式匹配审查每个参考文件保持在 100600 行范围内。设计文档中的 Implementation Order先建 SKILL.md再依次创建 6 个参考文件最后更新 SKILLS_GUIDE.md在仓库中已全部完成且实现严格遵循了参考文件 100600 行的设计约束——这正是该仓库把设计文档 → 实现 → 自动化验证作为闭环流程的体现。小结The Fool 是 claude-skills 中一个设计精良、实现完整的批判性推理技能以 play the fool 为强制触发点通过AskUserQuestion两阶段交互选择模式用苏格拉底提问、辩证法综合、灾前尸检、红队对抗、证据审计五种方法论对任意想法进行结构化压力测试最终收敛为带置信度评估的综合结论。它的价值不仅在于找茬更在于纪律——钢人化、具体化、克制化、收敛化的挑战配合 SKILLS_GUIDE.md 中的 Critical Thinking 决策树与 Decision Validation 组合流程可以在决策提交之前把盲点、假设与脆弱点系统性地暴露出来。对于任何希望让 Claude Code 扮演敢于说真话的诤友的开发者深入阅读 skills/the-fool/SKILL.md 及其 6 个参考文件是掌握这套方法论最直接的路径。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考