这是一个面向编码代理的安全审计技能，通过侦察、覆盖驱动挖掘、候选验证、结构化输出、独立复核与中性报告六个阶段，产出可机器读取的审计结果。
项目做什么
该技能旨在让具备工具调用与并行子代理能力的编码代理承担安全审计工作。它先把目标仓库的架构、信任边界、输入面与既有证据记录到 architecture.md 和 coverage-ledger.json，再按覆盖账本的单元分配隔离的挖掘代理，并用覆盖批评者寻找遗漏；随后由全新验证者对每个候选尝试证伪，最终输出 confirmed、needs_validation、rejected 三类记录并生成报告。多次针对同一仓库运行是累加的，会利用既有账本定位缺口、复核已变更源码。
与同类方案相比
流程被拆成六个明确阶段，并配套按目标类型划分的狩猎提示文件，覆盖内存安全与二进制、AI 与 LLM、Web 协议与认证、客户端、供应链与发布、云与部署、RPC 与消息、资源耗尽、数据隔离与生命周期、桌面移动与本地 IPC 等方向。验证者与发现者分离，最终来源声明还会由新的代理独立复核。附带零依赖的 findings 与 coverage-ledger 校验脚本及测试，记录字段受 JSON schema 约束，便于机器处理。设计上区分证据不足的重叠判定，不把纵深防御缺失当作漏洞。
设计与创新
仓库自述这是 Cloudflare 漏洞发现工具链的起点版本，强调以覆盖账本驱动任务分配、用覆盖批评者补缺、对候选做对抗性证伪，以及把判定分为 confirmed、needs_validation、rejected 三种语义并各自限定适用范围。源码被替换后需再由另一名独立验证者复核，报告从已核实记录与覆盖账本派生而非直接由发现者撰写。这些做法在该仓库内的组织方式有一定特点，但 README 未提供与其他安全审计工具或方法的对比数据，因此其相对创新程度与优劣尚无法验证。
适用场景
适用于把编码代理指向待审代码库后直接提出安全审计、查找漏洞、渗透测试等请求；README 给出的示例包括 security audit this codebase、find security vulnerabilities in ./src、以及指定输出目录的安全评审。它可用于原生二进制与内核目标、LLM 与代理工具类目标、HTTP 协议与认证目标、浏览器客户端目标，以及供应链、云基础设施、RPC 与消息队列、桌面与移动本地 IPC 等目标类型。同一仓库可重复运行以累积覆盖，也可用于专注于某类问题的定向排查。
谁会受益
对需要把安全审计流程结构化、并希望结果可被程序读取和持续追踪的团队较为实用：三类判定和 JSON schema 让记录便于校验与流转，覆盖账本使重复运行能针对缺口展开而非重头再来。按目标类型组织的狩猎提示文件降低了为不同技术栈准备审计思路的成本。独立的记录复核与验证者轮换机制有助于减少单一代理自证带来的偏差。README 提到在作者自身的测试运行中，单次运行大约发现重复运行合计数量的一半，可作为多次运行的动机参考。
使用前需要注意
运行依赖支持工具调用与并行子代理的模型，校验脚本需要 Node.js。若要执行目标代码进行构建、测试、浏览器、模拟器、模糊测试等操作，必须有操作系统强制的沙箱，禁用外部网络、使用净化后的白名单环境、限制资源并仅允许写入指定临时路径，否则流程会把线索保持为 needs_validation 而不执行目标代码。README 所述单次运行发现比例来自作者自述测试，缺少可复现细节，无法独立验证。该仓库只是单仓起点，博客中提到的舰队级系统并不在此。README 未给出与其他安全工具的性能或效果对比，相关优势无法确认。
本文基于抓取时的项目 README 和仓库简介整理；功能、限制与文档可能随项目更新而变化。