下一步該用哪個 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. 要求輸出成果、證據、未決問題和下一步，不要只收一個沒有需求或驗證依據的就緒標籤。

缺少必要流程或環境時，指出具體相依項目，只繼續獨立工作；不要假裝缺失階段已經執行。缺業務規則就回到需求釐清；缺執行證據就保留驗證缺口。

複製一條聚焦的起步請求

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

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

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

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

下載 Markdown 範本