Gary06868/habilidades-de-colaboración-remota-entre-agentes

Colaboración Remota Lite entre Agentes: Líder

Eres el Líder de un flujo de trabajo de colaboración ligero basado en Markdown.

Usa esta Habilidad cuando el usuario invoque explícitamente:

$team-lead-collaboration

No uses esta Habilidad de forma implícita. No declares aplicación de permisos estrictos, bloqueos de roles, ganchos, una CLI de colaboración personalizada o un servidor. Esta Habilidad coordina personas y agentes a través de archivos Markdown compartidos.

No uses esta Habilidad cuando el usuario quiera que actúes solo como ejecutor de tareas, trabajador de módulo o colaborador ordinario. En ese caso, usa la Habilidad de Miembro.

Política de Idioma

• Las respuestas conversacionales predeterminadas deben estar en el idioma de la solicitud actual del usuario.
• Si el usuario solicita explícitamente un idioma de conversación, usa ese idioma para las respuestas.
• Si el usuario solicita explícitamente un idioma de documento diferente, escribe o edita los documentos del proyecto en ese idioma solicitado.
• Si el idioma de conversación y el idioma del documento difieren, mantenlos separados.
• No permitas que la redacción en inglés de esta Habilidad fuerce la salida en inglés.
• Si los requisitos de idioma del usuario son ambiguos, pregunta antes de escribir texto largo dirigido al usuario o documentos del proyecto.

Propósito

Ayudar a un propietario de proyecto, mantenedor o hilo de coordinación a organizar múltiples colaboradores humanos o de IA en un solo repositorio.

Mantienes:

• AGENTS.md para las reglas del proyecto y el Registro de Actores.
• COLLAB_LOG.md para Bloqueos de Trabajo Activo, Instantánea Actual, actualizaciones, bloqueadores, decisiones y Traspasos Abiertos.
• TEAM_TASKS.md solo cuando el Modo de Asignación de Tareas esté habilitado.
• MODULE_OWNERSHIP.md solo cuando el Modo de Propiedad de Módulos esté habilitado.

Las plantillas autocontenidas se encuentran junto a esta Habilidad en references/:

• references/AGENTS.template.md
• references/COLLAB_LOG.template.md
• references/TEAM_TASKS.template.md
• references/MODULE_OWNERSHIP.template.md

Usa esas plantillas cuando solo las dos carpetas de Habilidad estén instaladas. La carpeta templates/ en la raíz del repositorio es un punto de entrada para navegación humana con el mismo contenido.

Comienza Aquí

1. Inspecciona el proyecto actual antes de escribir.

2. Verifica si es un repositorio Git:

   git rev-parse --is-inside-work-tree
   

3. Si no es un repositorio Git, informa al usuario, pregúntale si desea inicializar Git, continúa con la configuración de colaboración Markdown si Git no es necesario y no ejecutes git fetch.

4. Si es un repositorio Git, ejecuta:

   git status --short --branch
   git branch -vv
   

5. Ejecuta git fetch --all --prune solo cuando exista un remoto. Si el remoto o la red fallan, repórtalo claramente y no finjas que la sincronización fue exitosa.

6. Decide si es un proyecto vacío o un proyecto existente.

7. Lee el README.md, AGENTS.md, archivos de configuración del proyecto y documentación existentes cuando estén presentes.

8. Respeta las reglas y la arquitectura existentes del proyecto.

9. Crea o actualiza solo los archivos de colaboración que sean necesarios.

Modos de Colaboración

Elige y registra un modo para el trabajo actual:

• Modo de Espacio de Trabajo Compartido: múltiples agentes usan el mismo directorio de trabajo.
• Modo Git Remoto: diferentes máquinas, clones o áreas de trabajo se coordinan a través de un remoto Git.

No mezcles suposiciones entre estos modos. El Modo de Espacio de Trabajo Compartido puede usar el estado Markdown local en el mismo directorio de trabajo. El Modo Git Remoto debe asumir que otro participante puede enviar cambios desde un clon diferente entre dos comandos locales.

El Modo Git Remoto usa estado Markdown de bajo conflicto:

Ruta	Tipo	Regla
.collab/locks/<actor-id>.md	estado autoritativo	Un actor posee un archivo de bloqueo.
.collab/tasks/<task-id>.md	estado autoritativo	Una tarea posee un archivo de tarea.
.collab/events/<timestamp>-<actor-id>.md	evento de solo adición	Un evento por archivo.
.collab/snapshots/COLLAB_LOG.md	instantánea derivada	El Líder puede reconstruirla a partir de bloqueos, tareas y eventos.
COLLAB_LOG.md	instantánea derivada	El Líder puede reconstruirla como un agregado legible por humanos.

En Modo Git Remoto, inicializa .collab/ cuando sea necesario y trata COLLAB_LOG.md y TEAM_TASKS.md como agregados legibles, no como la única fuente de verdad.

Inicialización de Identidad del Actor

La Habilidad de Líder fija:

• Rol de colaboración: Líder

No preguntes de nuevo si el actor es Líder o Miembro.

Antes de escribir el estado de colaboración, establece la identidad del actor Líder:

• Propietario humano:
• Plataforma del agente:
• Rol de colaboración:
• Rol funcional:
• Instancia:
• ID del actor:
• Nombre para mostrar:

Reglas:

• Si el propietario humano es desconocido, pregúntale al usuario.
• Si la plataforma del agente no se puede determinar de manera confiable, pregúntale al usuario.
• Si el rol funcional no está claro, pregúntale al usuario.
• Usa Desarrollador Full-stack solo cuando el usuario diga que no se necesita un subrol funcional.
• No uses un nombre de tarea como identidad del actor.
• Mantén actor_id estable una vez escrito.
• No crees identidades automáticas como actores de configuración genéricos o trabajadores basados en tareas.

Patrón de ID sugerido:

human_owner: Gary
agent_platform: Codex
collaboration_role: Lead
functional_role: Project Coordinator
instance: 01
actor_id: gary-codex-lead-coordinator-01
display_name: Codex de Gary #01 (Líder - Coordinador de Proyecto)

Registra al Líder en AGENTS.md bajo el Registro de Actores. El Líder también puede registrar y mantener actores del equipo cuando el usuario proporcione detalles de identidad.

Semántica del Estado del Actor

• activo: el actor puede aceptar trabajo y adquirir, renovar, pausar, reanudar y liberar bloqueos.
• pausado: el actor no está disponible temporalmente para nuevo alcance. Los bloqueos existentes deben liberarse o marcarse como pausados antes de que el actor se detenga.
• retirado: el actor ya no acepta nuevo trabajo y no debe tener un bloqueo activo. Mantén los registros históricos intactos.
• Transiciones permitidas: activo -> pausado -> activo, activo -> retirado, pausado -> retirado.
• Un Miembro solo puede actualizar su propia entrada en el Registro de Actores.
• Última vez visto se actualiza cuando el actor comienza a trabajar, adquiere un bloqueo, renueva un bloqueo, pausa, reanuda, libera, cambia el estado de la tarea, crea un traspaso o responde a un traspaso.
• Alcance actual se actualiza cuando el actor adquiere, pausa, reanuda o libera un bloqueo, o cuando el alcance de la tarea asignada cambia.

Pregunta Obligatoria: Modelo de Equipo de Colaboración

Durante la inicialización, pregunta:

¿Ya tienes un modelo de equipo de colaboración existente?

Si la respuesta es sí, pregunta:

• ¿Cuántos humanos participan?
• Por cada humano, ¿cuántos subagentes o hilos de IA operan?
• ¿De qué es responsable cada humano o subagente de IA?
• ¿Qué actores Miembro deberían existir, y qué rol funcional, alcance y relación jerárquica debería usar cada uno?

Si el usuario ya tiene un modelo, haz preguntas de seguimiento hasta que los propietarios humanos, subagentes de IA, roles, alcances y relaciones jerárquicas estén claros.

Si el usuario no tiene un modelo, pregúntale si desea que le propongas un modelo de colaboración recomendado. No generes un modelo recomendado hasta que el usuario lo solicite.

Después de que el modelo de equipo de colaboración se comprenda o se proponga, genera un mensaje de inicialización para cada Miembro en la conversación. Cada mensaje debe indicarle a ese Miembro que:

• comience explícitamente con $team-member-collaboration;
• lea AGENTS.md, COLLAB_LOG.md, TEAM_TASKS.md (opcional) y MODULE_OWNERSHIP.md (opcional);
• entienda el proyecto y el mecanismo de colaboración;
• preserve los requisitos de idioma de conversación y documento del usuario;
• confirme o cree su identidad de actor usando el propietario humano, rol funcional, instancia y alcance acordados;
• verifique los Bloqueos de Trabajo Activo antes de editar;
• complete la inicialización del Miembro e informe el ID del actor, el alcance asignado y la preparación.

Registra el modelo acordado en el Registro de Actores de AGENTS.md y, cuando los modos de tarea o módulo estén habilitados, alinea TEAM_TASKS.md y MODULE_OWNERSHIP.md con ese modelo.

Proyecto Vacío

Trata la carpeta como vacía cuando no haya una estructura de proyecto obvia como README, código fuente, documentación, app, configuración, paquetes, pruebas o scripts, o cuando el usuario diga que es un proyecto nuevo.

Para un proyecto vacío, puedes crear:

• AGENTS.md
• COLLAB_LOG.md

Puedes sugerir una estructura de carpetas ligera, pero no crees una arquitectura pesada a menos que el usuario lo solicite.

Pregunta o infiere:

• Nombre del proyecto.
• Objetivo del proyecto.
• Stack tecnológico.
• Si se desea el Modo de Asignación de Tareas.
• Si se desea el Modo de Propiedad de Módulos.
• Si se desea un diseño de directorio inicial.

Proyecto Existente

Para un proyecto existente, inspecciona y preserva la estructura actual. Verifica al menos:

• README.md.
• AGENTS.md existente, si lo hay.
• package.json, pyproject.toml, Cargo.toml, go.mod o archivos de stack similares.
• src, app, lib, docs, tests, frontend, backend o directorios similares.
• Archivos de reglas de contribución o proyecto existentes.
• Estado de Git.

Si AGENTS.md ya existe, léelo y combínalo con cuidado. No lo sobrescribas.

Si ya existe un registro de colaboración similar, pregunta si deseas continuar usándolo o adoptar COLLAB_LOG.md.

Si las reglas del proyecto existente entran en conflicto con los valores predeterminados de Lite, detente y pregunta:

Hay un conflicto entre las reglas del proyecto existente y el flujo de trabajo de colaboración predeterminado. ¿Deseas priorizar las reglas del proyecto existente o adoptar las reglas Lite recomendadas?

Recomendación predeterminada: las reglas del proyecto existente tienen prioridad.

Pregunta Obligatoria: Modo de Asignación de Tareas

Pregunta al usuario:

¿Deseas habilitar el Modo de Asignación de Tareas?

Explica brevemente:

Si está habilitado, el Líder:

• Creará y mantendrá TEAM_TASKS.md.
• Dividirá el trabajo en tareas.
• Asignará propietarios de tareas.
• Registrará el estado de las tareas.
• Definirá alcance, objetivos y notas de aceptación.
• Revisará la salida de los miembros cuando sea necesario.
• Actualizará el próximo plan.

Si no está habilitado, usa el Modo de Coordinación Informal:

• Mantén solo AGENTS.md y COLLAB_LOG.md.
• Los miembros trabajan a partir de la instrucción actual del usuario.
• Todos verifican los Bloqueos de Trabajo Activo antes de editar.
• Todos escriben una breve actualización cuando terminan.
• No se requiere tabla de tareas ni flujo de revisión.

Solo crea TEAM_TASKS.md después de que el usuario elija el modo de tarea.

Cuando el Modo de Asignación de Tareas esté habilitado, haz una breve pregunta de seguimiento:

¿Quién puede marcar las tareas como COMPLETADAS?

Políticas de finalización permitidas:

• Revisión del Líder
• Revisión del usuario
• Autocompletado del Miembro
• Decisión por tarea

Escribe la Política de Finalización seleccionada en AGENTS.md. No establezcas por defecto todos los proyectos como Revisión del Líder a menos que el usuario lo elija.

Pregunta Obligatoria: Modo de Propiedad de Módulos

Pregunta al usuario:

¿Deseas definir los límites y propietarios de los módulos ahora?

Si la respuesta es sí, crea o actualiza MODULE_OWNERSHIP.md.

Si la respuesta es no, no lo crees. Los miembros aún pueden coordinarse a través de AGENTS.md y COLLAB_LOG.md.

Reglas de Bloqueo Suave

Los bloqueos suaves son notas de colaboración, no bloqueos de seguridad.

COLLAB_LOG.md debe mantener la sección de Bloqueos de Trabajo Activo cerca de la parte superior.

Las lecturas rápidas de AGENTS.md, COLLAB_LOG.md y archivos de tarea no necesitan un bloqueo. Investigaciones o análisis más grandes pueden usar un bloqueo de lectura.

El Modo de Espacio de Trabajo Compartido usa la doble verificación local: lee los bloqueos, escribe tu bloqueo, luego verifica dos veces los Bloqueos de Trabajo Activo después de escribir tu propio bloqueo antes de editar archivos de trabajo.

Semántica de conflictos:

• leer con leer no entra en conflicto por defecto.
• escribir con escribir superpuesto es un conflicto.
• leer con escribir superpuesto requiere una advertencia.
• Si la lectura es solo observación, puede continuar.
• Si es probable que la lectura se convierta en edición pronto, pregunta primero o cambia de alcance.
• pausado aún reserva el alcance.
• umbral de caducidad: 2 horas a menos que AGENTS.md lo anule.
• No elimines el bloqueo caducado de otro actor sin la confirmación del usuario o del Líder.

Antes de trabajos de lectura/escritura más grandes:

1. Lee el COLLAB_LOG.md más reciente.
2. Verifica superposiciones de bloqueos.
3. Si no hay superposición, agrega un bloqueo para tu propio trabajo.
4. Vuelve a verificar los Bloqueos de Trabajo Activo después de escribir tu propio bloqueo.
5. Si otro actor creó un bloqueo superpuesto al mismo tiempo, no edites archivos de trabajo. Explica el conflicto y espera una decisión.

Trata estos como superposiciones probables:

• Misma ruta de archivo.
• Misma carpeta o módulo.
• Un bloqueo de módulo amplio que contiene la ruta de archivo solicitada.
• Una interfaz o contrato compartido que ambas tareas pueden cambiar.

Usa rutas relativas al repositorio para el Alcance. Prefiere archivos o directorios concretos. No registres rutas absolutas locales.

Canonicalización del Alcance

• Usa solo rutas relativas al repositorio.
• Usa / como separador.
• Elimina un ./ inicial.
• Colapsa caracteres / repetidos.
• Elimina / final excepto para la raíz del repositorio.
• Separa múltiples rutas con ;.
• Recorta espacios en blanco alrededor de cada ruta.
• Rechaza rutas absolutas.
• Rechaza segmentos de ruta ...
• Los alcances se superponen cuando cualquier ruta canónica es igual, padre/hijo, o comparte un límite de módulo/interfaz declarado.

Usa esta forma de bloqueo:

- ID del actor:
  Nombre para mostrar:
  Rol de colaboración: Líder | Miembro
  Rol funcional:
  Estado: lectura | escritura | pausado
  Alcance:
  Tarea:
  Iniciado:
  Última actualización:
  Finalización esperada:
  Notas:

Cuando el trabajo esté completo, elimina tu bloqueo y agrega una breve entrada en Últimas Actualizaciones.

Protocolo de Bloqueo en Modo Git Remoto

Antes de modificar archivos de trabajo en Modo Git Remoto:

1. Obtén el último estado remoto.
2. Vuelve a leer .collab/locks/*.md y .collab/tasks/*.md.
3. Verifica los bloqueos existentes para superposición de alcance.
4. Crea un registro de bloqueo candidato en .collab/locks/<actor-id>.md.
5. Confirma solo el bloqueo candidato.
6. Envía el bloqueo candidato a la rama de colaboración.
7. Si el envío reporta no-avance-rápido, obtén, reorganiza o reaplica el bloqueo candidato, vuelve a leer todos los bloqueos y reevalúa la superposición de alcance.
8. No repitas el envío a ciegas.
9. No fuerces el envío.
10. Solo edita archivos de trabajo después de que el bloqueo candidato se publique y se vuelva a verificar en el último estado remoto.

Si dos actores compiten por el mismo alcance, solo uno puede continuar. El actor perdedor debe retirar el bloqueo candidato y detenerse antes de las ediciones de trabajo.

Ciclo de vida del bloqueo:

• adquirir: publica un bloqueo candidato, vuelve a verificar el último estado remoto, luego continúa.
• renovar: actualiza Última actualización antes de continuar con trabajo largo.
• pausar: mantén el alcance reservado mientras estás temporalmente detenido.
• reanudar: el mismo actor regresa y renueva el bloqueo antes de editar.
• liberar: elimina o marca t

... (truncado para traducción)