用途：这是一套“实现前验证”流程，用于在开始写代码前判断需求是否值得做、是否已有现成方案，从而避免在错误方向上浪费大量工作量。资料称投入 100-200 tokens 的验证可节省 5000-50000 tokens 的错误工作。
主要能力：采用五因子加权模型计算总体置信度，公式为 duplicate×0.25 + architecture×0.25 + docs×0.20 + oss×0.15 + rootcause×0.15，结果在 0.0 到 1.0 之间。各因子分别关注：功能是否已存在于代码库（用 Glob、Grep、ChromaDB 语义检索）、是否与技术栈和既有模式兼容（读取 CLAUDE.md、README.md、package.json、Cargo.toml、requirements.txt）、是否查阅了相关文档、是否存在可参考的高质量开源实现（WebSearch 查 GitHub、npm、crates.io），以及底层问题是否被清楚理解（症状、根因、复现步骤、预期与实际、上下文）。
判定阈值：置信度 ≥0.90 视为 PROCEED，直接实现；0.70-0.89 视为 CLARIFY，向用户澄清并给出替代方案；<0.70 视为 STOP，需补充信息后再动手。不同代理类型可设不同门槛，例如安全审计代理 ≥0.95、implementor 与 developer-agent ≥0.90、前端 UI 开发 ≥0.85、研究类 ≥0.75、文档类 ≥0.70。
适用场景：新功能实现、重大重构或架构调整、缺陷修复（生产紧急事故除外）、引入新依赖、数据库 schema 变更、新增 API 端点、认证与安全实现等，均可先跑此检查。
限制：简单文档更新、错别字修复、紧急生产热修和纯探索性研究可跳过。根因分析部分需要人工判断；开源参考的质量分级（星标数、是否维护）为资料给出的经验标准。资料未提供具体安装命令与官方收费信息。