loop-close

让一件事从"为什么做"走到"有没有用"，再把结论喂给下一件事。骨架统一，深度按类型裁剪，不要给小事套全流程。

0. 开工前

1. 归类：新能力 / 体验修复 / 底座建设 / 分发触达 / Skill 与内容 / 探索实验 / 调研。按 references/types.md 决定每步做多深；拿不准按重的那档。一次性小事（改文案、查一个问题）不用本 Skill，直接做。
2. 找项目规则：先读项目里已有的完成定义、契约、指标口径（通常在 AGENTS.md、CLAUDE.md 或 docs/ 下）。项目规则优先于本 Skill 的通用版。
3. 建事项文件：默认 docs/loop/<事项名>.md，一件事一个文件，八步按顺序在同一份里更新。用户指定位置时按用户的来。

1. 八步

步	回答什么	产出	过关条件
① 定目标	为什么做？支撑什么决定或推动哪个指标？	功能卡（模板）	写清假设、主指标、目标值、失败判定、负责人
② 走通任务	使用者从头到尾怎么用？	任务链路（清单）	每一环标"已有 / 要做 / 不适用"，不留空
③ 定规则	对外的接口、口径、术语是什么？	契约或口径说明	复用项目已有规则，不另起一套
④ 做出来	谁做哪一层？	各层实现与负责人	缺的上游能力列为别人的工作，不在本层绕过
⑤ 验收	真的能用吗？	验收记录	按类型的完成定义全部打勾；涉及扣费的，计费失败场景必须测
⑥ 发布触达	目标使用者怎么知道？	发布说明、案例、通知	一个陌生人照着案例能做出来
⑦ 看数据	有没有用？	上线前基线 + 上线后数据	按真实主体去重（账户、任务），排除内部和测试
⑧ 复盘决策	继续、修、还是砍？	复盘（模板）	写出决定和理由；结论入库；下一件事的 ① 引用它

2. 硬规则

• 没写失败判定不开工；没写决定不收尾。
• 调研也算一件事：开头写"这次要支撑什么决定"，结尾写"采用 / 否定 / 待验证"，不要只交资料汇总。
• 结论必须标注依据：实测 / 源码 / 文档 / 推测。
• 不把"做了"当"有用"：命令量、安装量、页面数不是结果，按 ⑦ 的口径看。

3. 常见坑

• 只做了"执行"一格：功能能跑，但发现、交付、计费、反馈没做，等于半成品。用 ② 的清单逐格过。
• 假成功信号：提交成功不等于交付成功；同一任务被反复查询会让成功数虚高；安装 ID 不等于人。
• 没有基线就上线：上线后的数字无从比较。⑦ 的基线要在上线前取。
• 调研无限扩张：没写要支撑的决定，资料只会越堆越多。卡在 ① 就先补决定。
• 复盘不落地：写了复盘但没改规则、没入库，下次照样踩。⑧ 必须写清"写回了哪里"。

4. 自主边界

• 可以直接做：建和更新事项文件、读项目文档和代码、跑本地只读查询与测试。
• 必须先问：付费调用或生成、对外发布或推送、改线上配置或数据、联系真实用户、删除东西。
• 有证据就反对：发现目标指标和事项不对应、失败判定无法观测、或有更小的做法能验证同一假设时，带着具体证据提出，并给出更小的替代方案。

5. 交接

到对应步骤时交给已安装的专门 Skill，没装就按本 Skill 的模板自己做：

• ② 竞品与同类对照 → 竞品分析类 Skill（如 peerscope）
• ⑤ 让真实外部用户试用 → 外部评测类 Skill（如 eval）
• ⑦ 指标与埋点设计 → product-analytics
• ⑧ 结论入库 → 知识库类 Skill（如 kb-wiki）
• 长任务的交接、续跑、止损 → flowguard

6. 完成检查

一件事算闭环，必须同时满足：

• 事项文件存在，八步里每一步都有产出，或注明"不适用"及原因
• 功能卡里有失败判定，复盘里有决定（继续 / 修 / 停 / 改方向）
• ⑦ 的数据有上线前基线和上线后数值
• 复盘写明结论回写到了哪里

向用户汇报时只说三件事：现在在第几步、过关了没有、下一步是什么。

例子见 references/examples.md。