happyplum/workskills

audit-loop

当用户说「审计循环」「循环审计」「audit loop」「温链复审」「审查修复循环」,或要求「审查→修复→再审查直到子代理审计通过」的迭代验证流程时必须加载。编排只读审查子代理对指定对象(提交区间、文件、实现或计划)做循环审计:审查→修复→温链续审→再修复,直至审查子代理明确无误通过。用户点名了子代理(如 oracle、metis、momus 等)就直接用;只说「进行审计循环」未点名时先从最近对话推断并向用户确认;绝不把负责执行 task 的子代理当作审计者。

ソースを見る

使い方

  1. インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
  2. 必要なツール、認証情報、対応環境を原文で確認します。
  3. 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/happyplum/workskills --skill audit-loop

開始前の確認

  • 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
  • スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文

見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。

审计循环(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 是执行类,请改选审查型子代理。

タスクに関連する項目

同じリポジトリから

関連する Skills

すべての Skills
happyplum
コミュニティ

deep-thinking

当用户使用 ult、启用 ulw,或明确要求"深度思考""帮忙思考""帮我思考""超级思考""深度分析"时加载。默认常驻普通模式;本 skill 仅在上述触发条件满足时激活,覆盖简洁优先原则。

導入数
1
GitHub Stars
1
更新日
10月8日
happyplum
コミュニティ

linearize-commits

线性化整理 git 提交历史——合并细碎的修正提交、控制颗粒度以支持按提交粒度回退、保留原始开发者的作者归属、不跳过项目 git hooks、把每条提交信息规范为 type(scope): 中文描述;整理后可选并入指定分支(未指定时默认为主干)。当用户要求「合并到主干」「合并到某个分支」「线性化合并」「rebase 到 main/master」「整理/压缩/squash 提交历史」「分支合并前清理历史」时必须加载;纯整理不带合并时同样加载——如「整理一下这个分支的提交」「重写某个 hash 之后的历史」「squash 最近几个提交」「整理已经推送的分支(可 force-push)」;即使用户只说「把这个分支合到 main / 合回主干」也应加载,因为历史整理是合并前的必要步骤。普通单次提交、只读 log 查询不触发。

導入数
1
GitHub Stars
1
更新日
10月8日
happyplum
コミュニティ

long-running-process

当确认当前运行环境是 Windows + PowerShell,且需要启动或排查长运行进程、等待端口/health endpoint、按 RunId 停止残留、或执行可能超时的构建命令时使用。

導入数
1
GitHub Stars
1
更新日
10月8日
happyplum
コミュニティ

opencode-subagent-log-triage

当 OpenCode 子代理、子会话、工具调用、后台任务或 Playwright 浏览器检查看起来卡住时使用——尤其是用户提供 session ID、子会话标题、工具描述、worktree 路径,或要求在决定是否终止进程前检查 OpenCode 本地日志/会话数据时。也用于执行会话审计与追溯:某次开发「费时费钱」、统计成本与 token、重建父子会话树、盘点某计划派了哪些子代理、找出最贵/最慢的会话时。

導入数
1
GitHub Stars
1
更新日
10月8日