fp-check 用于系统性验证某个疑似安全漏洞是否真实，目标是消除误报，并给出 TRUE POSITIVE 或 FALSE POSITIVE 的结论及有据可查的证据。
适用场景：当用户问“这个 bug 是真的吗”“这是真阳性还是假阳性”“验证这个发现”“检查该漏洞是否可利用”，或要求验证某个具体疑似 bug 时使用。不适用于漏洞挖掘（如“找 bug”“安全分析”“审计代码”）、风格/性能/可维护性等常规代码审查、功能开发与重构，以及用户明确要求只做快速扫描而不验证的情况。
主要流程：先执行 Step 0，用自己的话复述漏洞声明，记录漏洞类型、根因、触发条件、影响、威胁模型、bug 类别、执行上下文、调用方约束、架构与历史背景；若无法清晰复述则向用户澄清。随后选择验证路径：标准验证适用于声明清晰具体、单一组件、bug 类别明确、无并发/异步、数据流直接的情况，按线性清单逐项记录；深度验证适用于声明含糊、跨组件（数据流经 3 个以上模块或服务）、涉及竞态/TOCTOU/并发、无明确规范的逻辑 bug，或标准验证无法定论、用户要求完整验证的情况，需拆解任务依赖图并逐阶段执行。默认从标准验证开始，其内置两个升级检查点，复杂度超出线性清单时转入深度验证。
批量处理时：先对所有 bug 执行 Step 0，再分别路由，先处理标准路径再处理深度路径，最后检查是否存在由多个单独未通过门禁的发现组合而成的利用链。全部处理完后给出汇总：真阳性与假阳性数量、各自简要说明。
该技能强调拒绝“剩余 bug 快速分析”“模式危险即漏洞”“为效率跳过完整验证”“代码看起来不安全就直接报告”“别处类似代码有漏洞所以这里也是”“这显然很严重”等合理化借口，要求每个 bug 都完整验证、追踪从 source 到 sink 的完整数据流，并完成魔鬼代言人式复核。
参考资料包括：标准验证、深度验证、门禁审查（六个强制门禁与结论格式）、按 bug 类别的验证要求（内存破坏、逻辑 bug、竞态、整数问题、加密、注入、信息泄露、DoS、反序列化）、误报模式（13 项清单与红旗）、证据模板（数据流、数学证明、攻击者控制、魔鬼代言人复核）。
限制：资料未提供具体安装命令、运行环境、收费方式或平台支持信息，暂未提供。