用途
loop-readiness 是一个就绪度审查技能，用来评估一份“循环”计划是否具备足够的前馈指导与反馈验证，从而可以安全地无人值守运行。这里的“循环”指任何在无人工逐步检查的情况下多次迭代运行的智能体或进程——自动驾驶、定时任务、长时间运行的智能体工作流等。
需要强调：这是一次就绪度审查，不是一道闸门。它不会给出通过/不通过结论，也不会给出单一总分；它报告每个维度上有什么、缺什么、需要权衡什么，让决定是否启动循环的人掌握完整信息。审查对象是循环的计划，而不是循环本身——审查过程中不执行任何内容。
主要能力
第一步：获取计划
如果已经提供了计划（文本或文件路径），直接使用。如果没有，则在可用时使用 grill-design 技能；否则通过一次一个问题的访谈，逐步建立对计划的理解——它要做什么，以及它打算如何判断自己是否在正常工作。每轮只问一个问题，绝不问复合问题。
第二步：逐维度审查
依次走完全部四个维度。对每个维度，记录存在什么、缺失什么、覆盖有多深——没有固定的机械核对清单，而是根据这个具体循环实际所需的深度做出判断。
2.1 就绪定义（DoR）
是否有书面的东西定义这个循环的目的与边界？视循环而定，可能包括：目标陈述、明确的非目标/范围外事项、契约（数据形态、API 边界）、UI 草图或图示——按风险程度决定深度。小循环一行目标足矣；涉及生产数据的循环通常需要更多。
2.2 前馈（Feedforward）
前馈是在每次迭代之前或期间提供给循环的指导，用来提高它一开始就做对的概率——约定文档、技能、契约、引导脚本、代码改写工具，任何循环在行动时读取或受其约束的东西。需要记录这些指导属于：计算型（必须经过的确定性工具/脚本/生成器）、推断型（读取并运用判断的文档/技能）、两者兼具，或两者皆无。
2.3 反馈（Feedback）
反馈是在一次迭代/动作之后的验证，用来捕捉不良结果。健康的循环通常至少需要一种，但具体种类与数量取决于循环实际可能破坏什么，属于判断题。可关注：
- 计算/模拟/试运行——单元测试、linter、类型检查、结构检查。便宜快捷，每次迭代都能跑，但可能在遗漏真实世界故障的情况下通过；如果这是唯一的反馈机制，需指出这一权衡。
- 真实环境——针对循环实际要操作的真实系统进行验证。记录是否存在，以及看起来是否可安全无人运行（见第三步中的具体检查）。
- 推断型——由 LLM 作为评审者或审查步骤，对结果做语义判断，而非确定性检查。
2.4 完成定义（DoD）
计划是否说明循环如何真正停止？没有必须使用的词汇或固定的终态集合——循环可以按其作者定义的任何方式结束。记录计划是否覆盖了干净成功路径之外的情形：失败时怎么办，以及循环无法判断自己是否成功时怎么办（结果不明确、缺少前置条件等）——如果缺失，值得作为缺口提出，但不要求特定修复方式。
第三步：报告
对上述四个维度分别给出：存在/缺失/部分满足的简短清单；仅针对该维度的一行定性说明（如“扎实”“单薄”“缺失”）。不要把这些综合成一个总分或标签——四条说明各自独立，由读者自行权衡。
随后给出与具体缺口挂钩的可行建议——具体的下一步，而不只是“这里缺了”。对于 2.3 中发现的真实环境反馈，直接检查以下各项（这适合静态审查——通常从计划描述中就能得到明确的 yes/no），并对缺失项提出修复建议：
- 是否有预检步骤，在循环开始做真实工作之前验证凭据/权限确实可用（而不只是假定可用）？如果没有，建议补一个——在循环无人运行前，先对真实系统测试一次。
- 对于计划视为已存在的反馈机制（闸门脚本、测试套件、从早前工作继承的检查），而非循环将新建的机制——自计划写就以来它是否经过冒烟测试？一份计划可以在静态阅读中准确描述某个闸门，而计划与执行之间的无关变更会悄悄破坏它（例如别处重命名了硬编码路径）；只有实际运行闸门才能发现，静态审查在设计上对此是盲的。如果没有，建议在信任它作为可用反馈之前，对其运行 loop-preflight 技能——该技能会实际运行它，因此本审查本身仍无需违反下面“绝不执行计划”的规则。
- 访问权限是否按最小权限范围限定——不超过任务所需？如果不是，建议收窄。
- 是否默认只读？如果循环只需要观察却仍持有写权限，建议去掉。
- 如果循环确实需要写入，该写入是否限定在真正可安全写入的环境（沙箱、非生产目标等），而不是把写能力硬接到面向读取的检查上？如果不是，建议在循环无人运行前修正范围。
其他建议示例：
- 没有书面记录循环目标或边界（DoR）→ 建议在启动前至少写下一行目标和明确的非目标，以免运行中范围漂移。
- 没有供循环遵循的指导/约定（前馈）→ 建议指向现有文档/技能/契约，若没有则写一份简短的。
- 只有模拟/试运行反馈，没有针对真实目标的验证 → 建议至少加一个真实环境检查，或在循环风险较低时明确接受该风险。
- DoD 中没有升级/受阻结果 → 建议为循环增加一种明确方式，在无法判断是否成功时停止并移交人类。
建议是供权衡的备选，而不是继续之前必须满足的要求。
使用方式
在需要评估一份无人值守循环计划是否就绪时使用该技能。提供计划文本或文件路径即可开始；若没有提供，技能会通过一次一问的访谈或可用的 grill-design 技能来构建理解。审查全程在对话中（或作为响应返回）进行，不写入任何其他文件，除非用户明确要求保存。
适用场景
适用于任何计划以无人工逐步检查方式多次迭代运行的智能体或进程，例如自动驾驶、定时任务、长时间运行的智能体工作流等。特别适合在启动高风险（如涉及生产数据）的自主循环之前，用来发现前馈与反馈方面的缺口，以及真实环境验证、权限范围、冒烟测试等安全隐患。
限制
- 绝不执行被审查计划中的任何内容——这是对所描述内容的静态审查，不是对其是否真正可用的测试。
- 绝不产生通过/不通过结论或单一总分/标签——只给维度级说明。
- 绝不要求 DoD 终态使用特定词汇，也不要求 DoR 使用固定核对清单——只根据该具体循环的风险评估已有内容。
- 除用户明确要求外，不写入任何其他文件。
- 由于是静态审查，对于已存在反馈机制的隐蔽损坏（如路径被别处重命名）在设计上是盲的，需要借助 loop-preflight 技能实际运行才能发现。
- 该技能的安装命令、平台支持、是否收费等信息，资料中暂未提供。