用途：作为执行层的纪律叠加层，目标不是决定“为什么做”（目标层）或“做成什么形状”（设计层），而是证明“它确实能工作”。核心主张：没有可证伪证据的进度声明不成立，每次状态更新、每次验证勾选、每次“完成了”都必须携带原则上可能被推翻的观察结果。无法失败的测试、没有捕获输出的清单、“我试了看着还行”都不算证据。
主要能力：提供四个原则——可证伪性不可妥协；对可单元测试的代码默认采用 TDD（先写会失败的测试，再写最小实现）；状态更新是证据链而非进度条（须写明改动文件行号、通过哪些测试）；反教条检查，即每条测试/证据都要能说明它具体捕获什么失败。适用场景包括有真实用户的生产代码路径、大型重构等易回归系统、未发现缺陷成本高昂的工作，以及需他人或未来的自己长期复核的工作，不适用于一次性原型、探索性验证、一次性脚本和纯文档修改。
使用方式：两个入口命令。/evidence-driven init 读取并执行 commands/init.md，做一次性脚手架配置（代理配置片段、可选的预提交钩子与 CI 集成说明）。/evidence-driven [任务描述] 对指定任务应用该纪律，按 Plan → Build → Verify 流程推进：计划阶段列出具体失败模式的风险、对应测试或检查、TDD 顺序、完成证据清单，并与用户确认；构建阶段逐步执行 TDD 循环并更新状态；验证阶段逐项捕获具体观察结果，禁止无证据的勾选。
限制与依赖：该技能假定设计层（design-driven）的蓝图结构存在，但未安装时仍可配合其他任务结构使用；状态需要持久化载体（蓝图 State、外部任务系统或暂存 markdown），聊天记录不是状态载体；若任务跨会话且无持久表面，则不应使用。资料中未提供具体收费、价格或平台信息。