按当前任务选择 Skill，不必挑名字听起来最强的。产品规则不清楚时用 $talking-us；确认需求后需要技术设计时用 $write-design-doc；设计就绪并获准实现时用 $develop-closed-loop。明确的测试工作用 $test-case，已有故障用 $bug-fixing，具体代码差异的只读审查用 $code-review-multiagent。
这六个 Boloop 流程是面向 Codex 类 Agent 的说明包，不提供模型、浏览器、测试环境、凭据或操作权限。可以直接进入真正需要的阶段，不必把六个全部运行一遍。
“目标有了，但规则还没定”
从 talking-us 开始。它做的是产品需求讨论：检查现状、区分事实与提案、澄清角色和失败恢复，维护需求及验收条件。它的名称并不表示翻译或通用聊天工具。
准备目标、实际项目、可用样本和需要你决定的问题。产出应是带就绪状态及开放问题的需求文档，不是实现代码或技术设计。相关需求明确确认后再交接，不把沉默当批准。
“需求确认了，具体怎么实现？”
选择 write-design-doc。提供权威需求、验收条件、仓库及现有契约。预期得到可实施设计，覆盖适用的开发、数据库、API、交互、恢复及验证细节。
它只编辑设计文档。拟议字段不是已部署结构，提纲也不等于可以实施。完整产品交接会引用 develop-closed-loop 的相关资料；新页面设计按条件需要外部 frontend-design-lab。缺少决策或依赖时，不应声称相应设计已经就绪。
“设计就绪，请实现并验证功能”
使用 develop-closed-loop。提供确认需求、适用设计、允许的代码及测试范围、所需执行环境和数据。它协调实现、测试、修复、回归、审查及需求级证据。
应得到实际变更及范围到证据的记录，而非笼统的“完成”。已实现、本地验证、已部署和线上路径验收是不同状态。独立包不是完整套件，应另装所需阶段的配套 Skill。新建或大幅修改 UI 交互时，按条件需要外部且未附带的 frontend-design-lab。此流程不授权部署或增加功能。
“需要用例、红测交接或验收验证”
选择 test-case，并明确模式：
- design：按确认规则设计用例及覆盖，不执行有副作用的验收
- tdd_handoff：准备获授权的红测交接
- validation：对现有行为执行获授权检查，不新增或修改测试及产品代码
- closed_loop：协调获授权的测试与修复循环
提供预期结果、已有 REQ/AC 引用、角色、版本、数据及允许的副作用。模式名本身不授予权限。预期得到可追溯用例及实际 PASS、FAIL、BLOCKED、NOT RUN 或有依据的 N/A。缺少规则继续列为问题；Mock、零测试收集及未解释跳过不等于整体验收通过。
“已有故障，需要定位并验证修复”
使用 bug-fixing。提供原始入口、输入、预期与实际结果、版本、日志和允许范围。它沿真实失败路径定位，检查相关影响，并在获准修复时验证最小修复。
只需诊断就明确说。输出应把原因、变更及前后证据对应起来，同时列出缺口和回滚。无法复现时根因可能仍是暂定结论；验证修复仍需要对缺陷敏感的回归信号。不要用它悄悄替新功能决定业务规则。
“已有补丁，请独立审查”
选择 code-review-multiagent。提供准确基线和目标、当前差异、需求及已有证据。它是只读流程，会追踪调用方，检查实现、需求及适用风险边界。
尽管名称包含 multiagent，默认是深入 Solo 审查。独立 Agent 取决于复杂度及宿主能力。预期得到有证据、可行动的问题，或限定范围的“未发现可证实缺陷”，运行时缺口单独列出。没有差异就不能审查候选实现。它不自动修复，也不能凭静态证据证明浏览器可用或部署成功。
合成示例：增加导出，再排查故障
这是虚构规划示例，不是已执行项目，也没有效果数据。
若导出请求的所有权和格式还未确定，从 talking-us 开始。规则确认后，write-design-doc 定义契约及恢复；之后 develop-closed-loop 可协调获授权实现、测试及审查，按需使用配套流程。代码出现前，也可以独立用 test-case 设计覆盖。
若现有导出已经失败，直接带原始失败证据进入 bug-fixing。若只需只读评估补丁，直接进入 code-review-multiagent。交接由缺少的证据或工作决定，不是必须走完的六步仪式。
第一次调用前
- 阅读所选包的说明和依赖。安装合集时，保留六个 Skill 文件夹及同级 shared 文件夹的相对结构，放入支持的本地 Skills 目录；单独 ZIP 保留内部 shared 资源。覆盖前备份同名安装，避免重复。
- 确认宿主提供任务所需工具。真实 UI 验收需要真实浏览器或目标应用，说明包不能补出访问能力。
- 写清目标、权威来源、允许变更、环境、数据和禁止副作用。使用准确的 $skill-name，并另装所需配套流程。
- 要求输出成果、证据、未决问题和下一步，不要只收一个没有需求或验证依据的就绪标签。
缺少必要流程或环境时，指出具体依赖，只继续独立工作；不要假装缺失阶段已经执行。缺业务规则就回到需求澄清；缺运行证据就保留验证缺口。
复制一条聚焦的起步请求
以下是示例提示词，未实际执行：
“使用 $talking-us 澄清此项目的导出需求。先检查现有角色和导出行为，维护确认需求、验收条件及未决问题。不要实现、修改数据，也不要替我决定未确认的业务规则。”
替换为你的目标和范围。进入后续阶段时，选择准确 Skill 并提供上文前置条件。请求模板见下方。
以上介绍对应包内说明，不代表已测得跨模型可靠性。下一步：选出最符合当前阻塞的一句话，打开对应 Skill 页面并准备输入。
880 文章浏览
记录符合条件的页面浏览并过滤短期重复，不代表独立读者人数。