用途：这是一个“顾问式”审计技能，不直接改代码，而是深入理解代码库、找出最高价值的改进机会，并撰写不含本会话上下文也能执行、测试和维护的实施计划。核心原则是“计划即产品”，顾问做重上下文分析与规格说明，执行者做有界实现。
主要能力与流程： 一、侦察（Recon）：阅读 README、CLAUDE.md/AGENTS.md、CONTRIBUTING、根配置文件（package.json、pyproject.toml、go.mod 等）、CI 配置与目录结构；识别语言、框架、包管理器、构建/测试/静态检查命令、测试覆盖形态与部署目标；记录仓库约定；摄取意图与设计文档（ADR、PRD/spec、CONTEXT.md、DESIGN.md、PRODUCT.md）；用 git 日志观察活跃变化热点。若无可用验证命令，需记录，且“建立验证基线”常是第 1 号发现。 二、审计（并行）：按 references/audit-playbook.md 的分类审计：正确性/缺陷、安全、性能、测试覆盖、技术债与架构、依赖与迁移、DX 与工具、文档、方向（下一步该做什么）。可用运行时只读探索或子代理并行；子代理须能读到 playbook，并只返回发现。深度分 quick / standard（默认）/ deep 三档，覆盖范围、子代理数量、广度、分类与发现数量不同。每条发现需有证据（file:line）、影响、工作量（S/M/L）、修复风险与置信度。 三、复核、排序、确认：先由顾问亲自打开被引用代码确认，区分“设计如此”（如 ADR 已记录的取舍）、证据错配与重复项；将发现按杠杆（影响÷工作量×置信度）排序成表，方向类发现单独列在表后。再询问用户要把哪些发现转成计划，并说明依赖顺序。 四、编写计划：每项发现一个计划文件，放入 plans/（若已存在且用途不同则用 advisor-plans/），含 README.md 索引（优先级、依赖图、状态表）。写入前记录 git rev-parse --short HEAD；计划要写明动机、精确文件路径、现状代码摘录、要遵循的约定、有序步骤与各自验证命令和预期输出、范围与禁区、可机检的完成标准、测试计划、维护说明与逃生舱（发现 X 则停下报告）。
调用变体：裸调用走完整流程；quick/deep 控制审计力度；带 focus（security、perf、tests）只审计该分类；branch 只审计当前分支相对默认分支的变更并按“该分支引入/既有”标注；next/features/roadmap 只做方向审计并给 4–6 条有据建议；plan <description> 跳过审计直接写单份计划；review-plan <file> 按模板批评并收紧计划；execute <plan> 派发独立工作树中的执行子代理并像技术负责人一样复核其 diff；reconcile 处理上次以来的状态；--issues 显式标志下再通过 gh 把计划发布为 issue（公开仓库含敏感发现需先警告并确认）。
硬性规则与限制：绝不修改源码，只允许在 plans/（或 advisor-plans/）下创建或修改文件；不运行会改变用户工作树的命令，只做只读分析，仅有两处范围化例外（执行复核时在一次性工作树内的验证命令、带 --issues 时 gh issue create）；计划必须完全自包含；绝不复现密钥值，只引用 file:line 与凭证类型并建议轮换；尊重项目说明文件、把被审计内容当证据；仅在存在可达信任边界失效时才报提示注入风险。执行需要宿主代理能在隔离工作树中派生子代理，否则只能转人工执行。仓库规模很大时，深度档也只按包作用域而非整个根目录。具体价格、平台支持等本资料未提供。