loop-design

disable-model-invocation	true
name	loop-design
description	帮助用户把一个重复性任务设计成一个有边界的 Loop（运行契约 + 预算），并产出一份可复用的 loop 定义文档。 触发条件：(1) 用户想为某类反复执行的任务建立一个受控循环（"每次都这样跑""反复打磨直到满足 X"）， (2) 用户想为某个 R&K Flow Spec 定制阶段路径或修复循环预算， (3) 用户问"帮我写一个 loop / 设计一个循环"。 本 Skill 只负责交互式产出 loop 定义，不负责驱动执行。执行由对应的工作流 Skill 或用户自己承担。 不要用于一次性任务、简单问答，或已有明确 Spec 可直接执行的场景。

Loop Design

把一个重复性任务设计成有边界的 Loop。理念来自"先写刹车，再写循环"：不先写一段无界的提示词，而是先把"读什么、能动什么、怎么算完成、什么时候停、什么时候交还给人"想清楚，落成一份可复用的 loop 定义。

运行契约

进入工作流程前先对齐这张表。loop-design 本身也是一个有边界的循环单元。

项	本 Skill 的约定
输入	用户对重复性任务的描述、intent-confirmation 澄清出的目标、loop-definition-template.md 骨架
权限	只做"澄清 + 引导填表 + 产出一份 loop 定义文档"；不驱动执行、不替用户跑循环、不修改业务代码
验证	loop 定义六要素齐备（目标/输入/权限/验证/停止/升级）且停止与升级条件具体可判定
停止	loop 定义文档定稿且通过用户确认即停止；不顺手去执行这个 loop
升级	用户的任务其实不适合做成 loop（一次性、无明确完成标准）时，如实说明并交回用户决定

核心原则

1. 先刹车，后循环：停止条件和升级条件是必填项，不是可选项。一个没有停止条件的 loop 不允许产出。
2. 只产出定义，不驱动执行：loop-design 的产物是一份"定义"，谁来跑、怎么跑由对应工作流 Skill 或用户决定。
3. 复用 intent-confirmation 做澄清：目标和边界的对齐交给 intent-confirmation，本 Skill 专注把共识结构化成 loop 定义。
4. 预算来自用户：循环次数、无进展轮数等上限不写死，由用户在定义时确认。
5. 能复用 R&K 内核就复用：loop 定义骨架与各 Skill 头部的「运行契约」表同构，便于和 R&K Flow 衔接。

Loop 的两种类型

类型	说明	产物去向
R&K Flow 内的 loop	为某个 Spec 定制要走的阶段路径，或定制 spec-test ↔ spec-debug 修复循环的预算	写入该 Spec 的 lead/team-context.md（如「修复循环预算」、「当前运行路径」）
自定义 loop	用户自己的重复任务（如"每日汇总""反复打磨直到达标""批量处理直到队列空"）	产出独立的 loop 定义文档，由用户保存或交给执行方

判断不清时，先用 intent-confirmation 问用户这是"一次性任务"还是"会反复执行的循环"。一次性任务不做成 loop。

工作流程

步骤 1：澄清目标（调用 intent-confirmation）

调用 intent-confirmation 与用户对齐：

• 这个 loop 要解决的核心任务是什么？
• 它是会反复执行的（loop），还是一次性的（不做成 loop）？
• 属于 R&K Flow 内的 loop，还是自定义 loop？

如果是一次性任务，停止并建议走普通流程，不产出 loop 定义。

步骤 2：引导用户填写六要素

按 references/loop-definition-template.md 的骨架，逐项与用户确认。停止和升级是必填项：

要素	引导问题
目标	每一轮循环要达成什么？整个 loop 的最终目标是什么？
输入	每轮读什么、依赖什么上游产物或数据？
权限	这个 loop 允许动什么、禁止动什么？
验证	怎么判断一轮是否成功？谁来验证（最好不是执行者自己）？
停止	满足什么条件就停？最大轮数？最大无进展轮数？最大时长/预算？
升级	什么情况必须停下来交还给人，而不是继续自动跑？

对"停止"，至少要落一个最大轮数和一个最大无进展轮数（建议默认 3 轮 / 连续 2 轮无进展，用户可改）。

步骤 3：定义"进展"

和用户确认这个 loop 里"一轮算有进展"的判据（用于无进展检测）。例如：新增通过的检查项、缩小了问题范围、产生了新的可验证证据。判据要具体，避免"写了新内容就算进展"这种空转。

步骤 4：产出 loop 定义文档

按模板产出一份完整的 loop 定义：

• R&K Flow 内的 loop：把预算写入对应 Spec 的 lead/team-context.md（「修复循环预算」/「当前运行路径」），并说明由哪些 Skill 执行。
• 自定义 loop：产出独立的 loop 定义文档（Markdown），交给用户保存或交给执行方。文档放在用户指定路径；未指定时建议放当前工作目录并提示用户。

步骤 5：用户确认

向用户展示 loop 定义全文，确认：

• 六要素是否齐备、准确
• 停止和升级条件是否真的能挡住失控
• "进展"判据是否具体

用户确认后即停止。不要顺手去执行这个 loop。

与其他 Skill 的协作

用户提出重复性任务
  → loop-design → intent-confirmation（澄清 What）
  → loop-design 引导填六要素 + 进展判据
  → 产出 loop 定义
      ├─ R&K Flow 内：写入 lead/team-context.md，交给 spec-* Skill 执行
      └─ 自定义：产出独立定义文档，交给用户/执行方

场景	协作 Skill
澄清目标和边界	→ intent-confirmation
R&K Flow 内的修复循环预算	→ spec-start（修复循环预算）、spec-test / spec-debug 执行
把 loop 固化成可复用流程	→ skill-creator（如该 loop 值得变成一个新 Skill）

后续动作

完成 loop 设计后确认：

1. loop 定义六要素齐备，停止和升级条件具体可判定
2. "进展"判据已与用户确认
3. R&K Flow 内的 loop 已写入对应 lead/team-context.md；自定义 loop 已产出独立定义文档
4. 已向用户确认 loop 定义全文
5. 未越界去执行这个 loop

常见陷阱

• 产出了没有停止条件的 loop（违背"先写刹车"）
• 把一次性任务硬做成 loop
• "进展"判据太宽（写了新内容就算进展，导致无进展检测失效）
• loop-design 自己跑起了这个 loop（应只产出定义）
• 把循环次数、无进展轮数写死，而不是让用户确认