按当前任务选择 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。交接由缺少的证据或工作决定，不是必须走完的六步仪式。

第一次调用前

  1. 阅读所选包的说明和依赖。安装合集时，保留六个 Skill 文件夹及同级 shared 文件夹的相对结构，放入支持的本地 Skills 目录；单独 ZIP 保留内部 shared 资源。覆盖前备份同名安装，避免重复。
  2. 确认宿主提供任务所需工具。真实 UI 验收需要真实浏览器或目标应用，说明包不能补出访问能力。
  3. 写清目标、权威来源、允许变更、环境、数据和禁止副作用。使用准确的 $skill-name，并另装所需配套流程。
  4. 要求输出成果、证据、未决问题和下一步，不要只收一个没有需求或验证依据的就绪标签。

缺少必要流程或环境时，指出具体依赖，只继续独立工作；不要假装缺失阶段已经执行。缺业务规则就回到需求澄清；缺运行证据就保留验证缺口。

这些 Skill 加载在哪里？Codex 与 Claude Code

这六套 Boloop 包是面向 Codex 风格代理的指令工作流。它们本身不是托管模型、浏览器，也不等于授权。同一套 SKILL.md 目录可以按 Agent Skills 开放格式被不同宿主发现，但目录路径和按名称调用的方式并不相同。

Codex（OpenAI 文档）

Codex 从当前工作目录向上到仓库根目录扫描 .agents/skills，个人技能在 $HOME/.agents/skills。技能目录需要带 name 与 description 的 SKILL.md。在 CLI/IDE 里可用 /skills 或输入 $ 点名技能；任务描述匹配时也可被隐式选用。来源：Build skills（OpenAI，2026-11-06 查阅）。

Claude Code（官方文档）

Claude Code 的 skills 遵循同一套 Agent Skills 思路。项目技能在 .claude/skills/<name>/SKILL.md，个人技能在 ~/.claude/skills/<name>/SKILL.md。用 /skill-name 直接调用，或在请求匹配 description 时由 Claude 自动加载；正文只在使用该技能时载入。来源：Extend Claude with skills（Claude Code 文档，2026-11-06 查阅）。

对 Boloop 六套 Skill 的含义

  • 在 Codex 风格宿主上，文中的 $talking-us 一类写法对应 $ / 技能选择器显式调用。
  • 在 Claude Code 上，同样文件夹名通常写成 /talking-us（或以 frontmatter 的 name 为准），前提是文件已放在 .claude/skills/ 下。
  • 共享一份文件树时，一般是保留单份技能目录，再链接或复制到各宿主要求的路径——相同 Markdown 不等于相同运行时行为（工具、hooks、扩展字段不同）。
  • Boloop 没有声称已在 Claude Code 内对这六套包做过通过率测评。宿主差异来自厂商文档中的配置事实，不是本站实测结论。

常见选错（请重选）

对准当前阻塞点，不要选名字最“大”的 Skill。

  • 规则、角色或失败恢复仍未定 → 用 $talking-us，不要直接 $develop-closed-loop。
  • 需求已确认但可落地的设计还没有 → $write-design-doc，不要直接实现。
  • 设计已有且允许改动的范围清楚 → $develop-closed-loop（按需要安装配套阶段技能）。
  • 先要用例或红测交接再写代码 → $test-case。
  • 已经失败、需要可验证的修复 → $bug-fixing。
  • 已有补丁、需要独立审查 → $code-review-multiagent。

若两个都像合适，优先更靠前的阶段。跳过澄清不会自动获得实现授权。

FAQ

每次都必须跑完六套吗？

不必。从你真正需要的阶段进入即可。六套是地图，不是强制流水线。

安装 Skill 会不会自动带上凭证或上线权限？

不会。Skill 是指令包。凭证、浏览器、测试环境和改生产的权限仍由你控制。

能在 Claude Code 上像 Codex 一样用吗？

可以把 Agent Skills 格式的 SKILL.md 放到 Claude Code 查找的目录（.claude/skills/…），再用 /name 调用（见 Claude Code 文档）。Codex 使用 .agents/skills 与 $name / /skills。具体行为仍取决于各宿主的工具与设置；本文不断言 Boloop 已在 Claude Code 上验证全部六套包。

实现之后用什么做验收？

单独做验收：需求映射到检查项、证明测试能失败、核对用户可见路径。见 [AI 生成代码审查与验收清单](/zh-Hans/articles/ai-generated-code-acceptance-checklist) 与 [验证 AI 生成的缺陷修复](/zh-Hans/articles/verify-ai-generated-bug-fix)。

复制一条聚焦的起步请求

以下是示例提示词，未实际执行：

“使用 $talking-us 澄清此项目的导出需求。先检查现有角色和导出行为，维护确认需求、验收条件及未决问题。不要实现、修改数据，也不要替我决定未确认的业务规则。”

替换为你的目标和范围。进入后续阶段时，选择准确 Skill 并提供上文前置条件。请求模板见下方。

以上介绍对应包内说明，不代表已测得跨模型可靠性。下一步：选出最符合当前阻塞的一句话，打开对应 Skill 页面并准备输入。

下载 Markdown 模板

886 文章浏览

记录符合条件的页面浏览并过滤短期重复，不代表独立读者人数。