/plan, /grill, /goal: el flujo de trabajo con las skills integradas
El pitch de una línea de Meta para las skills incluidas en Muse Code: metes una idea a medio cocer y sale una feature interrogada a fondo y con control de calidad. Esto es lo que hace cada comando y cuándo conviene usarlo.
/plan — nada cambia hasta que tú apruebes
/plan convierte la tarea que pides en un plan que requiere tu aprobación. El agente estudia el repositorio, descompone el trabajo y presenta el enfoque que pretende seguir — y entonces se detiene. Nada de cambios en el código hasta que des el visto bueno. Para cualquier cosa que vaya más allá de un arreglo trivial, este es el movimiento de apertura correcto: convierte el “espero que el agente me haya entendido” en un documento que puedes leer, y caza los malentendidos cuando cuestan segundos, no una tarde entera deshaciendo un refactor mal planteado.
/grill — revisión adversarial antes de ejecutar
/grill somete el plan a presión hasta que aguanta. El nombre le va que ni pintado: en lugar de aceptar educadamente el primer plan con pinta plausible, el agente interroga su propio enfoque — casos límite, dependencias ocultas, modos de fallo — y lo revisa hasta que el plan sobrevive al interrogatorio. Los ingenieros humanos hacen esto en las design reviews. La mayoría de agentes de código se lo saltan por completo y lo pagan en reintentos. Si un plan se va a caer, quieres que se caiga sobre el papel.
/goal — la meta, sin olvidarla
/goal trabaja hacia la consecución del objetivo que especificas — y mantiene al agente centrado hasta que lo que acaba en el merge es lo que pediste originalmente. Las sesiones largas de agente tienen un modo de fallo bien conocido: la deriva. Cincuenta llamadas a herramientas después, el agente está puliendo diligentemente algo adyacente a lo que pediste, pero que no es exactamente lo que pediste. El condicionamiento por objetivos se entrenó en Muse Spark 1.2 precisamente para esto, y /goal es el asidero con el que lo sujetas.
Los secundarios: /model y /effort
Dos comandos más gestionan el coste, no el flujo de trabajo. /model cambia el modelo subyacente a mitad de sesión — por ejemplo a muse-spark-1.2 con el precio estándar de la Model API cuando necesitas el nivel sin datos de entrenamiento (los detalles están en nuestra comparativa de niveles). /effort sube o baja la profundidad de razonamiento. Muse Spark piensa antes de responder y esos tokens de pensamiento se facturan como salida, así que ajustar el esfuerzo a la dificultad de la tarea es la optimización de coste más sencilla que existe.
Un flujo de trabajo que compone
Las skills se encadenan con naturalidad: /plan para la feature, /grill para el plan, lo apruebas, y dejas que /goal lleve la ejecución — con el fan-out paralelizando las partes independientes y el event log registrando cada paso para revisarlo después. Cada etapa es la puerta de la siguiente, que es exactamente como querrías que un sistema autónomo se ganara tu confianza poco a poco. La receta del cookbook sobre las skills integradas muestra el pipeline completo con una feature real; la encuentras en el cookbook.