用途
execute-plan-loop 是一项用于 AI 编程代理的技能，用途是把一份已经确定的计划按步骤顺序执行，循环推进直到最后一步完成。它不是用来做规划的工具，而是在计划与规格已存在的前提下，负责逐步实现、验证和记录。
主要能力
- 全程约定：循环期间遵循若干约定：git-commit-organizer（提交整理）、no-slop-code（代码质量）、decision-record-log（决策记录）、scratchpad-working-files（草稿工作文件）、simplified-technical-language（简明技术语言）。
- 执行前准备：读取计划与规格；若
.scratchpad/<slug>/progress.md已存在，则从第一个未完成的步骤继续；运行全量测试并记录基线（测试数量、是否全绿）。 - 最小手工验证环境：搭建隔离于真实数据的最小手工运行方式（例如独立端口的服务器加临时数据库，或对临时文件夹的 CLI 调用），启动与停止命令写入
.scratchpad/<slug>/manual-env.sh；启动前检查端口是否空闲，因为其他项目可能占用；绝不停止不是自己启动的进程。 - 逐步实现：每步只实现该步骤描述的最小内容，不提前做后续步骤的事。
- 测试：为步骤的验收标准新增或更新测试；若是修复，先确认新测试在无修复时失败、有修复时通过。
- 全量检查：运行项目的完整检查（如类型检查、lint 和全部测试）。
- 手工验证：在手工环境中执行计划列出的验证，完成后停止自己启动的所有东西。
- 记录与提交：编写决策记录要求的 ADR（若项目已关闭该约定，理由写入提交正文），同步受影响的文档，并按提交整理约定提交。
- 进度文件：在 progress.md 中更新状态与提交哈希；在进度文件显示本步提交之前，不开始下一步。
- 简短输出：聊天中每步只简报：本步新增内容、测试数量、手工验证结果、提交哈希。
使用方式
以计划（或变更清单）为输入，按上述循环逐条推进。当现实与计划不符时：若某个库的表现与计划假设不同，选择能保持规格成立的最小改动，写入 ADR 并在步骤摘要中说明；若规格本身看似有误，或某步骤无法保持系统集成，则停下询问，不擅自更改用户已批准的行为。不要为验证擅自打开浏览器，除非用户要求浏览器测试；但改动用户界面的步骤仍需要查看结果（渲染或组件测试、无头截图，或检查生成输出），而不只是构建和 lint。若用户已委托决策（如“别问我”“选最好的方案”），则自行决定并用一行说明，不再重复询问已批准的事项（如每步后合并）。
变更清单模式：当输入是由 triage-findings-list 产生的编号变更清单而非计划时，把每个条目 id 当作一个步骤，按用户批准的顺序处理；在提交正文或 ADR 来源字段中使用条目 id；两个条目改动同一代码时合并为一次提交并同时标注两个 id；修复前先复现问题，并把复现留存为测试；同时更新变更清单中每个条目的状态。
结束阶段
把 progress.md 写成最终状态；对照循环新增的内容检查 AGENTS.md，新增的测试、lint 或启动命令、新文件夹或新约定应按步骤相同的提交风格补入；复盘循环中的失败与纠正（失败的检查、回滚的提交、计划偏差、来自用户的纠正），对每个可能再次发生的问题给出证据（步骤、提交或输出）和一条具体的预防方式，保存到 .scratchpad/<slug>/loop-log.md，供 session-retrospective-rules 使用；最后报告：完成的步骤、提交、前后测试数、记录的决策、遗留或跳过的事项及原因。若会话在结束前中断，说明已完成什么、还剩什么、从哪一步恢复。
适用场景
适用于已有经批准的计划或编号变更清单、需要逐步实现并持续验证的软件开发任务，尤其是要求每步都可测试、有手工验证、有决策记录、文档同步和清晰提交历史的工程流程。
限制
该技能依赖已存在的计划与规格；不负责制定计划。其具体运行环境、支持的平台或工具链、定价等信息暂未提供。