Por qué un comando no hace todo solo
Un comando es lo que tú escribes. Un agente es a quien le pasa una parte del trabajo, con una tarea acotada e instrucciones propias. La división es deliberada: quien decide cuál es el trabajo no decide también que ya quedó, y quien escribe el código no es quien lo aprueba.
Nunca llamas a un agente directamente. De eso se encargan los comandos, y el reporte te dice cuáles corrieron. Las instrucciones completas de cada agente se leen en el panel, en Instrucciones de IA del menú lateral, en el idioma de tu cuenta; una que todavía no está traducida se muestra en inglés, con un aviso que lo dice.
Los ocho agentes
| Agente | De qué responde |
|---|---|
analyst |
Encuentra lo ambiguo antes de que se construya nada y devuelve los huecos. Cuando se le entrega un documento para comprobar, también lee contra el código cada afirmación que hace sobre cómo se comporta hoy tu sistema, y marca cada una como verificada o contradicha. No escribe código, y tampoco decide qué hacer con ninguna de las dos listas: eso lo decide el comando que lo llamó. |
developer |
Implementa lo que dejaron resuelto los requerimientos, siguiendo los patrones que ya existen en tu código y nada más allá de ellos. |
frontend |
Todo lo que una persona ve: plantillas, el marcado de los componentes y los archivos de tu carpeta de recursos. Lee el estándar de estilos cada vez en vez de de memoria, y no toca la lógica de backend. |
ux-designer |
Mira la interfaz implementada como la miraría un usuario: si la acción se encuentra, si el estado vacío está explicado, si el botón destructivo se distingue claramente del seguro. En un producto con su propia capa de diseño también revisa que las pantallas sigan el catálogo y el manual de identidad con el mínimo de componentes. Propone; no implementa. |
code-reviewer |
Revisa código contra los estándares. Es la compuerta suplente para cuando no se puede alcanzar el analizador, y un revisor manual cuando lo pides por su nombre. |
tech-lead |
La opinión de arquitectura: si la lógica está en la capa correcta, si algo se repite y debería compartirse, si alguien que llega a este código lo entendería rápido. Se llama cuando lo pides, y además cuando /review lo llama porque un hallazgo sigue fallando tras varios arreglos o porque el analizador no responde. |
documenter |
Escribe la documentación de desarrollo de lo que se construyó y la deja en la carpeta de documentación del propio proyecto, en vez de repartida por el código. Cuando el comando que lo llamó lo pide, y el cambio es algo que un usuario notaría, también escribe lo que lee un usuario: el ítem de la función, la guía cuando el flujo necesita pasos y — cuando /finish lo pide — la entrada del changelog. |
workflow-reviewer |
Revisa los cambios a los comandos, los agentes y los estándares mismos, no a tu código. Atrapa una regla poco clara, mal ubicada o escrita como reacción estrecha a una sola mala corrida. |
Los dos pares que vale la pena conocer
frontend y ux-designer trabajan en ciclo. Después de implementada la interfaz, el diseñador la revisa y dice con qué tropezaría un usuario. Sus propuestas son propuestas: se te muestran y esperan tu sí antes de que se cambie nada. La única excepción es la revisión de diseño que /next hace a un plan que escribió /design-catalog: ese plan ya lo confirmaste, así que una corrección que devuelve lo construido a él va a la cola sin volver a preguntarte.
code-reviewer suple, y lo dice. La autoridad sobre los estándares es el analizador. Cuando la conexión con él está caída, el revisor lee el código en su lugar, y el resultado se reporta como una revisión interna, nunca como una pasada del analizador. Son cosas distintas y siempre se te dice cuál recibiste. Qué puede y qué no puede resolver el analizador está en Lo que el analizador no puede revisar.
Cuando cambia el toolkit mismo
Cambiar un comando, un agente o un estándar lo revisa workflow-reviewer antes de darlo por correcto, y la revisión corre dos veces sobre el mismo texto: el mismo texto entregado dos veces a un revisor no siempre regresa igual.
Ese ciclo tiene un tope a propósito. Cuando las rondas repetidas dejan de converger, o al llegar a diez rondas, el cambio se publica como está y todo hallazgo que siga abierto se te reporta. Pulir el texto para siempre cuesta más de lo que vale, y la decisión se te pone enfrente en lugar de absorberse en silencio.
Sigue por aquí
- Qué hace cada comando — cuál comando llama a cuál de estos.
- Cómo viaja una tarea — en qué parte de la corrida se usa cada uno.