Tu asistente, trabajando como trabaja tu equipo
Comandos para planear, construir, revisar, reparar y publicar, cada uno entregando el trabajo al especialista que le corresponde — y cada uno con una lista corta de cosas que no le hará a tu proyecto.
Un comando para cada tipo de trabajo
Planear, construir, revisar, limpiar, reparar, documentar, cotizar. Describes lo que quieres con tus propias palabras y arranca el que corresponde, en lugar de empezar cada tarea desde un prompt en blanco.
Qué hace cada comando →Pide con tus propias palabras
Di qué quieres, dónde lo quieres y si algo está roto. No tienes que nombrar un archivo ni un comando: la petición se lee contra tu proyecto, y solo se te pregunta lo que el código no puede responder.
Cómo pido un cambio →
Los especialistas detrás de cada comando
Un comando no hace todo por sí mismo. Le entrega cada parte al agente que le corresponde: el que define los requerimientos, el que escribe el código, el que lo revisa contra los estándares, el que mira la interfaz.
Quién hace qué →El mismo camino de una idea a un commit
Toda tarea recorre el mismo camino: qué se está pidiendo, qué toca, qué prueba que funciona, qué queda en el commit. Dos desarrolladores con dos asistentes terminan con el trabajo hecho de la misma forma.
Cómo viaja una tarea →Cada tipo de cambio toma su propia ruta
Una etiqueta que dice algo mal se construye de inmediato; una función con decisiones dentro se planea primero. Puedes saber de antemano dónde se va a detener tu petición para preguntarte algo.
Qué ruta toma tu cambio →Decide el enfoque antes de escribir una línea de código
Planear termina en un prompt que ejecuta el paso de construcción, con el alcance, los estados y las decisiones ya resueltos — mientras todavía cuestan una conversación y no una reescritura. Un cambio que vas a ver llega con un dibujo de la pantalla como está hoy y como se vería, para que apruebes el diseño antes de construir nada. Antes de preguntarte, el plan se revisa en busca de cada otro lugar donde pasa lo mismo y de lo que quien lo construya todavía tendría que preguntar, y cada pregunta llega con la respuesta que recomienda.
Planear antes de construir →Avanza con lo que ya estaba planeado
Los planes que se acordaron y quedaron esperando se construyen y se verifican sin que nadie tenga que estar al pendiente, y cada uno queda diciendo hasta dónde llegó. Una pregunta que solo tú puedes responder se escribe en el plan al que toca mientras el resto de la cola sigue, y un plan de /design-catalog además se revisa contra el catálogo y el manual de identidad de tu producto. Nadie vuelve a explicar una tarea que se decidió la semana pasada.
Correr la cola con /next →Comandos que solo tiene tu proyecto
Describe una rutina que tu proyecto repite y tu asistente la convierte en un comando propio, guardado en el toolkit y no en el repositorio: el mismo en cualquier rama y cualquier computadora, visible solo para ti, y ejecutado por su nombre cada vez que lo llamas.
Escribir y usar un comando interno →Ordena un proyecto sin cambiar lo que hace
La limpieza trabaja área por área en grupos pequeños, revisa cada grupo antes de seguir, y deja lo que hace el producto exactamente como estaba.
Todas las guías de los comandos y agentes →Haz que una rama rota vuelva a funcionar
Después de un merge, una actualización o una copia de otro proyecto, el flujo de reparación compara contra algo que se sabe que funciona y hace el cambio más pequeño que lo restaura, en lugar de rehacer lo que ya estaba bien.
Documentación escrita cuando el trabajo se publica
El paso de publicación escribe lo que necesita el siguiente desarrollador y lo que lee un usuario, para que la documentación deje de ser eso que todos piensan hacer después.
Lo que una tarea encuentra se anota, no se arregla de paso
Una tarea que nota algo que no se le pidió arreglar lo nombra y sigue. Queda en una sola lista por proyecto, así que lo que vale la pena hacer después sigue ahí cuando la conversación termina.
Hallazgos pendientes →Un defecto va al repositorio que lo posee
El código que llega por merge del repositorio del que desciende tu producto parece tuyo. Antes de cambiarlo, la ejecución revisa de quién son las líneas que están mal, así que el arreglo cae donde lo recibe cada producto construido sobre él en lugar de quedar sobrescrito por el siguiente merge.
Mandar un defecto al repositorio que lo posee →Lleva un objetivo a través de varios repositorios
Cuando lo que quieres necesita cambios en weblabor-base, weblabor-teams y tu producto, /coordinate pregunta hasta que el objetivo no deja dudas, escribe el plan que necesita cada repositorio y uno último que comprueba el objetivo en tu producto, y sigue vigilando cada cola hasta que funciona — respondiendo lo que bloquea un plan y bajando cada cambio terminado. No construye nada por sí mismo y no hace push de nada.
Coordinar un objetivo entre repositorios →No le pasa un formateador a tu código
El formato le pertenece a quien mantiene el proyecto. Un asistente que trabaja con el toolkit hace la edición que le pidieron y deja intacto el resto del archivo, para que un cambio pequeño siga siendo un cambio pequeño.
No destruye tu base de datos
Sin reset, sin wipe, sin reseed completo sobre una base de datos en uso, en ningún entorno. Cuando de verdad se necesita una base de datos limpia, crea una aparte y deja la tuya en paz.
No hace push, y no publica a tus espaldas
El trabajo queda en un commit; enviarlo a algún lado sigue siendo tu decisión. Una entrada del changelog solo se escribe estando en la rama principal, así que nada se anuncia antes de ser real.
Instálalos una vez, con la forma que espera tu cliente
Pídele a tu asistente que instale el toolkit y escribe cada agente y comando donde ese cliente los guarda. Cuando cambien, vuelve a pedírselo. Los estándares no necesitan nada, porque nunca se copiaron.
Cómo instalar el toolkit →