/plan・/grill・/goal：Muse Code 組み込みスキルの使いどころ

/plan — 承認するまで何も変わらない

/plan は、依頼されたタスクを承認ゲート付きの計画に変換します。エージェントはリポジトリを調査し、作業を分解し、意図するアプローチを提示して — そこで止まります。あなたがサインオフするまでコードは一切変更されません。ちょっとした修正を超えるタスクなら、これが正しい初手です。「エージェントが理解してくれたはず」という願望を、読んで確認できるドキュメントに変換し、誤解を数秒のコストで捕まえられます。見当違いのリファクタリングを丸一日かけて巻き戻す羽目になる前に。

/grill — 実行前の敵対的レビュー

/grill は、計画が持ちこたえるまでストレステストをかけます。名前の通り「炙る」わけです。最初に出てきたそれっぽい計画を礼儀正しく受け入れる代わりに、エージェントは自分のアプローチを尋問します — エッジケース、隠れた依存関係、失敗モード。そして計画がその炙りに耐えられるまで修正を重ねます。人間のエンジニアなら設計レビューでやっていることです。しかし多くのコーディングエージェントはこれを丸ごとスキップし、リトライという形でツケを払っています。計画が崩れるなら、紙の上で崩れてほしいものです。

/goal — ゴールラインを忘れないための仕組み

/goal は、指定した目標の達成に向けて動き続けます。あなたが最初に望んだものが、最終的にマージされるものと一致するまで、エージェントをタスクに縛り付けるのです。長いエージェントセッションには有名な失敗モードがあります。ドリフトです。ツール呼び出しを 50 回重ねた頃には、エージェントは依頼されたものの「隣にある何か」を律儀に磨き上げている。Muse Spark 1.2 のゴール条件付けはまさにこのために訓練されており、/goal はその手綱です。

脇を固める /model と /effort

残る 2 つのコマンドは、ワークフローではなくコストを管理します。/model はセッション途中でバックエンドのモデルを切り替えます。たとえば、訓練データに使われないティアが必要なときに標準の Model API 価格で muse-spark-1.2 に切り替える、といった使い方です（詳細はティア比較の記事にあります）。/effort は推論の深さを上下に調整します。Muse Spark は答える前に考えるモデルで、その思考トークンは出力として課金されるため、タスクの難易度に応じて effort を合わせることが、最も手軽なコスト最適化になります。

組み合わせて機能するワークフロー

これらのスキルは自然に連鎖します。機能を /plan し、その計画を /grill し、承認したら /goal に実行を任せる。独立した部分はファンアウトが並列化し、すべてのステップはイベントログがレビュー用に記録します。各ステージが次のステージへのゲートになる — 自律システムに段階的に信頼を積ませたいなら、まさにこうあってほしい形です。組み込みスキルの cookbook レシピでは、実際の機能開発を通じてこのパイプライン全体を確認できます。クックブックからどうぞ。