By 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（一次性、无明确完成标准）时，如实说明并交回用户决定 |
核心原则
- 先刹车，后循环：停止条件和升级条件是必填项，不是可选项。一个没有停止条件的 loop 不允许产出。
- 只产出定义，不驱动执行：loop-design 的产物是一份"定义"，谁来跑、怎么跑由对应工作流 Skill 或用户决定。
- 复用 intent-confirmation 做澄清：目标和边界的对齐交给 intent-confirmation，本 Skill 专注把共识结构化成 loop 定义。
- 预算来自用户：循环次数、无进展轮数等上限不写死，由用户在定义时确认。
- 能复用 R&K 内核就复用：loop 定义骨架与各 Skill 头部的「运行契约」表同构，便于和 R&K Flow 衔接。
Loop 的两种类型
| 类型 | 说明 | 产物去向 |
|---|---|---|
| R&K Flow 内的 loop | 为某个 Spec 定制要走的阶段路径，或定制 spec-test ↔ spec-debug 修复循环的预算 | 写入该 Spec 的 lead/team-context.md（如 Loop Budget、Current Run Path） |
| 自定义 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（Loop Budget/Current Run Path），并说明由哪些 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（Loop Budget）、spec-test / spec-debug 执行 |
| 把 loop 固化成可复用流程 | → skill-creator（如该 loop 值得变成一个新 Skill） |
后续动作
完成 loop 设计后确认：
- loop 定义六要素齐备，停止和升级条件具体可判定
- "进展"判据已与用户确认
- R&K Flow 内的 loop 已写入对应
lead/team-context.md；自定义 loop 已产出独立定义文档 - 已向用户确认 loop 定义全文
- 未越界去执行这个 loop
常见陷阱
- 产出了没有停止条件的 loop（违背"先写刹车"）
- 把一次性任务硬做成 loop
- "进展"判据太宽（写了新内容就算进展，导致无进展检测失效）
- loop-design 自己跑起了这个 loop（应只产出定义）
- 把循环次数、无进展轮数写死，而不是让用户确认