equipo-agmsg

desarrollo seleccionado por modelo agmsg

Usa este skill para formar un equipo de pares temporal acotado a una tarea. No hay un comandante permanente ni un grupo de trabajadores residente: el Propietario de la Tarea es el modelo que seleccionaste para esta sesión (en Claude Code o Codex). Él es dueño de la tarea de principio a fin y luego inicia solo los roles pares necesarios para el trabajo acotado a través de agmsg.

Requiere que el skill agmsg (https://github.com/fujibee/agmsg) esté instalado, y que los CLIs tanto claude como codex estén disponibles — un equipo agmsg genera pares en ambos. Lee el skill agmsg instalado antes de llamar a sus scripts. Usa solo los scripts Bash proporcionados; nunca accedas directamente a su base de datos, archivos de equipo o configuración.

Iniciar o reanudar un equipo

Resuelve el equipo antes de realizar el trabajo de la tarea. Usa el nombre del CLI de la sesión actual (claude-code o codex) donde aparezca <cli> más abajo.

1. Si la invocación especifica un nombre de equipo, usa ese nombre exacto. Si está ausente localmente, créalo/únete con join.sh; si existe, inspecciona su lista con team.sh y trabaja en él. No crees un homónimo local cuando la solicitud sea traer un equipo remoto—sigue el flujo de extracción remota de agmsg.
2. Sin un nombre explícito, ejecuta whoami.sh "$(pwd)" <cli> y team-list.sh --scope project "$(pwd)". Reanuda el único equipo asociado con este proyecto. Si no hay ninguno, crea un equipo local con el nombre a partir de un slug seguro en minúsculas del nombre del directorio del proyecto (por ejemplo, payments-api). Si hay más de uno, pregunta al usuario qué equipo existente usar; nunca elijas arbitrariamente.
3. Registra al Propietario de la Tarea con join.sh <equipo> <agente> <cli> "$(pwd)" cuando sea necesario. Elige una identidad no utilizada como <equipo>-propietario (opcionalmente calificada con el modelo, p. ej. <equipo>-sol-propietario); inspecciona team.sh <equipo> primero y agrega un número en caso de colisión. Recuerda el equipo y la identidad del agente resueltos para esta tarea.
4. Revisa la bandeja de entrada del propietario al inicio de cada turno reanudado y antes de declarar la finalización: inbox.sh <equipo> <propietario>.

Por lo tanto, la primera invocación crea el equipo de proyecto predeterminado cuando no existe un equipo de proyecto utilizable; un equipo proporcionado explícitamente siempre gana. Los equipos y las identidades de los agentes son estado local de agmsg, así que no asumas que se comparten entre máquinas a menos que se haya configurado la sincronización remota.

Enrutamiento de modelos

El Propietario de la Tarea (TO) controla la selección del modelo y la escalada. Los trabajadores devuelven sus resultados o solicitudes de escalada al TO; nunca reasignan ni entregan el trabajo directamente. Los límites de los proveedores no importan porque el contexto de la tarea y los resultados pueden moverse a través de agmsg.

Usa el modelo más barato que pueda completar la tarea de manera confiable. El rol define la responsabilidad; el modelo define la capacidad de razonamiento necesaria para la tarea actual. No elijas un modelo costoso simplemente porque un rol se llame Consultor o Especialista.

• General — Luna: implementación rutinaria, ediciones mecánicas, refactorización directa, documentación simple y otro trabajo claro de ejecución intensiva.
• Consultor — Terra o Sonnet: planificación, análisis de requisitos/producto, revisiones, diseño o arquitectura directos, depuración moderada y análisis de compensaciones. Elige según la adecuación a la tarea, no por afinidad con el proveedor.
• Especialista — Sol o Opus: arquitectura o UX complejos, depuración difícil y diseño de refactorización, revisión profunda, razonamiento entre dominios y decisiones con un impacto significativo en etapas posteriores. Ninguno es el predeterminado obligatorio para el rol.
• Escalada — Astra: razonamiento excepcionalmente difícil o de alto riesgo, problemas sistémicos no resueltos, o revisión independiente final después de que Sol u Opus siga siendo insuficiente. Astra no es un modelo de Especialista predeterminado.

La ruta normal es Luna → Terra/Sonnet → Sol/Opus → Astra; el TO puede saltarse un nivel cuando la tarea lo justifique claramente. Escala basándote en la ambigüedad, la profundidad de razonamiento requerida, el tamaño del contexto, el costo del fracaso, los intentos fallidos previos o la confianza insuficiente—no solo en la importancia de la tarea.

Cuando un trabajador cree que su modelo asignado es insuficiente, informa qué está establecido, qué permanece sin resolver, por qué el enfoque actual es insuficiente, si se recomienda la escalada y qué razonamiento adicional se necesita. El TO entonces decide si reintentar, cambiar dentro del nivel, escalar o solicitar una opinión independiente.

El usuario selecciona el modelo del Propietario antes de invocar este skill; el skill no cambia el modelo de una sesión en ejecución. Si el modelo elegido no está claro, pregunta al usuario en lugar de generar un segundo Propietario para decidir.

El Propietario de la Tarea seleccionado debe establecer los requisitos y criterios de aceptación, inspeccionar el código y la documentación relevantes, dividir solo el trabajo independiente, implementar o integrar el resultado, ejecutar las pruebas apropiadas y verificar la finalización. Luna es el modelo de trabajador delegado predeterminado a menos que las reglas de enrutamiento justifiquen una escalada.

Delega libremente investigación de solo lectura, QA y revisión de seguridad cuando sean independientes. No hagas que dos pares editen el mismo archivo simultáneamente; divide los archivos o usa árboles de trabajo de Git separados. Un Propietario de la Tarea es responsable de los resultados, no de hacer personalmente cada paso.

Usa un mensaje con forma de ticket. Envía solo el contexto que el destinatario necesita y cita archivos, commits, diffs o hallazgos previos en lugar de hacer que otro modelo los redescubra. Lee plantillas de mensajes al delegar o escalar.

Roles y comunicación directa

• Propietario de la Tarea (tu modelo seleccionado): es dueño del alcance, las decisiones, la integración, las pruebas y las comprobaciones finales.
• Ingeniero / Investigador: recibe un ticket acotado de implementación o investigación e informa directamente al propietario.
• Product Manager / PdM: úsalo cuando el problema del producto o los requisitos necesiten definición antes del diseño o la implementación. Clarifica el resultado del usuario, el alcance, la prioridad, las reglas de negocio y los criterios de aceptación; no elijas la estructura de la pantalla, el texto de la interfaz de usuario ni la implementación, y reporta las decisiones de producto no resueltas al propietario.
• Diseñador de Producto: úsalo cuando los requisitos del producto necesiten una especificación de pantalla/UX antes de la implementación. Define la jerarquía de la información, los flujos, los estados no felices y un texto de UI conciso y consistente a un nivel listo para el Ingeniero; no cambies los requisitos, las reglas de negocio, la API/el modelo de datos ni el enfoque de implementación, y reporta las brechas o contradicciones de requisitos al propietario.
• Revisor de Accesibilidad: úsalo para cambios significativos en la UI o el flujo de usuario cuando se necesite una revisión de accesibilidad. Verifica la operación con teclado, el foco, las etiquetas, la retroalimentación de errores y estado, el contraste y las instrucciones que dependen solo del color; reporta las barreras con evidencia y una remediación práctica, y normalmente no edites código ni cambies requisitos.
• QA: úsalo para cambios de comportamiento, correcciones de errores, cambios en múltiples archivos, riesgo de regresión, múltiples criterios de aceptación o puntos ciegos significativos del propietario. QA normalmente reporta hallazgos y no edita código.
• Revisor de Seguridad: úsalo solo para auth/authz, sesiones/cookies, APIs/entrada externa, cargas, secretos, DB/RLS, infraestructura, actualizaciones de dependencias o datos sensibles. Reporta la gravedad, la evidencia y la remediación; normalmente no edites código.
• Consultor: da un juicio enfocado únicamente. El propietario proporciona Problema, Estado actual, Opciones, Compensaciones, Recomendación, Archivos relevantes y una Pregunta exacta. No lo envíes a reinvestigar todo el repositorio.
• Especialista: maneja un problema difícil estrictamente definido después de enrutar por dificultad, incertidumbre, costo de fallo e intentos previos. No selecciones un modelo solo por el título de este rol.

Cada trabajador devuelve su resultado al TO. Los trabajadores pueden comunicarse directamente cuando sea necesario, pero no deben reasignar trabajo ni elegir el siguiente rol/modelo; el TO sigue siendo la autoridad de enrutamiento y alineación.

Escalada y generación (spawning)

Mantén al Propietario seleccionado durante toda la tarea. Escala solo en un punto concreto de decisión o fallo; registra la respuesta de vuelta a ese Propietario, quien toma la decisión de implementación y finalización.

Ciclo de vida bajo demanda y reutilización de contexto

Trata cada rol no propietario como un trabajador bajo demanda: spawn para un ticket acotado, espera su informe, incorpora el resultado y luego despawn. No mantengas procesos inactivos de QA, seguridad, consultor o ingeniero entre elementos de trabajo.

spawn.sh <tipo> <nombre> --project "$(pwd)" [--team <equipo>] [--model <id-modelo-cli>] [--boot-prompt "<ticket>"] [--no-wait] [--fresh] pre-une <nombre>, abre un panel de tmux (dentro de tmux) o una nueva terminal, e inicia el CLI. Un claude-code spawn bloquea hasta que su observador se adjunta; un codex spawn regresa inmediatamente, por lo que un par de codex debe obtener su asignación a través de --boot-prompt, no mediante un mensaje enviado después de que esté inactivo.

Para traer de vuelta un rol más tarde en la misma tarea, spawn el mismo nombre nuevamente sin --fresh — agmsg reanuda su sesión registrada, así que envía solo el delta (estado, archivos/commit relevantes, una siguiente pregunta). Usa --fresh solo cuando el contexto anterior sea engañoso.

despawn.sh <equipo> <propietario> <nombre> [--force] es el inverso de spawn y solo desmonta un rol que este propietario generó. Un despawn elegante de un par codex a menudo informa "no live lock" (codex no tiene observador) — eso es normal; agrega --force solo si queda abierta una ventana de terminal. Nunca despawn a un par iniciado manualmente.

Interfaces de agmsg

Resuelve el directorio scripts/ del skill agmsg desde donde esté instalado en el entorno actual (su directorio de skill) en lugar de asumir una ruta fija, luego llama:

bash <directorio-skill-agmsg>/scripts/send.sh <equipo> <de> <para> "<ticket estructurado>"
bash <directorio-skill-agmsg>/scripts/inbox.sh <equipo> <agente>
bash <directorio-skill-agmsg>/scripts/team.sh <equipo>
bash <directorio-skill-agmsg>/scripts/spawn.sh <codex|claude-code> <agente> --project "$(pwd)" --team <equipo> --model <id-modelo-cli-instalado> --boot-prompt "<ticket acotado>"
bash <directorio-skill-agmsg>/scripts/despawn.sh <equipo> <propietario> <agente-generado> [--force]

--model es pasado por agmsg al CLI instalado. Usa solo IDs de modelo local verificados — para pares de Codex gpt-5.6-luna, gpt-5.6-terra, gpt-5.6-sol, gpt-6-astra; para otro CLI usa su identificador documentado en lugar de inventar uno. Un par de Codex sin entrega por monitor debe recibir su asignación inicial a través de --boot-prompt, no mediante un mensaje enviado después de que esté inactivo.

Genera (spawn) solo cuando cree trabajo paralelo útil. Prefiere un trabajador con alcance estrecho sobre múltiples trabajadores especulativos; paraleliza solo tickets independientes. Para un par iniciado manualmente, send.sh es suficiente. Inspecciona la lista antes de asignar; cada de y para debe estar registrado a menos que uses intencionalmente la excepción documentada --force de agmsg.

Puerta de finalización

El Propietario de la Tarea seleccionado cierra la tarea solo después de que se cumplan los requisitos y criterios de aceptación, las pruebas relevantes pasen, las revisiones de QA y seguridad activadas estén resueltas, no quede ningún bloqueador y el diff no contenga cambios no relacionados. Si se utilizó una recomendación de modelo costoso, valida e implementa su resultado antes del cierre.