/plan、/grill、/goal：Muse Code 內建技能的完整工作流

/plan — 你點頭之前，什麼都不會動

/plan 會把你交辦的任務轉成一份需要核准才放行的計畫。Agent 先研究儲存庫、拆解工作、提出它打算採取的做法——然後就停下來。你簽核之前，程式碼一個字都不會改。只要不是雞毛蒜皮的小修正，這都是正確的開局：它把「希望 agent 有聽懂我的意思」變成一份你讀得到的文件，並且在誤解只值幾秒鐘的時候就抓出來，而不是等你花一整個下午收拾一場方向錯誤的重構。

/grill — 動手之前，先對計畫嚴刑拷打

/grill 會對計畫進行壓力測試，直到它站得住腳為止。這個名字取得貼切：agent 不會客客氣氣地接受第一版看起來還行的計畫，而是質問自己的做法——邊界情況、隱藏相依、失敗模式——然後反覆修訂，直到計畫熬得過這場拷問。人類工程師在設計審查裡就是這麼做的。大多數 coding agent 完全跳過這一步，然後用一次次重試來還債。如果一份計畫終究要垮，你會希望它垮在紙上。

/goal — 幫你記住終點線在哪

/goal 會朝著你指定的目標推進到成功完成為止——並讓 agent 一路緊盯任務，直到最後合併進去的，就是你當初想要的那個東西。長時間的 agent session 有一種眾所皆知的失敗模式：飄移。五十次工具呼叫之後，agent 正勤勤懇懇地打磨一個跟你要的東西「很像、但不是」的東西。目標制約（goal conditioning）正是為此訓練進 Muse Spark 1.2 的，而 /goal 就是你握住它的那個把手。

兩個配角：/model 與 /effort

另外兩個指令管的是成本，而不是工作流。/model 讓你在 session 中途切換背後的模型——例如切到標準 Model API 定價的 muse-spark-1.2，當你需要「不用於訓練資料」的那一級時（細節在我們的方案比較）。/effort 則負責調高或調低推理深度。Muse Spark 是先思考再回答的模型，而那些思考 token 是按輸出計費的，所以讓推理力道對準任務難度，是你能做的最簡單的一項成本最佳化。

一套可以串起來的工作流

這些技能天生就能接力：用 /plan 規劃功能、用 /grill 拷問計畫、核准之後交給 /goal 扛住執行——同時讓 fan-out 把彼此獨立的部分平行化，事件日誌則把每一步記下來供你事後審查。每個階段都是下一階段的閘門，這正是你希望一套自主系統逐步贏得信任的方式。內建技能的 cookbook 範例把整條管線套在一個真實功能上完整走過一遍；請到 cookbook 找它。