Cargando…

Esto está tardando más de lo esperado.

Centro de ayuda AI Toolkit
Ve al sitio web
es en
Volver

Qué hace cada comando

Los diecisiete comandos que instala el toolkit, para qué sirve cada uno y cuál conviene usar en su lugar.

Diecisiete comandos, uno para cada tipo de trabajo

Una vez instalado el toolkit, tu asistente tiene diecisiete comandos. Cada uno cubre un tipo de trabajo y dice en voz alta cuándo el trabajo le corresponde a otro, así que nunca te quedas eligiendo entre dos que se encimen.

Rara vez tienes que escribirlos. Cuando lo que pides coincide con el disparador de un comando, tu asistente lo elige solo: describir una función que quieres construida arranca el comando de implementación sin que lo nombres. Escribir el nombre es cómo anulas esa elección, no cómo la haces.

Si todavía no instalas el toolkit, empieza por Instalar el toolkit.

La pantalla Instrucciones de IA, una tarjeta por comando

Los comandos

Van en el orden en que la mayoría del trabajo los encuentra: decidir qué es el producto, cotizarlo, planearlo, construirlo, comprobarlo, mantenerlo limpio y publicarlo. Los tres últimos trabajan con los comandos y los documentos propios de tu proyecto en el toolkit.

Comando Para qué sirve Usa otro cuando
/vision Deja por escrito las decisiones de producto contra las que se construye el proyecto: a quién sirve, cómo habla, qué nunca hará. Escribir la visión del producto Quieres planear una función, no asentar el producto.
/quote Separa lo que ya existe de lo nuevo y agrupa el trabajo en bloques a los que puedes ponerles precio. Necesitas el enfoque técnico y no la forma de la cotización.
/plan-prompt Resuelve cómo se construiría un cambio y te entrega un prompt de implementación para correr después. Salvo que el cambio sea tan chico que vaya por la ruta directa, el prompt termina con un plan técnico que la construcción sigue como guía, y un cambio que vas a ver se dibuja como está hoy y como quedaría, para que lo apruebes antes de construir nada. Planear antes de construir Lo quieres construido ya, no pensado antes.
/develop Construye el cambio: confirma el alcance, lo implementa, lo valida y lo commitea. Solo quieres el enfoque, o el trabajo ya está planeado y en cola.
/test Abre la pantalla en un navegador real y recorre el plan punto por punto: pasa o falla cada punto, y hay un solo veredicto para el plan. Verificar un plan con /test Quieres la suite de pruebas automatizadas, o una revisión contra los estándares.
/next Corre los planes que ya están en cola y marcados como listos, construyendo y verificando cada uno. Cada plan se construye en su propio worktree, hasta seis en paralelo, y se revisa en el navegador por lotes; solo cuando tu asistente no puede trabajar así va uno a la vez. Toma los planes que guardas o desbloqueas mientras corre, y nunca se detiene a preguntar: una pregunta que solo tú puedes resolver queda escrita en el plan para que la respondas en otra conversación, y el resto de la cola sigue avanzando. Estás describiendo una tarea ahora mismo en lugar de trabajar una cola.
/review Revisa un archivo o un módulo contra los estándares y corrige lo que encuentra. Lo necesita el proyecto entero, o el código todavía no existe.
/cleanup Limpia todo el proyecto en grupos pequeños ya validados, sin cambiar cómo se comporta. Algo está roto y no solo desordenado, o se trata de un solo archivo.
/design-catalog Hace de responsable de diseño del producto: guarda tu manual de identidad, propone el mínimo de componentes, la landing y el rediseño del layout, y escribe los planes por área que /next construye y manda revisar en diseño. No construye nada por sí mismo. Diseñar el catálogo de un producto Lo que hay que cambiar es el estándar compartido, o el proyecto solo necesita orden.
/coordinate Lleva hasta el final un objetivo que necesita cambios en varios repositorios — weblabor-base, weblabor-teams y tu producto —: te entrevista hasta que no queda ninguna duda, escribe el plan que necesita cada repositorio y un último plan que comprueba el objetivo en tu producto, y sigue vigilando cada cola, contestando lo que las bloquea y bajando cada cambio terminado al repositorio de abajo. No construye nada por sí mismo y no sube nada. Coordinar un objetivo entre repositorios El cambio vive en un solo repositorio y no necesita a nadie que lo siga: lo planea /plan-prompt.
/repair-project Repara un proyecto que dejó de funcionar tras un merge, una actualización, una divergencia de rama o una copia. Nada se rompió y solo quieres el código más ordenado.
/document Escribe la documentación de desarrollo de algo ya construido. Lo que falta es la ayuda que lee un usuario, no el manual de desarrollo.
/finish Publica el trabajo: la entrada del changelog cuando estás en la rama principal, más un barrido de lo que se publicó sin la documentación que debía — una edición a mano, o un cambio hecho antes de que todo esto existiera — y la página de características de tu landing al día con lo que se construyó. En la rama principal también borra los planes y los documentos de coordinación cuyo trabajo ya llegó ahí. No pregunta nada: cubre lo que llegó desde la última entrada del changelog, normalmente tu último merge. El trabajo todavía no está construido, o no está verificado.
/improve-toolkit Arregla el toolkit mismo cuando una regla marcó código correcto, dejó pasar código incorrecto o no se siguió. Reportar un hallazgo equivocado El problema está en el código de tu propio proyecto y no en una regla.
/call Ejecuta uno de los comandos internos de tu proyecto: /call <nombre> seguido de la información que recibe. Sin nombre, los lista. El comando todavía no existe, o hay que cambiarlo.
/make-command Construye o cambia uno de los comandos internos de tu proyecto: pregunta solo lo que falta y lo guarda cuando apruebas el texto. Quieres ejecutar el comando, no escribirlo.
/cloud-doc Lee, crea y va guardando un documento de trabajo de tu proyecto en el toolkit: una investigación, un manual de funciones, notas para después. Sin ruta, lista los documentos del proyecto. El documento es documentación del código o un manual de usuario, que siguen en tu repositorio, o es un comando interno.

Los tres que se confunden fácil

/review y /cleanup. Los dos leen código existente contra los estándares. /review responde una pregunta acotada: este archivo, este módulo, este cambio. /cleanup barre el proyecto entero en orden, lleva un registro por archivo para que nada se salte en silencio y commitea cada grupo validado. Si pides un archivo quieres el primero; si pides dejar el proyecto en buena forma quieres el segundo.

/cleanup y /repair-project. /cleanup parte de un proyecto que funciona y lo deja más limpio. /repair-project parte de uno que funcionaba y ya no, lo compara contra una fuente que sí funciona y hace los arreglos más pequeños que lo devuelven a su lugar.

/document y /finish. /document escribe el manual de desarrollo. /finish es lo que corres cuando el trabajo está hecho y probado: escribe la entrada del changelog y barre la historia buscando lo que se publicó sin la documentación que debía, y agrega a la página de características de tu landing lo que todavía no presenta. La documentación de un cambio la escribe /develop en la misma corrida que lo construye; /finish es quien atrapa los que entraron por otro lado. Corrido desde tu rama principal, también borra cada plan cuyos commits ya llegaron ahí, con el dibujo guardado junto a él cuando lo tiene, y los encuentra por el número del plan. Un plan que Borrar finalizados renumeró después de construirse puede quedarse, porque sus commits todavía llevan el número que tenía antes: /finish lo nombra entre los planes que conservó, y tú lo borras a mano cuando su código ya está en tu rama principal. También puede pasar lo contrario, y se describe en Tus proyectos y sus documentos.

A quién le pasa el trabajo cada comando

Un comando le pasa partes de su trabajo a los agentes que se describen en Los agentes detrás de un comando. Esto es a quién llama cada uno. «Si el analizador está caído» marca la revisión suplente, que corre solo cuando no se puede alcanzar el analizador.

Comando Agentes que llama
/vision analyst, documenter
/quote analyst
/plan-prompt analyst, y ux-designer cuando el diseño de un cambio tiene más de un camino
/develop analyst, developer, documenter
/test analyst, ux-designer — ninguno de los dos cuando /next construye sus planes en worktrees
/next developer y documenter por cada plan que construye en un worktree, y luego /test para la revisión en el navegador; solo cuando no hay worktrees va uno a la vez, y corre /develop y /test, que llaman a los suyos. En los dos caminos, ux-designer revisa el diseño de un plan que escribió /design-catalog cuando /test lo aprueba
/review analyst, developer, tech-lead; code-reviewer si el analizador está caído
/cleanup developer; code-reviewer si el analizador está caído
/design-catalog ux-designer
/coordinate analyst
/repair-project developer
/document documenter
/finish documenter
/improve-toolkit workflow-reviewer; code-reviewer si el analizador está caído
/call Ninguno propio; el comando interno que ejecuta puede llegar a los agentes de cualquier comando
/make-command Ninguno
/cloud-doc Ninguno

frontend siempre llama a ux-designer después de implementar algo, así que un comando que llama al primero recibe también al segundo.

Lo que ningún comando hará

Decirlo claro sale más barato que descubrirlo a media corrida:

  • Ningún comando corre un formateador. El formato es de quien mantiene el proyecto. Un comando que encuentra detalles de estilo que le tocan al formateador los clasifica y te dice que habría que correrlo; no lo corre.
  • Ningún comando hace push. Los comandos commitean, por defecto un commit enfocado por cada trabajo terminado, agregando solo los archivos que les pertenecen. El push, las ramas, el amend, el squash y el rebase siguen siendo tuyos salvo que los pidas.
  • Ningún comando destruye una base de datos. Tirarla, vaciarla, truncarla, reiniciarla o refrescarla está prohibido en cualquier entorno, incluso como salida a una cuenta rota. Cuando de verdad hace falta una base limpia, se crea una aparte y tus datos de trabajo se quedan como están.
  • Ningún comando copia los estándares dentro de tu proyecto. Se leen del servidor cuando hacen falta, así que una regla que cambia hoy es la regla que todos los proyectos siguen mañana. Mira Leer los estándares.

Los comandos y documentos propios de tu proyecto

Cada proyecto que conectas tiene en el toolkit un lugar para lo que es suyo y no de su código. Además de los planes, ahí viven dos cosas:

  • Comandos internos. Comandos que solo tiene tu proyecto, escritos por ti con /make-command y ejecutados con /call. Son los mismos en cualquier rama y en cualquier computadora conectada con tu token, y solo tú los ves. Mira Escribir y usar un comando interno.
  • Documentos de trabajo. Cuando le pides a tu asistente que guarde una investigación, un manual de funciones o notas para después, los guarda en el proyecto dentro del toolkit y no como un archivo de tu repositorio; no hace falta que escribas /cloud-doc para eso. Lo que documenta el código sigue en el repositorio: la documentación de desarrollo, las guías de ayuda y el README. Si dices «en el repositorio», se guarda ahí.

Los dos aparecen en la sección Proyectos, dentro de tu proyecto.

Leer un comando en tu propio idioma

El panel lista cada comando y cada agente en Instrucciones de IA del menú lateral — la página se titula Lo que se les indica a los asistentes —, cada uno con las instrucciones completas con las que corre, en el idioma configurado en tu cuenta. Uno que todavía no está traducido se muestra en inglés, con un aviso que lo dice. Esa página es el mismo texto que sigue tu asistente, así que vale la pena abrirla antes de confiarle a un comando algo grande. Configurar el idioma está en Tu perfil y tu idioma.

Tu asistente siempre recibe el original en inglés por la conexión, porque un agente que siguiera una traducción estaría siguiendo un documento que nadie revisó.

Sigue por aquí