用途：把 GitHub 仓库上的多步骤迭代任务结构化为带可验证目标与显式边界的智能体循环，典型场景包括修复失败的 CI、清理 lint 违规、迭代 PR、调试失败的工作流。它针对两类常见失败：无限循环却不知是否在推进，以及在模糊标准下宣布“完成”。
主要能力与循环步骤：观察（先读取真实状态，如 gh pr checks、CI 日志、当前 diff、涉及文件，不预设状态）；决定（只做针对性的单个动作，不做大范围重写，优先修复日志中已定位原因的最小改动）；执行（编辑、提交）；验证（对照停止标准，而非凭感觉）；决定下一步（继续、换法修复、回滚或停止）；达到可验证标准后立即停止，不“为了保险”继续跑。
客观与主观判定：客观标准（CI 变绿、测试通过、markdownlint 无错误、构建可编译、PR 可无冲突合并）可由智能体自行判断并循环到满足为止；主观标准（双语文档质量、路线图合理性、README 语气）不能循环，需让用户给出可应用的测试，或改为可验证的代理标准（如“包含 X、Y、Z 章节”而非“感知质量”）。混合任务应拆分，各部分使用各自的判定标准。
迭代护栏：开始前设定最大尝试次数（定向 CI 修复为 3–5 次，超过需再经用户确认）；检测停滞，若同一错误在两次不同尝试后复现，通常不是语法问题而是理解问题，应停下并暴露阻塞点，而非继续猜测；不得静默超出约定上限，达到上限应报告状态并询问后续处理。
回滚：若某次尝试反而恶化状态（新的 CI 错误、引入冲突），先回到已知稳定状态再重试（git checkout -- <文件>，涉及多提交时重置工作分支），不要在已损坏状态上继续叠加修复。
双层记忆：任务记忆记录当前 PR/会话中已尝试过什么、为何失败，避免重复；长期记忆沉淀跨仓库可复用的模式（如系统性禁用 MD013/MD033、在 2026 年 9 月 Node 20 弃用前需要 actions/checkout@v5、为避免编码冲突的 git 操作顺序），解决一次后即记录，不必在每个仓库重新发现。
示例：任务“CI markdownlint 失败，请修复”，客观停止标准为 gh pr checks 变绿；循环为读取确切错误→修正相关行→push→复查 CI，若出现不同错误则重来，若两次后仍是同一错误则停止并报告；若每个提交都是隔离且在下一个之前已验证的修复，则无需回滚。
限制：该技能本身不提供安装命令、收费方式或运行环境要求，原始资料未提供这些信息；具体操作依赖 gh、git 等工具在用户环境中的可用性，资料中也未说明。