/plan, /grill, /goal: o fluxo de skills que já vem com o Muse Code
O pitch de uma linha da Meta para as skills embutidas do Muse Code: entra uma ideia crua, sai uma funcionalidade testada no fogo e com o gosto conferido. Veja o que cada comando faz de verdade e quando usar cada um.
/plan — nada muda até você aprovar
O /plan transforma uma tarefa pedida em um plano condicionado à sua aprovação. O agente estuda o repositório, decompõe o trabalho e apresenta a abordagem que pretende seguir — e então para. Nenhuma mudança de código até você dar o aval. Para qualquer coisa além de um ajuste trivial, essa é a jogada de abertura correta: ela converte “tomara que o agente tenha me entendido” em um documento que você pode ler, e pega mal-entendidos quando eles custam segundos, e não uma tarde inteira desfazendo um refactor que nasceu errado.
/grill — revisão adversarial antes da execução
O /grill submete o plano a um teste de estresse até ele se sustentar. O nome é bem escolhido: em vez de aceitar educadamente o primeiro plano com cara de plausível, o agente interroga a própria abordagem — casos de borda, dependências escondidas, modos de falha — e revisa até o plano sobreviver ao interrogatório. Engenheiros humanos fazem isso em design review. A maioria dos agentes de código pula essa etapa por completo e paga o preço em retentativas. Se um plano vai desmoronar, é melhor que desmorone no papel.
/goal — a linha de chegada, sem sair da memória
O /goal trabalha rumo à conclusão bem-sucedida do objetivo que você especifica — e mantém o agente na tarefa até que o que você pediu originalmente seja o que entra no merge. Sessões longas de agente têm um modo de falha bem conhecido: a deriva. Cinquenta chamadas de ferramenta depois, o agente está polindo com todo o zelo algo adjacente — mas não exatamente — ao que você pediu. O condicionamento por objetivo foi treinado no Muse Spark 1.2 exatamente para isso, e o /goal é a alça pela qual você segura esse mecanismo.
O elenco de apoio: /model e /effort
Mais dois comandos cuidam de custo, não de fluxo de trabalho. O /model troca o modelo por trás no meio da sessão — por exemplo, para o muse-spark-1.2 no preço padrão da Model API quando você precisa da faixa sem uso de dados para treinamento (os detalhes estão no nosso comparativo de planos). O /effort regula a profundidade de raciocínio para cima ou para baixo. O Muse Spark pensa antes de responder, e esses tokens de raciocínio são cobrados como saída — então calibrar o esforço pela dificuldade da tarefa é a otimização de custo mais fácil que existe.
Um fluxo que se encaixa
As skills se encadeiam com naturalidade: /plan na funcionalidade, /grill no plano, aprovação sua, e depois o /goal conduz a execução — com o fan-out paralelizando as partes independentes e o event log registrando cada passo para revisão. Cada estágio serve de portão para o próximo, que é exatamente como você gostaria que um sistema autônomo conquistasse confiança aos poucos. A receita de bundled skills no cookbook mostra o pipeline inteiro em uma funcionalidade real; procure no cookbook.