用途：loop-readiness 只对反馈机制做静态审查，能确认闸门脚本被写进计划，但按自身规则不执行任何东西，因此无法确认闸门仍能真正运行。本技能填补这一空白：在循环开始前，真实地运行一次计划中既有的反馈机制。闸门在计划里可能描述准确却已损坏——计划撰写到循环启动之间发生的无关变更，可能悄悄破坏计划假设仍可用的东西（如硬编码路径被改名），只有实际运行才能发现，静态阅读计划无法做到。这是独立检查，只要循环依赖既有反馈就可运行，无论是否先跑过 loop-readiness；loop-readiness 若发现计划视为已就位的反馈，其报告应指向本技能。
主要流程：第一步识别。从计划或用户直接给出的列表中，找出计划依赖的既有验证的具体命令——闸门脚本、测试套件、被引作反馈的 lint/类型检查。不包括循环实际工作（部署步骤、迁移、代码变更），只含这些检查。运行前先把识别出的命令列回给用户确认，不要假设，要确认列表正确且完整。第二步护栏与运行。运行每个已确认命令前：范围检查，只运行第一步识别为既有反馈的命令，绝不运行计划中其他任何东西（部署、迁移、数据写入），即使在同一文件附近或用户先前笼统同意过；生产检查，若命令的路径、参数或目标疑似生产相关（如提到 prod、共享或在线系统），要专门就这一条再次与用户确认，即便已同意整批运行，笼统的“是，运行它们”不构成对触及在线系统的特定命令的知情同意。随后在循环实际运行的环境中真实运行每条已确认、范围内、已放行的命令，捕获退出码与输出。第三步报告。对每条命令给出通过或失败，失败时附实际输出/错误，而非只说“闸门存在”；此处的失败是真实、已确认的阻塞项，应按阻塞项报告，而非供权衡的建议。
与 loop-readiness 的关系：独立技能，不共享状态或文件；loop-readiness 的“从不执行”规则完全保留，本技能的存在正是为了不必让该规则让步。限制：资料未提供更多平台、安装或收费信息。