agent-team

Convierte el mecanismo de colaboración de "multi-sesión = multi-departamento" directamente en la carpeta del proyecto. No se trata de un juego de roles, sino de un sistema de puestos de trabajo: cada sesión tiene responsabilidades fijas, límites de escritura, bandeja de entrada, traspasos y controles de auditoría.

Límites que deben mantenerse primero

Primero se necesita una base de proyecto adecuada para el escenario de negocio, y luego se construye la capa de colaboración. El directorio de destino predeterminado = el directorio de trabajo actual; si faltan docs/ o archivos claros de objetivos/progreso/traspaso, primero se debe juzgar el tipo de proyecto: para productos de Internet / Vibe Coding se recomienda prioritariamente vibe-project-foundation; para otros escenarios de negocio, priorizar el uso de Skills de base de negocio especializados existentes o la estructura de archivos actual. Si no hay una base adecuada, primero preguntar por el objetivo del negocio, los entregables, los criterios de aceptación, los recursos del proceso, los riesgos/métodos de revisión, y luego ayudar al usuario a crear una base de negocio mínima, y después construir la capa de colaboración.
Las tres capas deben estar completas: capa de gestión / capa de ejecución / capa de auditoría. La configuración mínima es lead, do, review; no dividir departamentos forzadamente solo para tener "más agentes".
Antes de crear docs/collaboration/, añadir/eliminar/reemplazar departamentos, crear la primera sesión de un departamento, o cambiar las rutas de sesión cruzada o los modos de notificación, primero se debe obtener la confirmación del usuario; las activaciones cortas registradas como automáticas/manuales se ejecutan según departamentos.md, sin necesidad de confirmar cada vez.
No escribir código de negocio directamente; este skill solo se dedica al diagnóstico del equipo, la construcción de la capa de colaboración, el registro de sesiones y el mantenimiento de las reglas de colaboración.
Si ya existe docs/collaboration/, no sobrescribir; primero leer el estado actual, y luego determinar si se añaden departamentos de forma incremental, se registran sesiones, se actualizan reglas o se reconstruye.
Control duro antes de iniciar: No se debe pasar de "ayúdame a montar un equipo/departamento" directamente al desarrollo de un producto de Internet. Primero se debe confirmar el entregable final del proyecto y el modo de creación de sesiones, y luego recomendar los departamentos.

Reglas de funcionamiento inamovibles

Estas reglas deben escribirse en los artefactos generados, y todas las asignaciones posteriores deben cumplirlas:

Control de tres tipos de nodos: Cada funcionalidad/hito solo avanza a través de un nodo de aceptación. Después de que un departamento complete un nodo, primero debe informar al departamento de coordinación; el departamento de coordinación juzga según los tres tipos: los nodos de percepción del producto/límite importante deben ser confirmados por el usuario, los nodos de proceso/técnicos pueden avanzar de forma autónoma, y los nodos que pueden avanzar de forma autónoma pero afectan la visibilidad del proyecto deben informarse con una tarjeta de nodo breve.
La bandeja de entrada es la fuente de la verdad: Los detalles de las tareas y los informes se escriben en el bandeja-de-entrada.md del departamento correspondiente; cada sesión de departamento solo realiza el registro de capacidad de notificación una vez al comenzar o al tomar el relevo, y luego ejecuta según el modo "automático/manual" registrado. Las notificaciones solo expresan tres estados: hay una nueva tarea / la tarea está completada / se ha encontrado un bloqueo.
Paquete de cuatro elementos para informar la finalización: Ruta del producto, resultado de la verificación (incluyendo elementos no verificados), recibo del registro, y autocomprobación de errores. Si falta alguno, el departamento de coordinación no puede considerar el ciclo cerrado.
Coordinación no consume contexto largo: El departamento de coordinación primero lee su propia bandeja de entrada, solo verifica la existencia del recibo del registro; solo cuando el informe es insuficiente, el recibo es incorrecto, hay conflictos en las conclusiones de los departamentos o el usuario lo solicita, lee el cuerpo mínimo necesario.
La independencia de la capa de auditoría no equivale a una auditoría ciega suficiente: El departamento de auditoría verifica personalmente, no hereda el contexto largo del departamento de ejecución y no confía en las paráfrasis de "ya aprobado"; pero tampoco puede simplemente repetir el camino feliz del departamento de ejecución. Todo lo que involucre lo que el usuario ve / indicaciones / texto de error / progreso / estado / ventanas emergentes / resumen de resultados / nombre de archivo exportado / ventana de estado de compilación debe probarse hasta el worker / UI / punto de salida final del usuario; probar solo la capa engine/API/helper no cuenta como aprobado. Para cada riesgo clave, diseñar al menos una sonda inversa.
Las asignaciones deben especificar la salida de aceptación y la ruta de fallo obligatoria: La asignación del departamento de coordinación debe especificar claramente la salida de aceptación y la ruta de fallo obligatoria. La salida de aceptación se refiere a dónde ve finalmente el usuario el resultado / indicación / error / estado / ventana emergente / resumen de resultados / nombre de archivo exportado / ventana de estado de compilación; todo lo que involucre contenido visible para el usuario no puede limitarse a la capa engine/API/helper. La ruta de fallo obligatoria debe enumerar al menos 1-3 escenarios de fallo, excepción o límite que rompan el camino feliz. Si falta, el departamento receptor debe devolverlo al departamento de coordinación para que lo complete, no puede inventarlo.
Experiencia antes que pruebas: Las funcionalidades ejecutables se dan primero al usuario para que las experimente; al llegar a un nodo que "requiere que el usuario experimente la App", el departamento de coordinación abre la App para el usuario por defecto, sin preguntar primero "¿quieres abrirla?", y luego da una tarjeta de experiencia breve. Solo después de que el usuario confirme claramente "experiencia OK / se puede pasar a pruebas", el departamento de pruebas realiza el control de calidad profesional.
La intención de diseño debe ser visualizable: En todos los nodos que involucren UI, interacción, presentación visual, diseño de página, bocetos de diseño o recorridos de experiencia del usuario, el departamento de diseño no puede entregar solo descripciones de texto, wireframes ASCII, tablas Markdown o conclusiones abstractas; debe proporcionar una vista previa de la intención de diseño que el usuario pueda juzgar directamente. La vista previa de diseño no puede afirmar que sea equivalente a la UI real de la App; la aceptación de la UI real se basa en la App en ejecución / la ruta real / capturas de pantalla del producto compilado o empaquetado.
La confirmación de diseño es independiente de la confirmación de funcionalidad: La confirmación del usuario de que la dirección funcional es OK no equivale a la aprobación visual/interactiva. Antes de que el usuario confirme la dirección visual/interactiva del diseño, el departamento de coordinación no puede asignar al departamento de desarrollo para su implementación formal; como máximo, puede avanzar en la viabilidad funcional o la evaluación técnica.
Auditoría ciega/inspección aleatoria por activación: Cuando la misma cadena de funcionalidad pasa múltiples rondas consecutivas sin bloqueos (por defecto 3 rondas, ajustable con explicación), la cadena cruza engine→worker→UI→salida del usuario, involucra texto de error/estado/publicación/empaquetado/seguridad/costos, etc. de alto riesgo, o el usuario/coordinación siente que la base de la conclusión es insuficiente, se activa la auditoría ciega/inspección aleatoria del sub-Agente. El sub-Agente solo informa la conclusión de la auditoría ciega/inspección aleatoria, no modifica el código directamente ni autoriza automáticamente.
Riesgo/costo por activación: El departamento de seguridad solo interviene en grandes etapas, antes del lanzamiento/envío externo, o cuando aparecen riesgos de privacidad, permisos, claves, autorización, plataformas de terceros, configuración de producción, etc.; el departamento de finanzas solo interviene en los nodos de costos, solo advierte e informa, no bloquea el lanzamiento.
La autorización la decide el usuario: Después de que la capa de auditoría pase los tres controles, el departamento de coordinación solo da una recomendación de autorización; la finalización del marcado, la publicación externa, el pago, etc., son confirmados por el usuario.
Regla mnemotécnica de enrutamiento: Los elementos de aclaración (que no modifican productos, no deciden, no avanzan el estado) se conectan directamente a la bandeja de entrada del otro; cualquier cosa que requiera modificar / decidir / cambiar el estado / autorizar / añadir/eliminar departamentos pasa por el departamento de coordinación.
Desvío si las pruebas no pasan: Después de que el usuario haya dado el visto bueno a la experiencia, se entra en pruebas. Si el departamento de pruebas encuentra problemas puramente de código/calidad/ruta excepcional, el departamento de pruebas informa al departamento de coordinación, y el departamento de coordinación primero sincroniza con el usuario mediante una tarjeta de nodo, luego puede asignar al departamento de desarrollo para retrabajar de forma autónoma; solo se detiene para esperar la confirmación del usuario cuando se trata de compensaciones de experiencia, cambios de alcance, costos/seguridad/publicación, decisiones de diseño o asuntos importantes.

Decisión de tres tipos de nodos por el departamento de coordinación

Principio de juicio del departamento de coordinación:

El usuario es responsable de la experiencia del producto, las decisiones de funcionalidad, el juicio de diseño y las decisiones de riesgo importante; el departamento de coordinación es responsable del flujo técnico, la programación de departamentos, el control de calidad de rutina y el avance sin controversia. El avance autónomo debe mantener un informe breve; cuando se encuentren cambios en la percepción del producto o cambios importantes en los límites, debe detenerse para confirmar.

A. Debe ser confirmado por el usuario

Cualquier nodo que afecte la experiencia del producto, la percepción del usuario, las decisiones de funcionalidad, el diseño de la interfaz, el flujo de interacción, la presentación visual, los límites del MVP, la hoja de ruta del producto, el lanzamiento, la entrega externa, el aumento significativo de costos, o los riesgos de privacidad/seguridad/nube/claves/autorización debe ser detenido por el departamento de coordinación para que el usuario confirme.

Casos típicos:

Después de completar una funcionalidad, el usuario necesita probarla.
Después de completar la UI/interacción/boceto de diseño, se debe mostrar una vista previa visual al usuario.
Cuando el resultado del departamento de diseño solo contiene descripciones de texto, wireframes ASCII, tablas Markdown o conclusiones abstractas, no se considera un nodo de diseño completado.
Cuando el usuario solo ha confirmado que la dirección funcional es OK, pero no ha confirmado la dirección visual/interactiva, no se puede proceder a la implementación formal de desarrollo.
Cuando se necesita añadir, eliminar, posponer o cambiar el alcance de una funcionalidad, el usuario debe decidir.
Después de que las pruebas pasen, se necesita la confirmación del usuario para cerrar formalmente o pasar a la siguiente gran etapa.
Cuando se trata de nube, carga, clave API, descarga en línea, costos, o cambios significativos en el tamaño del paquete, se necesita la confirmación del usuario.

B. El departamento de coordinación puede avanzar de forma autónoma

Cualquier nodo de proceso/técnico que el usuario no pueda juzgar adecuadamente y que no cambie la experiencia del producto ni los límites importantes puede ser avanzado por el departamento de coordinación basándose en su juicio profesional, sin necesidad de preguntar repetidamente.

Casos típicos:

Después de confirmar los límites del producto, asignar al departamento de diseño para un borrador de interacción mínimo.
Después de completar el borrador de diseño, asignar al departamento de desarrollo para una evaluación de implementación.
Cuando el diseño visual/interactivo ha sido confirmado por el usuario, la evaluación técnica es clara y el riesgo es controlable, asignar al departamento de desarrollo para la implementación formal; antes de la confirmación de la UI, solo se puede avanzar en la evaluación de implementación/viabilidad técnica.
Después de que la experiencia del usuario sea OK, asignar al departamento de pruebas para el control de calidad.
Cuando el departamento de pruebas encuentra problemas puramente de código/calidad/ruta excepcional después de que el usuario haya dado el visto bueno a la experiencia, el departamento de coordinación sincroniza con el usuario mediante una tarjeta de nodo y luego asigna al departamento de desarrollo para retrabajar.
Cuando no hay bloqueos P0/P1/P2 en las pruebas, el departamento de coordinación puede recomendar la aprobación y proceder al cierre.
Acciones de rutina como registros, traspasos, colección compartida de errores, registro de progreso, verificación ligera, archivado de commit después de la confirmación del usuario.

C. Se puede avanzar de forma autónoma pero se debe informar

Este tipo no requiere la decisión del usuario, pero el departamento de coordinación debe usar una tarjeta de nodo breve para decirle al usuario "hasta dónde he avanzado".

Ejemplo de tarjeta de nodo:

"La evaluación de desarrollo está completa, pero la UI no está confirmada; solo he asignado al departamento de desarrollo una evaluación de viabilidad técnica."
"El diseño visual/interactivo está confirmado y el riesgo de la evaluación de desarrollo es controlable; ya se ha asignado al departamento de desarrollo para la implementación formal."
"Después de que hayas dado el visto bueno a la experiencia, ya he asignado al departamento de pruebas para el control de calidad."
"Las pruebas encontraron un problema a nivel de código, sin compensaciones de producto; ya he asignado al departamento de desarrollo para retrabajar."
"No hay bloqueos en las pruebas; me preparo para cerrar y archivar."
"El nodo de seguridad/finanzas no se activó esta vez, por lo que no intervino."

Salida de aceptación, ruta de fallo y auditoría ciega/inspección aleatoria

La asignación del departamento de coordinación debe escribir "dónde ver la aceptación" y "cómo romper el camino feliz" en la tarea, no solo un objetivo de aceptación abstracto.

Campos obligatorios en la asignación:

salida de aceptación: Dónde ve finalmente el usuario el resultado / indicación / error / estado / ventana emergente / resumen de resultados / nombre de archivo exportado / ventana de estado de compilación. Todo lo que involucre contenido visible para el usuario no puede limitarse a la capa engine/API/helper.
ruta de fallo obligatoria: Al menos 1-3 escenarios de fallo, excepción o límite para romper el camino feliz.

Si falta alguno, el departamento receptor debe devolverlo al departamento de coordinación para que lo complete, no puede inventarlo.

Campos obligatorios en el informe de auditoría/prueba:

nivel de verificación: engine / adapter-service / worker-tarea en segundo plano / UI-salida visible para el usuario / estado de compilación / niveles no cubiertos.
salida visible para el usuario: La salida final realmente probada.
sonda inversa autodiseñada: Al menos una para cada riesgo clave, explicando cómo demostrar que no es solo repetir el camino feliz.
niveles no cubiertos: Los niveles no cubiertos deben indicarse explícitamente; si no hay ninguno, escribir "ninguno".
¿Se activó la auditoría ciega/inspección aleatoria del sub-Agente?: Escribir la conclusión y el fundamento.

La independencia de la capa de auditoría no equivale a una auditoría ciega suficiente. El departamento de auditoría no puede simplemente repetir el camino feliz del departamento de ejecución; toda aceptación que involucre lo que el usuario ve / indicaciones / texto de error / progreso / estado / ventanas emergentes / resumen de resultados / nombre de archivo exportado / ventana de estado de compilación debe probarse hasta el worker / UI / punto de salida final del usuario; probar solo la capa inferior no cuenta como aprobado.

Condiciones de activación de la auditoría ciega/inspección aleatoria:

La misma cadena de funcionalidad pasa múltiples rondas consecutivas sin bloqueos, por defecto 3 rondas, ajustable según la documentación del proyecto.
La cadena cruza engine→worker→UI→salida del usuario.
Involucra texto de error, estado, publicación/empaquetado, seguridad, costos, etc. de alto riesgo.
El usuario o la coordinación siente que la base de la conclusión es insuficiente.

Una vez activado, el sub-Agente solo informa la conclusión de la auditoría ciega/inspección aleatoria, no modifica el código directamente ni autoriza automáticamente.

Desvío de retrabajo si las pruebas no pasan

Cuando el usuario ha dado el visto bueno a la experiencia de la App, esto solo significa que el flujo de experiencia, las expectativas de funcionalidad y la percepción del usuario pueden pasar a pruebas profesionales; no significa que la calidad del código, las rutas excepcionales, el estado de compilación, los registros y las condiciones de límite ya estén aprobados. Si el departamento de pruebas encuentra problemas P0/P1/P2 u otros problemas de calidad, primero escribe un informe de auditoría y un [informe] en la bandeja de entrada del departamento de coordinación. El departamento de coordinación debe primero sincronizar la conclusión con el usuario mediante una tarjeta de nodo, y luego desviar según la naturaleza del problema:

Se puede asignar al departamento de desarrollo para retrabajar de forma autónoma: Errores de código puro, rutas excepcionales, texto de error, registros, estado de compilación, inconsistencias en la salida worker/UI, brechas en la cobertura de pruebas, etc., problemas de calidad profesional; estos problemas no requieren que el usuario tome decisiones de código.
Debe detenerse para esperar la confirmación del usuario: Cuando se necesita cambiar la experiencia del producto, el alcance de la funcionalidad, el plan de diseño, los límites del MVP, la estrategia de retención de datos, el costo, la seguridad, la privacidad, el método de publicación, o cuando hay múltiples planes de reparación que sacrificarán experiencia/alcance/costo/velocidad.

La tarjeta de nodo debe indicar claramente: la conclusión de la prueba, el impacto, la razón del retrabajo, si implica una compensación del usuario, el juicio de la coordinación y el siguiente paso. El retrabajo autónomo solo significa que entra en un ciclo de reparación, no la autorización final; después de la reparación, aún se vuelve al nodo de experiencia del usuario/prueba.

Cierre y archivado de commit

El cambio de turno no equivale a un git commit. Cuando un departamento completa un nodo, primero actualiza el traspaso, los registros, el informe de la bandeja de entrada y los productos necesarios; el commit es la acción de archivo en el repositorio después de que el usuario confirma el cierre formal.

Cuando no hay bloqueos P0/P1/P2 en las pruebas y no hay bloqueos en los controles de riesgo/costo, el departamento de coordinación puede dar una recomendación de autorización y solicitar al usuario que confirme el cierre formal. Después de la confirmación del usuario, el departamento de coordinación debe ejecutar:

Ejecutar git status --short.
Si el área de trabajo solo contiene cambios relacionados con este nodo, ejecutar el commit de archivado.
Si hay cambios no relacionados, cambios no confirmados por el usuario o cambios cuya pertenencia no se puede determinar, primero explicar al usuario, no mezclar la confirmación.
Si el proyecto no es un repositorio git, explicar que no se puede hacer commit, solo completar el registro de cierre de la capa de colaboración.

El commit de archivado no representa una publicación externa; la publicación, el envío externo, el pago y el lanzamiento siguen siendo decididos por el usuario.

Nodo de experiencia de App

Al llegar a un nodo que "requiere que el usuario experimente la App", el departamento de coordinación abre la App para el usuario por defecto, sin preguntar primero "¿quieres abrirla?". Si el entorno actual puede iniciar/abrir la App, se ejecuta directamente; si falla el inicio, se explica el motivo del fallo, los comandos ya probados y la entrada que el usuario puede abrir manualmente.

Estándar de la tarjeta de experiencia:

Entrada:
Puntos clave:
Método sugerido:
Criterio de juicio:

Requisitos de la tarjeta de experiencia:

Entrada: Decir al usuario por dónde entrar, por ejemplo, "Doblaje/Clonar voz → IndexTTS2 Doblaje emocional → Intensidad emocional".
Puntos clave: Decir al usuario qué es lo principal que debe observar esta vez, solo 1-2 puntos.
Método sugerido: Dar 2-4 acciones específicas para que el usuario no tenga que pensar cómo probar.
Criterio de juicio: Decir al usuario que solo necesita responder "Experiencia OK" o indicar qué no funciona.

Ejemplo:

Entrada: Doblaje/Clonar voz → IndexTTS2 Doblaje emocional → Intensidad emocional
Puntos clave: Escuchar si la diferencia entre los tres niveles es obvia y natural.
Método sugerido:
- Probar  Feliz + Contenido / Estándar / Pronunciado.
- Probar  Locución enérgica si por defecto trae  Feliz + Pronunciado.
- Cambiar a  Natural y ver si se fija en Estándar y da una pista.
Criterio de juicio: Si te parece bien, di "Experiencia OK"; si no, dímelo específicamente.

Nodo de confirmación visual de diseño

En todos los nodos que involucren UI, interacción, presentación visual, diseño de página, bocetos de diseño o recorridos de experiencia del usuario, el departamento de diseño debe entregar una vista previa de la intención de diseño que el usuario pueda juzgar directamente, no solo descripciones de texto, wireframes ASCII, tablas Markdown o conclusiones abstractas. La vista previa de la intención de diseño se utiliza para juzgar la dirección, el diseño, la jerarquía de la información y la sensación de interacción, y no puede afirmar que sea equivalente a la UI real de la App.

La aceptación de la UI real debe provenir de la App en ejecución, la ruta real, el producto compilado o las capturas de pantalla del estado de compilación. El OpenDesign / Figma / HTML mock / PNG del departamento de diseño solo puede servir como base de la intención de diseño; después de la implementación, el departamento de desarrollo debe marcar las diferencias con la intención de diseño, y el departamento de pruebas verifica si se desvía utilizando la interfaz real de la App.

Prioridad de entrega del departamento de diseño:

Priorizar el uso de herramientas de diseño especializadas como OpenDesign para generar artefactos de diseño editables o artifacts.
Si la sesión actual no tiene OpenDesign MCP cargado en caliente, OpenDesign no tiene un proyecto activo, permisos insuficientes o fallo de conexión de la herramienta, el departamento de diseño debe indicar claramente el motivo del fallo en el informe.
Cuando la herramienta no esté disponible, se debe utilizar local HTML + captura de pantalla PNG, Figma, o una vista previa de imagen que se pueda abrir como plan de respaldo, asegurando que el usuario vea la intención de diseño, pero sin prometer que esta sea la UI final real.
Si el usuario no quiere instalar, iniciar, autorizar, registrar o reparar OpenDesign, o no está dispuesto a recargar/abrir una nueva sesión para la sesión actual, el departamento de diseño no debe bloquearse, sino que debe elegir directamente local HTML + PNG, Figma o una vista previa de imagen que se pueda abrir según las preferencias del usuario.

La "ruta del producto" en el paquete de cuatro elementos del informe de finalización del departamento de diseño debe incluir simultáneamente:

Ruta del documento de especificación de diseño.
Ruta de la vista previa de la intención de diseño, como un enlace de artifact de OpenDesign / local HTML / captura de pantalla PNG / enlace de Figma / imagen que se pueda abrir.
Si se utiliza un plan de respaldo, se debe indicar claramente el estado actual de OpenDesign y las condiciones para su restauración posterior.

Reglas de integración de OpenDesign:

Primero confirmar si la App OpenDesign local se está ejecutando, luego confirmar el estado de salud del daemon.
No asumir que el puerto predeterminado es siempre 7456; se debe confirmar la URL real del daemon desde los registros de OpenDesign o el puerto de escucha local.
Después de confirmar, registrar el MCP open-design en Codex; la sesión actual puede no ser capaz de cargar en caliente el nuevo MCP, si es necesario, indicar al usuario que recargue/abra una nueva sesión.
Si la escritura del artifact de OpenDesign indica que no hay un proyecto activo, solicitar al usuario que cree o haga clic en un proyecto dentro de OpenDesign, o utilizar local HTML/PNG como plan de respaldo para la entrega, no bloquear el nodo.
Si se descubre que OpenDesign no está instalado/en ejecución, hay permisos insuficientes, fallo de conexión o el MCP no está cargado en caliente, el departamento de diseño debe preguntar activamente al usuario si necesita ayuda para instalar/iniciar/autorizar/registrar el MCP/recargar o abrir una nueva sesión; si el usuario no lo gestiona, se debe ir inmediatamente al plan de respaldo de visualización.
Orden mínimo de resolución de problemas: Verificar si la App está en ejecución → Verificar el puerto de escucha o la URL del daemon en los registros → Verificar si el MCP está registrado / si la sesión actual lo ha cargado en caliente → Verificar el proyecto activo → Verificar permisos/errores de conexión; si falla en cualquier paso, proporcionar simultáneamente un plan de respaldo de vista previa.
OpenDesign solo mejora la capacidad de expresión de diseño y confirmación visual, no significa una expansión automática a un rediseño completo de UI, una actualización de marca o una implementación de desarrollo.

Después de recibir el informe de diseño, el departamento de coordinación:

Primero mostrar la vista previa de la intención de diseño, luego dar al usuario una tarjeta de nodo breve.
Estructura sugerida para la tarjeta de nodo: Resultado / Punto de juicio / Sugerencia / Riesgo / Siguiente paso.
No arrojar explicaciones técnicas largas o el cuerpo del diseño directamente al usuario para que juzgue.
Antes de que el usuario confirme la dirección visual/interactiva del diseño, no se puede asignar al departamento de desarrollo para la implementación formal; si el usuario solo indica que la dirección funcional es OK pero la UI no está confirmada, solo se puede avanzar en la viabilidad funcional o la evaluación técnica.
Después de la finalización del desarrollo, el juicio de la UI no puede continuar citando la vista previa de la intención de diseño en lugar de la interfaz real; se debe volver a la App real / ruta real / captura de pantalla del producto compilado o empaquetado.

Condiciones de detención del avance autónomo

El avance autónomo del departamento de coordinación no significa un avance continuo ilimitado. Se puede avanzar continuamente en nodos de proceso, pero cuando se encuentren las siguientes situaciones, se debe detener y preguntar al usuario:

La conclusión tiene una incertidumbre obvia.
Hay conflictos de juicio entre departamentos.
Se necesita sacrificar cualquiera de: experiencia, alcance, costo, velocidad.
Se necesita añadir nuevas dependencias, nube, conexión en línea, modelo, costo.
Se necesita cambiar la dirección del producto previamente confirmada por el usuario.
Se necesita entrar en la experiencia de funcionalidad ejecutable, confirmación visual de UI, publicación/empaquetado/envío externo, cierre de gran etapa.

Proceso de diagnóstico

Si el usuario ya ha especificado el tipo de proyecto, los entregables y el modo de creación de sesiones, diagnosticar directamente; no preguntar repetidamente. Si falta información, hacer solo una pregunta clave a la vez.

Primera pregunta:

¿Qué es lo que este proyecto debe entregar finalmente: un software ejecutable, contenido/curso, resultado de operaciones, plan de investigación, flujo de automatización, entrega offline, u otro?

Segunda pregunta:

¿Cómo se crearán las sesiones de departamento: las creará automáticamente este agente (Codex) que tiene una herramienta de gestión de sesiones, o primero crearás manualmente las ventanas de sesión de cada departamento y yo solo seré responsable de generar los archivos del departamento y la guía de inicio?

Antes de que la primera pregunta esté clara, no recomendar la configuración común de software product/design/dev/test. Antes de que la segunda pregunta esté clara, no afirmar que ya se han creado las sesiones de departamento. Si al proyecto le faltan archivos de base, primero determinar si ya existe un Skill de base de escenario aplicable; si no, crear una base de negocio mínima genérica, no orientar todos los proyectos hacia vibe-project-foundation.

Al diagnosticar, fijar las tres capas, solo determinar cuántos departamentos de ejecución dividir y cuántos controles de auditoría abrir:

Dimensión desencadenante	Impacto si se cumple	Departamento
Software / Producto de Internet / Vibe Coding / Tiene un producto ejecutable	Habilitar configuración de software	`product/design/dev/test`
Fuerte en UI/interacción/visual	Reforzar diseño	`design`
Fuerte en recopilación de datos, verificación de usuarios/mercado/competencia/hechos	Añadir investigación	`research`
Fuerte en planes, procesos, programación, asignación de recursos	Añadir planificación	`planning`
Fuerte en recopilación/limpieza/importación/exportación/exactitud de datos	Añadir datos	`data`
Ejecución por lotes, programada, automatizada a través de plataformas	Añadir automatización	`auto`
Producción continua de texto/imagen/video/informe	Añadir contenido	`content`
Crecimiento, conversión, retención, operaciones de monetización	Añadir operaciones de crecimiento	`growth`
Cuentas, inicio de sesión, privacidad, cumplimiento, plataformas de terceros, claves, configuración de producción	Abrir control de riesgos	`security`
Presupuesto, sensibilidad de costos, elementos de pago	Abrir control de costos	`finance`
Funcionalidades complejas, necesidad de cobertura de errores/excepciones	Control de calidad independiente	`test` o `review`
Ninguno es fuerte	Configuración mínima genérica	`lead,do,review`

Para proyectos que no son de software, no forzar la configuración producto/diseño/desarrollo/prueba; primero juzgar según los entregables, los criterios de aceptación, los recursos del proceso, los riesgos y el método de revisión. Si no se puede clasificar, usar lead,do,review, y luego complementar con research/planning/content/data/auto/security/finance según el riesgo.

Selección de base

La capa de colaboración depende de una base de proyecto que "permita a los departamentos leer los objetivos y límites", pero la base no equivale a una estructura de directorios de software fija.

Orden de procesamiento:

Primero ver si el proyecto ya tiene una base utilizable: como docs/, plan de negocio, descripción del proyecto, lista de entregables, archivos de progreso/traspaso, directorios específicos de la industria. Si ya existe, planificar las responsabilidades de los departamentos y los rangos de escritura basándose en la base existente, no forzar el cambio a una estructura de software.
Solo si es un producto de Internet, software, Vibe Coding o tiene claramente productos como app/ design/ docs/spec.md, se recomienda o utiliza prioritariamente vibe-project-foundation.
Si es un proyecto no software, como cursos, contenido, operaciones, consultoría, entrega offline, investigación, procesos internos, primero buscar si hay un Skill de base de negocio especializado correspondiente o una plantilla existente; si la hay, usarla.
Si no hay una base especializada, no detenerse en "primero instala tal base de software". Primero preguntar por el objetivo del negocio, el entregable final, los criterios de aceptación, los recursos del proceso, los riesgos/métodos de revisión, y luego crear la base de negocio mínima.

La base de negocio mínima solo contiene los archivos genéricos necesarios para la colaboración:

docs/overview.md: Objetivo del proyecto, entregables, destinatarios/usuarios, límites.
docs/progress.md: Etapa actual, completado, en curso, siguiente paso.
docs/agent-guide.md: Reglas de colaboración de este proyecto, división de archivos, notas importantes.
Si es necesario, crear directorios como deliverables/, materials/, research/, operations/, scratch/ según el negocio; no crear directorios de software irrelevantes.

Al recomendar el equipo, proporcionar:

Las tres capas y los departamentos en cada una, con el fundamento de la selección.
Las responsabilidades, acciones prohibidas, entradas, salidas, rangos de escritura y rangos de escritura prohibidos de cada departamento.
Enrutamiento entre departamentos: aclaración directa o a través de la coordinación.
Qué nodos requieren confirmación del usuario.
Modo de creación de sesiones: Creación automática de sesiones o Creación manual de ventanas de sesión, y los pasos de ejecución correspondientes.

Detenerse para confirmar antes de crear:

Recomiendo crear docs/collaboration/ con la configuración de equipo anterior, con el modo de sesión [Creación automática / Creación manual]. ¿Confirmas?

Creación de la capa de colaboración

Después de la confirmación, ejecutar el script. Si no hay una base especializada y el usuario confirma que este Skill debe complementar la base de negocio mínima, añadir --create-minimal-foundation --allow-without-foundation. Configuración mínima genérica por defecto:

python3 <directorio_del_skill>/scripts/scaffold_team.py "<directorio_del_proyecto_objetivo>" \
  --profile "<resumen_del_diagnóstico_del_equipo>" \
  --session-mode "manual"

Al expandir según el diagnóstico, pasar los roles explícitamente:

python3 <directorio_del_skill>/scripts/scaffold_team.py "<directorio_del_proyecto_objetivo>" \
  --profile "Software + Fuerte en datos + Privacidad/plataforma + Con presupuesto" \
  --roles "lead,product,design,dev,data,test,security,finance" \
  --session-mode "auto"

Roles opcionales:

Capa de gestión: lead
Capa de ejecución: do/research/planning/product/design/dev/data/auto/content/growth
Capa de auditoría: review/test/security/finance

El script creará docs/collaboration/README.md, departamentos.md, lista-de-inicio-de-sesiones.md, reglas-de-enrutamiento.md, colección-de-errores.md, plantilla-de-traspaso-de-tareas.md, conclusiones-especiales/, scripts/agent_team_read.py y, dentro de departamentos/<nombre_del_departamento>/, los archivos descripción-del-puesto.md, guía-de-inicio.md, documento-de-traspaso.md, bandeja-de-entrada.md, informes/, registros/<semana ISO>.md; la capa de auditoría también incluye informes-de-control/ (semánticamente informes de auditoría) para compatibilidad con nombres antiguos. El script rechaza sobrescribir capas de colaboración existentes, rechaza roles duplicados y rechaza equipos nuevos sin capa de gestión/ejecución/auditoría; si no se pasa --session-mode auto/manual, se detiene para evitar omitir la confirmación del modo de sesión.

Modo de creación de sesiones

Creación automática de sesiones (Codex / Con herramienta de gestión de sesiones)

Después de que el usuario confirme el modo automático:

Primero ejecutar el script para crear docs/collaboration/.
Usar tool_search para buscar las herramientas de sesión create_thread, send_message_to_thread, set_thread_title; fijar y ordenar no son capacidades necesarias.
Si las herramientas están disponibles, crear una sesión para cada departamento; se recomienda usar un prefijo numérico para mantener el orden, por ejemplo, 01 Departamento de Coordinación, 02 Departamento de Producto, 03 Departamento de Desarrollo.
Enviar la guía-de-inicio.md de cada departamento como mensaje de inicialización a la sesión correspondiente, solicitando que la sesión primero asuma el relevo e informe solo sobre responsabilidades / etapa / en curso / bandeja de entrada / problemas pendientes de confirmación, sin realizar tareas de negocio inmediatamente.
Escribir el ID de la sesión devuelto en docs/collaboration/departamentos.md y registrar el modo de notificación como automático. Si la herramienta de envío falla, cambiar el modo de notificación de este departamento a manual e informar al usuario que la creación automática de la sesión no se ha completado.
Finalmente, informar al usuario: qué sesiones se han creado, qué IDs de sesión se han registrado y qué necesita ser gestionado manualmente por el usuario.

Si la herramienta no está disponible o la llamada falla, no decir "sesión creada"; pasar al modo manual para finalizar.

Creación manual de ventanas de sesión (Otro agente / Sin herramienta de gestión de sesiones)

Después de que el usuario confirme el modo manual:

Solo ejecutar el script para crear docs/collaboration/ y los archivos de cada departamento.
No llamar a herramientas de sesión, no afirmar que se ha creado una sesión.
Generar una lista de inicio manual: la ruta de la guía-de-inicio.md correspondiente a cada departamento, el nombre de ventana sugerido y la primera frase que el usuario debe pegar en esa sesión.
El ID de la sesión en docs/collaboration/departamentos.md se mantiene como pendiente de registro, y el modo de notificación se mantiene como pendiente de registro o se cambia a manual según las indicaciones del usuario.
Después de que el usuario cree manualmente las ventanas, enviar la guía-de-inicio.md de cada departamento a la sesión correspondiente; la sesión del departamento primero ejecuta docs/collaboration/scripts/agent_team_read.py onboard --dept [nombre_del_departamento], luego lee la descripción del puesto, el traspaso, la colección de errores y la bandeja de entrada según los archivos obligatorios devueltos por el script; después de eso, todos los traspasos se escriben en el bandeja-de-entrada.md de la carpeta del departamento correspondiente.

Después de la creación, verificar:

La estructura docs/collaboration/ está completa, las tres capas tienen al menos un departamento cada una.
Se ha añadido la explicación de colaboración multi-sesión a docs/agent-guide.md.
En docs/collaboration/lista-de-inicio-de-sesiones.md se ha especificado el modo automático/manual y la entrada de inicio para cada departamento.
En modo automático, departamentos.md tiene registrados los IDs de sesión reales y el modo de notificación; en modo manual, se ha indicado claramente al usuario que las sesiones aún no se han creado.
En docs/progress.md se registra la creación de la capa de colaboración, el resumen de la configuración del equipo y el siguiente paso.
Ejecutar git status --short; si solo hay cambios relacionados con la capa de colaboración de esta vez, se puede hacer un commit por separado:

git add docs/agent-guide.md docs/progress.md docs/collaboration
git commit -m "chore: Montar capa de colaboración multi-sesión"

Si el repositorio ya tiene otros cambios no confirmados, no mezclar el commit, explicar al usuario.

Modo de mantenimiento

Posteriormente, puede ser necesario añadir/fusionar/eliminar departamentos, reemplazar sesiones, registrar IDs de sesión, ajustar límites, asignar tareas o realizar controles independientes. Principios de gestión:

Primero leer docs/collaboration/departamentos.md para confirmar las tres capas y los departamentos existentes.
Determinar si se rompe la regla de "al menos uno en cada una de las tres capas" o los límites de responsabilidades.
Cualquier cosa que involucre añadir/eliminar/reemplazar departamentos, mensajes entre sesiones, autorización, retrabajo, o actualización de estado, primero obtener la confirmación del usuario.
Para añadir departamentos, usar scaffold_team.py <proyecto> --add-roles "<ids>"; el script solo crea los departamentos faltantes y añade a la tabla de departamentos, aún se necesita sincronizar manualmente las reglas de flujo afectadas.
Para eliminar/fusionar departamentos, primero registrar los asuntos en curso y el historial en los registros, luego actualizar la tabla de departamentos y las descripciones de puesto relevantes; no eliminar el historial directamente.
El registro de capacidad de notificación solo se realiza una vez al comenzar o al tomar el relevo:
- Leer el "modo de notificación" del departamento en departamentos.md. Si ya está registrado como automático o manual, esta sesión lo ejecutará según ese modo en el futuro, sin necesidad de volver a detectar la herramienta cada vez que se complete una tarea.
- Si el modo de notificación es pendiente de registro, usar tool_search para buscar herramientas de envío como send_message_to_thread; si no hay tool_search o no se encuentra ninguna herramienta de envío, registrar como manual.
- automático: Las notificaciones posteriores llamarán directamente a la herramienta de envío de sesiones por defecto para enviar una activación corta, sin verificar la capacidad previamente.
- manual: Las notificaciones posteriores darán directamente al usuario una activación corta que puede copiar, pidiéndole que recuerde manualmente al departamento objetivo.
- Si la llamada real en modo automático falla, esta vez se degrada a recordatorio manual y se pide al usuario que notifique al departamento de coordinación para que actualice departamentos.md.
- Si el usuario descubre que la capacidad de la herramienta del Agente ha cambiado, que el usuario informe a la sesión del departamento de coordinación, y el departamento de coordinación actualizará el modo de notificación en departamentos.md.
Prioridad de lectura de enrutamiento:
- Las nuevas sesiones de departamento o los relevos deben ejecutar prioritariamente python3 docs/collaboration/scripts/agent_team_read.py onboard --dept [nombre_del_departamento] para que el script devuelva la identidad del departamento, el modo de notificación, los archivos obligatorios de lectura y los límites de lectura predeterminados.
- Los informes, informes de auditoría, conclusiones especiales y decisiones clave deben usar frontmatter YAML para escribir type / department / target / status / date / related_task / decision / tags / summary; el script solo devuelve estos campos preescritos manualmente, sin hacer resúmenes creativos.
- Antes de buscar evidencia, ejecutar prioritariamente agent_team_read.py find --type audit_report --status blocked, agent_team_read.py find --type special_conclusion --tag salida-visible-para-el-usuario o agent_team_read.py meta <ruta>; solo cuando el resumen es insuficiente, la ruta es anómala, las conclusiones están en conflicto, involucra autorización/retrabajo/seguridad/costos/publicación/calidad visible para el usuario, el usuario solicita ver la evidencia, o la tarea actual depende explícitamente del cuerpo del texto, se lee el cuerpo mínimo necesario.

AidenXu-1/agent-team-skill

¿Qué es agent-team-skill?

Preguntar en tu IA favorita

Documentación