How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/happyplum/workskills --skill audit-loopBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
审计循环（Audit Loop）
这是什么
以「子代理审查 → 修复 → 温链续审 → 再修复」的闭环收敛质量目标：审查者与修复者分离（审查者只读，修复由协调者侧完成），每轮修复后由同一审查会话（温链，task_id 续用）复核，直到审查者明确零未决发现。
通过审计循环 = 最后一轮温链续审返回无误（无未决发现、无修复引入的新问题）。
温链的价值：审查者带着上轮完整记忆只审增量（修复 delta），既不重新翻案已闭合项，也能专门检查修复本身是否引入新回归——这是每轮新开审查会话做不到的。
触发与子代理识别（先于一切）
| 用户话语 | 动作 |
|---|---|
| 点名了审查子代理（「用 oracle 审计循环」「metis 审计一遍再修再审」等） | 直接使用该子代理，进入循环 |
| 只说「进行审计循环」「走审计循环」等，未点名 | 先从最近对话推断候选（上一轮审计用过谁、近期讨论中提及过哪个审查代理），以「是否用 X」一个定向问题确认；推断不出候选时，列出当前环境可用的审查型子代理让用户选 |
| 点名的是执行 task 的子代理（build / Sisyphus-Junior / quick 等执行类） | 拒绝并请用户改选——审计者必须只读，执行者不能审自己生态里产出的修复 |
识别规则：
- 不硬编码子代理名单。判定标准是角色性质：只读咨询/评审型代理（oracle、metis、momus 这类高推理审查者）合格；承担文件修改、task 执行或构建的代理不合格。环境里没有用户点名的代理时，如实报告并请用户改选，不擅自替换。
- 审计对象同样从用户话语获取（提交区间、文件/目录、计划、刚完成的实现）；对象模糊时，与确认子代理合并为同一个问题一次问清，不连环追问。
循环协议
每轮三阶段；未通过则回到阶段 2。
阶段 1：审查（ROUND N）
- 首轮：后台新派审查子代理，委托采用六段（TASK / EXPECTED OUTCOME / REQUIRED TOOLS / MUST DO / MUST NOT DO / CONTEXT），写明：
- 审计对象与精确范围（如
git log A..B的提交清单、文件集、计划文档）； - 本轮改动的完整背景与已有验证证据（已跑过的测试/typecheck 结果，避免审查者重复长构建）；
- 只读约束（禁改文件、禁状态变更 git 操作、禁长构建）；
- 输出要求：逐项发现带 file:line 证据、严重级别（阻断/非阻断）、每项给最小修复方向；
- 通过条件明示：零发现即 PASS。
- 续轮（温链）：
task(task_id="ses_...", ...)复用原审查会话，prompt 只含增量——上轮发现清单、对应修复提交（hash）、修复后验证证据——要求审查者逐项裁定FIX-CORRECT / FIX-INCOMPLETE / FIX-INTRODUCES-REGRESSION，并整体扫描修复是否引入新问题。审查者有上轮记忆，不需要重发背景。
阶段 2：修复
- 收到审查完成通知后先取结果，按发现逐项修复（协调者按正常路由自修或派发；与审查者角色分离）。
- 修复本身必须过定向验证（受影响测试 / typecheck / diff 核对）才算完成；每轮修复按独立意图原子提交，提交 hash 供续审引用。
- 非阻断发现（测试缺口、建议级）默认也修；明确决定不修的，须在续审 prompt 中向审查者声明并给理由，由其裁定是否放行——不许静默跳过。
阶段 3：裁定
- 审查者零未决发现且明确 PASS → 审计循环通过，向用户报告终态。
- 仍有发现（含 FIX-INCOMPLETE / FIX-INTRODUCES-REGRESSION）→ 回到阶段 2，进入下一轮。
防护与停止条件
- 温链不换人：续审一律复用原会话
task_id；每轮新开审查会话会丢上下文并重新翻案已闭合项，禁止。仅当原会话因基础设施故障不可恢复时才允许重开，且 prompt 须携带前几轮全部发现与修复史。 - 不削弱换通过：不得以删测试、改断言、压制错误制造 PASS；审查者裁定的必修项修完并通过验证才能送续审。
- 验证先行：未过定向验证的修复不送审。
- 轮数熔断：同一发现连续 2 轮修不掉，或连续 3 轮都在发现全新问题（范围蔓延），停止循环，把分歧点摊开给用户裁决——不无限循环消耗预算。
- 审查者只读：任何轮次都禁止审查子代理直接改文件或执行修复。
终态报告
至少包含：总轮数、每轮发现数与「发现→修复提交」对应关系、最终 PASS 证据（审查者结论摘录或原话要点）、残余非阻断项（若有，含已声明的放行理由）。
示例
- 「审计循环，用 oracle 审 f1560864a..HEAD」→ oracle 首审 → 修复 → oracle 同会话续审 → …直至 PASS。
- 「对这份计划走审计循环」（未点名）→ 上一轮用过 momus 则问「是否继续用 momus？」→ 确认后进循环。
- 「审计循环，派 quick 审」→ 拒绝：quick 是执行类，请改选审查型子代理。
