用途：把原本需要人在内层循环中操作的工作流，改造成 LLM 能自己闭合的循环。核心是两件事：移除触发闸门，打开可观测性。
主要能力：先显式指出触发闸门——当前哪一步需要人操作（点击按钮、查看截图、终端交互、提交网页表单），人提供了什么 LLM 拿不到的信号（视觉确认、复制粘贴、密钥、目测判断），结果去了哪里（对话记忆、截图、脑内笔记）。多数循环只有一两个闸门，移除后周期可缩短到秒级，优先选最小的那个。
结构性修复：Web-UI 触发改为 CLI 触发，寻找或构建等价命令行（webhook、REST 端点、gh/aws/gcloud 子命令、内部 just 目标等可编程调用）；仅 stdout 输出改为文件输出，把结果写入 LLM 可回读的文件（结构化 JSON、markdown 报告、带可寻址偏移的追加日志），以便在上下文压缩后仍可 diff 和检查；仪表盘改为结构化日志，用 CLI 查询（PromQL、Datadog API、日志聚合 tail）产出可读的通过/失败/警告判定；目测判断改为契约断言，把标准编码为测试、schema 或断言，作为循环的完成条件。
剩余闸门用 trap-or-abandon 规则处理：若该步骤能包成“LLM 提议、人批准一次、LLM 迭代至契约通过”的验证循环，则保留，人处于外层；若必须人在内层且无法包装（如每次迭代都要新的 SOC2 审查、实时客服、硬件介导测试），则不要照看，要么整体移出循环作为离散交接，要么改进工具链让该步骤消失。
限制：该技能不编写项目规则（交给 init 处理 AGENTS.md），不引导严格模式验证闸门（交给 strict-validation-setup），不选择测试框架（交给 test-driven 或语言惯用测试器）。姿态是外科手术式而非架构式：一次移除一个闸门，每次修复后重新评估循环是否闭合，避免重设计整个系统。资料未提供安装命令、收费与平台信息。