下一步該用哪個 Coding Skill？

按目前任務選擇 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-Hant/articles/ai-generated-code-acceptance-checklist) 與 [驗證 AI 生成的缺陷修復](/zh-Hant/articles/verify-ai-generated-bug-fix)。

複製一條聚焦的起步請求

以下是示例提示詞，未實際執行：

「使用 $talking-us 釐清此專案的匯出需求。先檢查現有角色和匯出行為，維護確認需求、驗收條件及未決問題。不要實作、修改資料，也不要替我決定未確認的業務規則。」

替換為你的目標和範圍。進入後續階段時，選擇準確 Skill 並提供上文前置條件。請求範本見下方。

以上介紹對應套件內說明，不代表已測得跨模型可靠性。下一步：選出最符合目前阻塞的一句話，開啟對應 Skill 頁面並準備輸入。

下載 Markdown 範本