do-in-steps

do-in-steps 技能概覽

do-in-steps 技能能幫助 agent 處理複雜工作：把任務拆成有順序的子步驟，逐一執行，並在進入下一步前先驗證每個步驟。當工作有相依關係、涉及多個檔案或系統，或只要少了每一步檢查就很容易出現無聲失敗時，這個 do-in-steps 技能特別實用。

這個 do-in-steps 技能很適合用在 repository 變更、多步驟重構、移轉作業、agent orchestration，以及任何你希望減少假設、讓步驟之間交接更可控的任務。它最大的差異在於內建的 meta-judge → LLM-as-a-judge 流程，會在執行與推進之間加上一道品質關卡。

這個技能適合做什麼

當任務不能安全地一次做完，而且每一步的結果都應該影響下一步時，就適合用 do-in-steps。它的設計目標是讓上下文保持緊湊、維持順序，並在複雜執行中降低連鎖失誤。

它的突出之處

和只會說「一步一步思考」的通用提示不同，do-in-steps 是一個面向 Agent Orchestration 的工作流程技能。它強調任務拆解、依子任務選擇模型、上下文傳遞，以及獨立驗證，因此在較長任務中通常更可靠。

最適合哪些讀者

這份 do-in-steps 指南最適合在 codebase 上工作的 agent、撰寫自動化的人，或需要結構化執行而不是創意發想的使用者。如果你要的是一個有步驟檢查的協調式計畫，而不是單次回應，這個技能會比一次性提示更合適。

如何使用 do-in-steps 技能

安裝並載入技能

進行 do-in-steps install 時，先依照你環境使用的 repository path 加入這個技能，接著把 SKILL.md 載入為主要指令來源。在這個 repo 裡，技能位置是 plugins/sadd/skills/do-in-steps，所以重點是在開始工作前，先把技能檔加入 agent 目前可用的 skills set。

把模糊目標轉成可用輸入

do-in-steps usage 這個模式，在你的 prompt 先包含目標、目標 repo 或系統、限制條件，以及預期完成標準時，效果最好。好的輸入會寫出交付成果與風險點，而不只是主題。

較好的 prompt 範例：
Refactor UserService to remove duplicated validation, update all callers, keep public APIs stable, and verify behavior with tests.
這比下面這種寫法好：
Improve the service layer.

先讀這些檔案

先從 SKILL.md 開始，理解協調邏輯；如果你的安裝環境有曝光其他相關檔案，再去檢查任何被引用的專案文件或相鄰的 skill 檔。在這個 repository 裡，沒有支援性的 rules/、resources/ 或 scripts/ 資料夾，所以主要的操作指引都集中在 skill 檔本身。

以有順序的階段執行

把這個技能當成一個順序式工作流程來用：先分析任務、拆解相依關係、執行第一個子任務、驗證結果，然後只把相關上下文交給下一步。品質提升來自於維持步驟邊界，而不是讓後面的工作偏離前面已做的決策。

do-in-steps 技能 FAQ

do-in-steps 比一般提示更好嗎？

是的，當任務有相依性，或需要在步驟之間做驗證時，特別如此。一般提示可以處理小型工作，但當你需要可控的協調、依子任務選擇模型，以及更少的隱性失敗時，do-in-steps 會更好。

什麼情況下不該用？

如果只是簡單修改、一次性問題，或直接回答就足夠的任務，就不要用 do-in-steps。只有在排序與驗證能實質改善結果時，這套 orchestration 的額外成本才值得。

這個技能適合初學者嗎？

可以，只要你能把任務描述清楚就行。主要學習曲線在於：要提供足夠的上下文讓系統能拆解任務，並接受在繼續之前，工作流程可能會要求中間證據。

它如何融入 Agent Orchestration？

它是明確為 do-in-steps for Agent Orchestration 設計的：由主管協調專門的子 agents，把摘要往下傳，並用獨立 judge 降低每一步的錯誤。這讓它在多 agent 的 coding 或 operations 工作流程中特別有用。

如何改進 do-in-steps 技能

給它更清楚的邊界

改善 do-in-steps 結果最快的方法，就是定義哪些內容不能改、哪些內容必須驗證，以及最後輸出應該長什麼樣。清楚的限制能幫助 orchestrator 選對子任務，並避免返工。

提供會影響決策的關鍵上下文

如果你想要更好的輸出，請一開始就提供受影響的檔案、目標環境、測試預期，以及任何相容性要求。這個技能在能依真實限制拆解任務時表現最好，而不是等到後面才靠推測補齊。

注意常見失敗模式

最大的風險是任務描述不夠具體，導致拆解不紮實或驗證太淺。另一個失敗模式是第一步塞進太多上下文；比較好的做法是先提供足夠資訊讓系統決定計畫，之後讓每個子任務只繼承它真正需要的內容。

在第一次執行後持續迭代

如果第一次結果已經接近，但還不完整，就用具體缺口來修正任務：像是缺少測試、相依順序不清楚，或變更邊界太大。對 do-in-steps 而言，改進通常來自更好的任務框架，而不是要求更多文字。