Si ya usas Antigravity, seguramente resuelves buena parte del trabajo escribiendo instrucciones en el chat. Le explicas qué necesitas, revisas lo que propone y vas ajustando. Pero hay otra forma de dirigir al agente sin repetir cada vez cómo quieres que trabaje: los comandos que aparecen al escribir una barra diagonal.
La diferencia es sencilla. No siempre necesitas que el agente programe. A veces quieres revisar una propuesta, aclarar una decisión, hacer una consulta aparte o comprobar una interfaz sin modificarla. Si todo lo pides como un encargo de construcción, estás mezclando tareas que conviene separar.
Los nueve comandos que vamos a recorrer son /plan, /grill-me, /goal, /btw, /learn, /browser, /schedule, /boost y /teamwork-preview. Cada uno tiene un momento útil. No hace falta utilizarlos todos en cada proyecto.
Para entenderlos, voy a trabajar con un cotizador de páginas web. Es un ejemplo pequeño a propósito: dos tipos de web, tres extras y un total que cambia con la selección. Así podemos concentrarnos en lo importante: qué pedir, con qué comando y cómo comprobar que quedó listo.
Tabla de contenido
- 🧭 Cómo usar los comandos de Antigravity
- 📝 1. /plan: revisar la propuesta antes de construir
- ❓ 2. /grill-me: convertir una idea general en decisiones concretas
- 🎯 3. /goal: llevar un objetivo hasta las comprobaciones definidas
- 💬 4. /btw: resolver una duda sin convertirla en otro encargo
- 🧮 El resultado: un cotizador que podemos comprobar
- 🧠 5. /learn: conservar una preferencia para los próximos cambios
- 🌐 6. /browser: pedir pruebas concretas de una interfaz
- ⏰ 7. /schedule: volver a una instrucción más tarde
- 🔎 8. /boost: una opción para problemas difíciles
- 👥 9. /teamwork-preview: organizar proyectos grandes entre agentes
- ✅ Qué comando elegir según el trabajo que tienes delante
🧭 Cómo usar los comandos de Antigravity
El funcionamiento básico es el mismo para todos: escribes / en el chat, eliges el comando y añades la petición concreta para tu proyecto. El comando indica la forma de trabajo; el texto que lo acompaña define lo que necesitas.
Por eso, elegir un comando no sustituye una buena instrucción. Seleccionar /browser no explica qué botones hay que probar. Elegir /goal tampoco define por sí solo cuándo una tarea está terminada. Esa parte sigue siendo nuestra.
Una forma práctica de preparar cualquier petición es responder tres preguntas:
- ¿Qué necesito ahora? Una propuesta, una decisión, una implementación, una explicación o una prueba.
- ¿Sobre qué debe trabajar? El proyecto, una función concreta, una página local o una preferencia.
- ¿Qué resultado espero? Un plan revisable, una aplicación funcionando, un informe o una regla reutilizable.
En el cotizador vamos a pasar por varias de esas situaciones. Primero definiremos el trabajo. Después resolveremos una ambigüedad, construiremos la página y comprobaremos su comportamiento. Más adelante conservaremos una decisión para los siguientes cambios.
No es una secuencia obligatoria. Es una manera de distinguir tareas que, cuando se mezclan en un solo mensaje, resultan más difíciles de revisar.
📝 1. /plan: revisar la propuesta antes de construir
/plan sirve para preparar el trabajo y revisar la propuesta antes de pasar a la implementación. Lo usaría cuando ya tengo una idea del resultado, pero quiero comprobar cómo la ha entendido el agente.
Partimos de un proyecto en blanco en la aplicación de escritorio. Para el cotizador, la petición puede quedar así:
/plan Prepara un cotizador web en español, de una sola página. Debe permitir elegir entre una landing y una web corporativa, seleccionar tres extras, actualizar el total y reiniciar la selección. Utiliza HTML, CSS y JavaScript sin dependencias. Usa precios de ejemplo en dólares enteros, sin impuestos.
Es una instrucción breve, pero ya delimita bastante el proyecto. Define el idioma, el tamaño de la aplicación, las opciones principales, la tecnología y la forma de presentar los precios.
El plan aparece en un documento que podemos abrir junto al chat. Eso permite leerlo como una propuesta de trabajo, no como una respuesta que hay que aceptar de inmediato. Aquí todavía estamos a tiempo de añadir algo que falta o corregir una interpretación.
Qué conviene revisar en el plan
Para este ejemplo, me interesa comprobar que estén los dos tipos de web, los tres extras, el total actualizado y el reinicio. También que se respeten las restricciones: una sola página y ninguna dependencia.
Hay una diferencia importante entre describir una función y definir su comportamiento. “Botón de reinicio” parece claro, pero necesitamos saber a qué estado vuelve. En nuestro caso, debe recuperar la landing sin extras, con su precio inicial.
El valor de planificar está en descubrir esas decisiones antes de programar. No se trata de producir un documento largo. Se trata de tener una propuesta que puedas revisar y utilizar después como referencia.
De hecho, al revisar este cotizador aparece una necesidad nueva: quiero poder copiar el presupuesto para compartirlo. Esa frase todavía deja varias decisiones abiertas. Para resolverlas, pasamos al siguiente comando.
❓ 2. /grill-me: convertir una idea general en decisiones concretas
/grill-me resulta útil cuando sabes qué quieres conseguir, pero todavía no has definido todos los detalles. En lugar de pedirle al agente que rellene esos huecos por su cuenta, le pides que te haga preguntas.
La instrucción inicial es muy corta:
/grill-me Quiero poder copiar y compartir el presupuesto.
“Compartir” puede significar varias cosas. Podría ser copiar un texto, preparar un correo o utilizar otro mecanismo. Si no elegimos uno, la implementación puede resolver un problema distinto al que teníamos en mente.
En este caso, el agente plantea tres decisiones, una a la vez.
Primera decisión: cómo compartirlo
Elijo copiar un texto al portapapeles. Después podré pegarlo en un correo o en un mensaje. Para este cotizador no necesito convertir la función en un sistema de envío: basta con generar un resumen que se pueda reutilizar fuera de la página.
Segunda decisión: qué datos incluir
El texto debe contener el tipo de web con su precio, los extras seleccionados con sus importes y el total en dólares. No quiero copiar únicamente una cifra. Quiero que el presupuesto se entienda por sí solo.
Tercera decisión: cómo confirmar la acción
Elijo un mensaje temporal en el mismo botón. Así queda definido también cómo sabrá la persona que utiliza el cotizador que el presupuesto se ha copiado.
Con esas respuestas, el agente actualiza el plan sin construir todavía. Hemos pasado de una frase general a tres decisiones concretas: el mecanismo para compartir, el contenido del resumen y la confirmación de la acción.
Usaría /grill-me cuando una función parece clara hasta que intentas explicar exactamente cómo debe comportarse. Es especialmente útil antes de implementar, porque permite completar la idea sin mezclar la conversación de decisiones con los cambios de código.
También conviene mantener el foco. Aquí la duda era cómo copiar y compartir el presupuesto. No hacía falta reabrir todas las decisiones del cotizador. Aclarar una función concreta ya era suficiente para continuar.
🎯 3. /goal: llevar un objetivo hasta las comprobaciones definidas
Una vez revisado el plan, toca ejecutar. Para eso usamos /goal: le damos un objetivo al agente y le pedimos que siga trabajando hasta completarlo.
Como los requisitos ya están en el plan, no necesito volver a escribir toda la descripción:
/goal Implementa el plan revisado y deja el cotizador funcionando en local.
La brevedad funciona porque antes hicimos el trabajo de definición. El agente ya tiene una referencia con las funciones y las comprobaciones previstas. La instrucción corta no significa que el encargo esté poco definido; significa que no estamos duplicando información.
En este ejemplo, el agente crea los archivos y, al terminar, entrega la dirección local junto con un resumen de lo que probó. Ese es un resultado que podemos revisar: una página accesible y una explicación de las comprobaciones realizadas.
“Implementado” y “comprobado” no son lo mismo
Aunque el agente indique que terminó, abro la página y compruebo a mano los botones y los cálculos. Es importante mantener esa revisión: queremos confirmar el comportamiento de la aplicación, no quedarnos solo con el resumen del trabajo.
El objetivo tampoco debería ser algo tan abierto como “deja todo perfecto”. Para el cotizador tenemos condiciones reconocibles: elegir el tipo de web, añadir extras, obtener el total correcto, copiar el desglose y volver al estado inicial.
Cuanto mejor definida esté la llegada, más fácil será revisar si el objetivo se cumplió. Esa es la relación entre /plan y /goal: el primero prepara una propuesta; el segundo lleva el trabajo hacia el resultado acordado.
No necesitas usar ambos para cada ajuste pequeño. Pero cuando hay varias funciones relacionadas, separar preparación y ejecución ayuda a saber qué estás aprobando y qué estás pidiendo construir.
💬 4. /btw: resolver una duda sin convertirla en otro encargo
Mientras el agente construye el cotizador, puede aparecer una pregunta que no requiere cambiar nada. Para esa situación está /btw. El nombre viene de “by the way”, que significa “por cierto”.
La consulta del ejemplo es esta:
/btw ¿Qué ventaja tiene utilizar JavaScript sin un framework para un cotizador tan pequeño?
La respuesta aparece en un panel aparte. Podemos leerla, cerrar el panel y volver al trabajo principal, que continúa mientras hacemos la consulta.
Lo importante aquí es la separación: la pregunta no se convierte en un nuevo encargo para el proyecto. Estamos pidiendo una explicación sobre una decisión técnica, no solicitando que el agente cambie la tecnología.
Esa distinción parece pequeña, pero ayuda mucho al trabajar con IA. Una duda sobre una alternativa no equivale a una orden para implementarla. Preguntar por qué se eligió JavaScript sin framework no significa que queramos introducir uno.
Usaría /btw cuando quiero entender algo sin desviar la tarea en curso. Si después de leer la respuesta decido cambiar el proyecto, ese cambio merece una petición explícita. Así queda claro qué parte de la conversación es aprendizaje y qué parte autoriza trabajo nuevo.
🧮 El resultado: un cotizador que podemos comprobar
Con la implementación lista, ya tenemos un ejemplo concreto para validar. Los importes son de demostración, están expresados en dólares enteros y no incluyen impuestos.
La comprobación manual sigue una secuencia sencilla:
- La landing sin extras muestra un total de 300 dólares.
- Al elegir la web corporativa, el importe base cambia a 700 dólares.
- Con el primer extra seleccionado, el total pasa a 850 dólares.
- Al añadir el segundo, aumenta a 950 dólares.
- Con los tres extras activos, llega a 1.000 dólares.
- El botón de copiar genera el desglose del presupuesto.
- El botón de reiniciar recupera la landing sin extras y el total de 300 dólares.
Esta secuencia permite comprobar varias cosas sin complicar el proyecto: que cambia el precio base, que se suman los extras, que la copia responde y que el reinicio recupera el estado esperado.
No basta con que la página tenga buen aspecto. El total y el texto copiado deben representar la misma selección. Esa relación nos llevará enseguida a una regla útil para mantener el proyecto.
Y si estás creando webs con IA y necesitas recursos visuales para tus proyectos, en Dínamo Sites tienes secciones web animadas. Es un recurso para la parte visual; aquí seguimos centrados en cómo dirigir al agente y revisar su trabajo.
🧠 5. /learn: conservar una preferencia para los próximos cambios
Hay decisiones que no queremos resolver una y otra vez. En el cotizador, una de ellas es cómo organizar los precios para que resulte fácil modificarlos y para que no haya diferencias entre el total y el presupuesto copiado.
Primero pido el cambio con un mensaje normal:
Reúne todos los precios en un único lugar para poder actualizarlos fácilmente. Utiliza esos mismos valores al calcular el total y al copiar el presupuesto. Si ya está organizado así, indícame dónde se modifican.
El agente hace un ajuste y reúne los precios en una configuración al comienzo del archivo de JavaScript. Tanto el cálculo como el texto copiado toman sus valores de ahí.
El cambio resuelve la situación actual. Pero ahora quiero que esa decisión también guíe los próximos cambios del proyecto. Para eso utilizo /learn.
/learn En este proyecto, utiliza la misma configuración de precios para calcular el total y generar el presupuesto copiado.
Modificar el proyecto y guardar una regla son dos tareas distintas
El mensaje normal pide organizar el código que existe. /learn propone convertir esa preferencia en una instrucción reutilizable. En este caso, la propuesta consiste en guardarla en GEMINI.md, un archivo de instrucciones del proyecto.
Antes de aceptar, reviso dos aspectos: que el alcance sea este proyecto y que la regla refleje lo que pedí. No quiero guardar una instrucción más amplia de lo necesario ni una versión ambigua de la decisión.
La regla útil no es “gestiona bien los precios”. Es algo concreto: el cálculo y la copia deben utilizar la misma configuración. Así queda claro qué relación queremos conservar.
Usaría /learn cuando una preferencia ya está decidida y tiene sentido mantenerla en futuras tareas. No para guardar cualquier comentario de la conversación. Lo importante es conservar decisiones que realmente deban orientar el trabajo posterior.
Además, la regla no sustituye las pruebas. Aunque esté escrita, seguiremos comprobando que los importes mostrados y copiados coincidan.
🌐 6. /browser: pedir pruebas concretas de una interfaz
Con /browser podemos pedir al agente que abra una página y compruebe acciones determinadas. La clave está en darle la dirección y explicar qué debe probar.
Para nuestro ejemplo, el encargo puede ser este, añadiendo la dirección local que haya entregado la implementación:
/browser Abre el cotizador en su dirección local y comprueba los tipos de web, los extras, los totales, la copia del presupuesto y el reinicio. Revisa también la interfaz con un ancho móvil de 390 píxeles y entrega capturas con los resultados. Solo prueba e informa.
La última frase es importante. Si ahora quiero una revisión, lo digo expresamente: solo probar e informar. No estoy autorizando cambios mientras se realiza la comprobación.
Qué hace útil una petición de pruebas
“Revisa la página” deja demasiado abierto el encargo. En cambio, enumerar los tipos de web, los extras, el total, la copia y el reinicio conecta la prueba con las funciones que realmente hemos construido.
También especificamos una condición visual concreta: un ancho de 390 píxeles. Eso da una referencia para revisar la interfaz en móvil, en lugar de dejar “comprueba que sea adaptable” como una indicación general.
Y pedimos evidencia: capturas y resultados. Queremos poder revisar qué ocurrió, no recibir únicamente una afirmación de que todo funciona.
Conviene distinguir qué evidencia corresponde a cada comprobación. Una captura puede mostrar la selección y el total, pero comprobar la función de copia también requiere revisar el contenido generado. Del mismo modo, probar el reinicio supone confirmar el estado al que vuelve la página.
/browser complementa la revisión manual que hicimos antes. Nos permite encargar una ronda de pruebas con un alcance definido y decidir después qué hacer con los problemas que se encuentren.
⏰ 7. /schedule: volver a una instrucción más tarde
/schedule permite programar una instrucción para más adelante. En este recorrido lo utilizo para un recordatorio sencillo:
/schedule En un minuto, recuérdame revisar la regla de precios del cotizador.
Primero aparece el temporizador pendiente. Mientras pasa ese minuto, podemos seguir revisando otras opciones. Cuando se cumple el tiempo, llega el aviso en la misma conversación y nos recuerda la regla que habíamos preparado.
Este ejemplo ayuda a distinguir dos necesidades que pueden parecer similares. Con /learn queremos conservar una instrucción del proyecto. Con /schedule queremos volver a una acción en un momento posterior.
Guardar la regla no significa revisarla automáticamente más tarde. Programar un recordatorio tampoco convierte su contenido en una regla permanente. Cada comando resuelve una parte distinta.
Para escribir una petición clara, basta con indicar cuándo debe llegar el aviso y qué debe recordar. En este caso, el resultado esperado es un mensaje en la conversación. No una modificación del cotizador ni una nueva implementación.
🔎 8. /boost: una opción para problemas difíciles
Las siguientes dos opciones están pensadas para trabajos más complejos. No las ejecuto en el cotizador, porque un ejemplo tan pequeño no necesita abrir ese nivel de trabajo.
La descripción de /boost indica que puede recurrir a un conjunto de agentes para abordar una tarea difícil. Un posible encargo sería investigar un fallo intermitente:
/boost Investiga por qué el total de una aplicación a veces deja de actualizarse cuando cambio varias opciones rápidamente. Contrasta las posibles causas y verifica la solución.
Este es un ejemplo hipotético, no una prueba realizada. El cotizador que hemos comprobado no se presenta aquí como una aplicación con ese fallo.
La situación sirve para entender cuándo podría tener sentido el comando: hay un comportamiento difícil de explicar y necesitamos investigar, probar posibles causas y comprobar la corrección.
Fíjate en que el encargo no termina en “encuentra el error”. Incluye verificar la solución. Si el problema aparece al cambiar opciones rápidamente, esa condición debe formar parte de la comprobación posterior.
No elegiría /boost solo porque suene más potente. Lo reservaría para una dificultad que justifique ese enfoque. Para una modificación pequeña y bien definida, conviene mantener el trabajo igual de acotado.
👥 9. /teamwork-preview: organizar proyectos grandes entre agentes
/teamwork-preview aparece en el menú como una opción para abordar proyectos grandes con un equipo de agentes. Aquí la idea no es únicamente investigar un problema difícil, sino organizar un trabajo que se puede repartir.
Un ejemplo sería una reorganización amplia de una aplicación:
/teamwork-preview Organiza la migración de una aplicación grande a una estructura nueva. Distribuye la investigación, los cambios y las pruebas entre agentes, y define qué debe entregar cada uno.
Este encargo también queda como ejemplo sin ejecutar. No necesitamos repartir el cotizador entre varios agentes para entender los otros comandos.
La parte más importante de la petición es definir las entregas. Decir “trabajad en equipo” no explica qué debe investigar cada agente, qué cambios le corresponden ni cómo se revisará el resultado conjunto.
Repartir trabajo exige dejar claras las responsabilidades y las comprobaciones. En una migración, por ejemplo, el encargo ya distingue investigación, implementación y pruebas. Esa separación ayuda a expresar qué esperamos de cada parte.
La elección frente a /boost depende del tipo de necesidad: un problema difícil que requiere investigación o un proyecto grande cuyo trabajo conviene organizar entre agentes. No son pasos obligatorios después de /goal.
✅ Qué comando elegir según el trabajo que tienes delante
No hace falta memorizar los nueve como una lista de funciones. Es más útil relacionarlos con la situación concreta en la que estás:
- Necesitas revisar una propuesta antes de construir:
/plan. - Tienes una idea con decisiones pendientes:
/grill-me. - Ya definiste el resultado y quieres ejecutarlo:
/goal. - Quieres resolver una duda aparte:
/btw. - Quieres conservar una preferencia del proyecto:
/learn. - Necesitas probar una interfaz:
/browser. - Quieres recibir un recordatorio más tarde:
/schedule. - Tienes un problema difícil que merece más investigación: considera
/boost. - El proyecto es grande y necesita reparto de trabajo: considera
/teamwork-preview.
En el cotizador, el recorrido principal fue preparar el plan, aclarar cómo compartir el presupuesto y ejecutar el objetivo. La consulta aparte no cambió el encargo. Después organizamos los precios y convertimos esa decisión en una regla para el proyecto.
Las pruebas y el recordatorio respondían a necesidades diferentes. Y las opciones de varios agentes quedaron fuera de la ejecución porque no hacían falta. Elegir bien también significa saber cuándo no utilizar un comando.
Empieza con una tarea concreta y una comprobación
Puedes aplicar este recorrido a un proyecto que ya tengas. No necesitas rehacerlo desde cero. Elige una función pendiente, identifica qué necesitas resolver ahora y utiliza el comando correspondiente.
Antes de enviar la petición, añade cómo vas a comprobar que quedó lista. En nuestro ejemplo no pedimos solamente “un cotizador”: definimos selecciones, importes, copia y reinicio. Eso nos dio una forma clara de revisar el resultado.
Si quieres seguir aprendiendo, hacer preguntas y compartir lo que estás construyendo, te espero en Círculo Builders. Ahí puedes mostrar tus avances y conversar conmigo sobre tus proyectos con IA.
Quédate con esta idea: los comandos de Antigravity sirven para elegir cómo debe trabajar el agente. Tú sigues definiendo el proyecto, las decisiones importantes y las condiciones para dar el trabajo por terminado.
