Esqueleto de Proyecto Colaborativo Multiagente (Reanudable entre Software)

Instalación en una línea (el usuario ejecuta cuando te pide "instala este skill")

Repositorio fuente: https://github.com/aduhappy/multi-agent-project-skill. Clonar en el directorio skills de tu herramienta para instalarlo (sin otras dependencias).

Los directorios skills varían según la herramienta. Elige la ruta correcta:

Herramienta	Directorio skills de usuario	Directorio skills de proyecto
ZCode / Codex CLI	`~/.agents/skills/`	`<proyecto>/.agents/skills/`
Claude Code	`~/.claude/skills/`	`<proyecto>/.claude/skills/`
Cursor	N/A (usar rules)	`.cursor/rules/` (formato moderno) o `.cursorrules` (legacy)

Principios generales:

En Windows, ~ = %USERPROFILE%.
Si no estás seguro entre usuario o proyecto, por defecto usuario (instálalo una vez y estará disponible en todas partes).
Si el directorio no existe, créalo antes de clonar. Después de clonar, informa al usuario que abra una nueva sesión para activar este skill.

¿Qué hace este skill?

Genera en la raíz del proyecto un esqueleto de colaboración en Markdown puro, independiente del software: una entrada autorizada + varios punteros ligeros + tarjetas de tarea autocontenidas + reglas de finalización. Cambia entre Claude / Cursor / Gemini / ZCode / Copilot: cualquier agente que entre y lea esa misma entrada podrá continuar el trabajo del anterior, sin perder contexto y sin sobrescribirse.

Cuatro principios básicos:

Una única fuente de verdad: AGENTS.md es la única entrada autorizada; los archivos de convención de otras herramientas (CLAUDE.md / GEMINI.md / .cursorrules / copilot-instructions.md) son punteros ligeros de 3 líneas que apuntan a AGENTS.md.
Enlaces externos para detalles, entrada breve: AGENTS.md debe ocupar 1-2 pantallas como máximo; cada nuevo agente debe leerlo completo. Los detalles van en documentos temáticos dentro de docs/, la entrada solo contiene punteros.
Markdown puro + rutas relativas: Sin depender de sintaxis específica de ningún software; no se rompe al cambiar de herramienta.
Confiar pero verificar: La autocomprobación del agente no es suficiente; los productos críticos deben ser revisados de forma independiente por el controlador o por otro agente (conservación, límites, recuento, orden de magnitud, coherencia) antes de pasar al siguiente paso. Esta es la base de la confiabilidad en una cadena multiagente.

Cuándo activarlo

El usuario dice "nuevo proyecto/nuevo tema" "cómo organizar documentos para que la IA colabore" "cómo escribir AGENTS.md" "relevo multiagente".
En proyectos existentes, los agentes hacen preguntas repetitivas, no encuentran el estado, sobrescriben los resultados de otros.
El usuario quiere consolidar "experiencia de colaboración resumida manualmente" en una estructura reutilizable.

Cómo usarlo (dos modos)

Modo A: Generar esqueleto desde cero

Pregunta (todo de una vez, sin rodeos): directorio raíz del proyecto, objetivo en una frase, qué herramientas de IA se deben compatibilizar, si hay directorio de sincronización en la nube, qué fuentes de datos están involucradas.
Pregunta adicional por una lista de restricciones duras: "Enumera las dimensiones que 'no se pueden mezclar' en este campo (criterio/unidad/sistema de coordenadas/resolución/período/estrato de edad, etc.). Escríbelas como reglas duras; todos los agentes posteriores deben cumplirlas." — Esta es la regla de hierro que más se pasa por alto y que, cuando falla, lo arruina todo.
Copia AGENTS.md desde assets/ a la raíz del proyecto y completa con la información proporcionada por el usuario.
- Regla para marcadores de posición (importante): Rellena directamente la información que el usuario haya dado explícitamente; para lo que no haya dado, prioriza dar un valor predeterminado razonable (inferido del tema del proyecto) y anótalo brevemente como "valor predeterminado, modificable"; solo deja 【Pendiente】 para detalles que sean "específicos del usuario y no se puedan inferir razonablemente" (como un DOI concreto, una contraseña, una cuenta). Criterio: cuantos menos 【Pendiente】 haya en el cuerpo de AGENTS.md, mejor; lo ideal es 0.
Para cada herramienta que el usuario haya marcado, copia el archivo de puntero ligero correspondiente (CLAUDE.md, GEMINI.md, copilot-instructions.md, etc.), con el contenido unificado: "Basarse en AGENTS.md"; para usuarios de Cursor, recomendamos usar .cursor/rules/multi-agent.mdc (formato moderno), y .cursorrules como respaldo legacy. No generes archivos para herramientas que el usuario no haya marcado.
Crea docs/planificacion_tareas_<tema>.md (copia desde assets/plantilla_planificacion_tareas.md). Si el proyecto tiene varias tarjetas de tarea, copia también assets/README_tarjetas_tarea.md (índice de tarjetas de tarea con cadena de dependencias y estado actual). Cada tarjeta de tarea incluye al final un bloque 📋 Mensaje de delegación (listo para copiar y usar) — rellena los campos de la tarjeta, el usuario puede copiarlo y pegarlo a cualquier agente para un arranque en frío, sin tener que redactar la delegación cada vez. Al crear la tarjeta, rellena este bloque.
(Opcional) Crea según necesidad: docs/plantilla_delegacion_tareas.md (copia desde assets/plantilla_delegacion_tareas.md, para que el agente controlador delegue), docs/registro_decisiones/ (para ADR), docs/glosario.md (términos del proyecto). Nota: Estas son plantillas opcionales; omítelas en proyectos pequeños para no hacer la entrada voluminosa.
Derivar directorios de conjuntos de datos: A partir de las fuentes de datos descritas por el usuario, divide en categorías — un directorio por tipo de datos (ej.: si el usuario dice "MODIS + Landsat" → crea directorios MODIS/ y Landsat/; si dice "encuestas + mediciones" → crea encuestas/ y mediciones/). En cada directorio de conjunto de datos, coloca fuente.txt (copia desde assets/fuente.txt). Omite este paso si no hay fuentes de datos claras.
Colocar código en su lugar: Crea el directorio scripts/ + scripts/README.md (copia desde assets/scripts_README.md). Rellena la lista de scripts existentes del usuario (si los hay), o déjalo vacío para que agentes posteriores lo completen. Copia también check_handoff.py (desde assets/check_handoff.py) — script de autocomprobación de entrega; el agente lo ejecuta al finalizar con python scripts/check_handoff.py para verificar que §3/§4/STATUS se han actualizado. En la regla de hierro §5 de AGENTS.md, acuerda que "los scripts no estén dispersos en la raíz del proyecto".
Crea STATUS.md (copia desde assets/STATUS.md) — plantilla vacía; el primer agente que termine la rellena con un handoff incremental (qué hizo este agente / qué archivos modificó / en qué escollos tropezó).
Escribe el entorno y las restricciones del usuario en las secciones §Reglas de hierro y §Convenciones de ruta.
Al terminar, informa al usuario: qué archivos se generaron, qué "valores predeterminados" necesita confirmar, y qué 【Pendiente】 debe completar.

Modo B: Diagnosticar un proyecto existente

B1: Reparar un proyecto deficiente (sin documentación o con documentación desordenada)

El usuario tiene un proyecto existente pero la colaboración es un caos: los agentes preguntan repetidamente, se sobrescriben, no encuentran el estado. Primero, lee el README/cualquier documentación/estructura de directorios existente, compáralo con el §Esqueleto de archivos y las §Secciones de AGENTS.md para ver qué falta, y proporciona una lista completa de reparaciones (¿faltan punteros ligeros? ¿falta la entrada? ¿las tarjetas de tarea no son autocontenidas? ¿no hay fuente.txt? ¿no hay reglas de cierre?). Después de que el usuario lo confirme, completa lo que falta. Lee primero, luego modifica; nunca sobrescribas archivos existentes directamente.

B2: Mejorar un proyecto bueno (ya tiene buena documentación, solo le faltan punteros ligeros)

El usuario ya tiene una buena documentación del proyecto (ej.: AI_COLLABORATION_PLAN.md / README.md / wiki detallada), pero las herramientas de IA no la leen automáticamente (Codex/Claude leen AGENTS.md por defecto y no descubren nombres de archivo personalizados). Solo añade un AGENTS.md como puntero ligero (3 líneas) que apunte a la documentación existente; luego, según las herramientas que el usuario haya marcado, añade los archivos de puntero ligero correspondientes (CLAUDE.md, etc.). No modifiques ningún documento existente. Criterio: después de añadirlos, un nuevo agente entra → lee AGENTS.md → salta a la documentación existente → obtiene el contexto completo, sin que el usuario tenga que decir manualmente "primero lee el archivo XX".

Esqueleto de archivos (cómo queda después de la generación)

<raíz del proyecto>/
├── AGENTS.md                          ← Única entrada autorizada (TL;DR de 3 líneas en la parte superior + siete secciones; todas las herramientas lo leen por defecto)
├── STATUS.md                          ← Handoff incremental (qué hizo este agente / qué archivos modificó / en qué escollos tropezó; se escribe al finalizar)
├── CLAUDE.md                          ← Puntero ligero → "Basarse en AGENTS.md"
├── GEMINI.md                          ← Puntero ligero (igual, opcional)
├── .cursorrules                       ← Puntero ligero (para Cursor, opcional)
├── .github/copilot-instructions.md    ← Puntero ligero (para Copilot, opcional)
├── docs/
│   ├── planificacion_tareas_<tema>.md ← Tarjeta de tarea autocontenida (incluye lista de "obligatorio antes de entregar" + modelo sugerido opcional)
│   ├── README_tarjetas_tarea.md       ← Índice de tarjetas de tarea (cadena de dependencias + tabla de estado actual, opcional)
│   ├── plantilla_delegacion_tareas.md ← Discurso estándar para delegar tareas a un agente IA (copiar y rellenar, opcional)
│   ├── registro_decisiones/           ← Decisiones técnicas clave (opcional, ver advanced.md)
│   └── glosario.md                    ← Términos del proyecto (opcional)
├── <nombre_conjunto_datos>/           ← Un directorio por cada conjunto de datos
│   ├── fuente.txt                     ← DOI/URL/fecha/criterio/unidad
│   └── ...
├── scripts/                           ← Colocar código aquí (recomendado: los scripts no deben estar dispersos en la raíz)
│   ├── README.md                      ← Una línea por script: qué hace / entrada / salida / quién lo escribió
│   └── check_handoff.py               ← Script de autocomprobación de entrega (ejecutar para verificar que §3/§4/STATUS se han actualizado)
└── registro_progreso.md               ← Registro de cambios con marca de fecha (opcional)

Secciones de AGENTS.md (el orden es la prioridad)

Completa según la plantilla en assets/AGENTS.md. En la parte superior, primero un bloque TL;DR (3 líneas: etapa actual / siguiente paso / bloqueo) para que un nuevo agente sepa el estado de un vistazo; luego 8 secciones (numeradas 1–7 en la plantilla, donde las convenciones de ruta se numeran por separado como §5.5 porque son demasiado importantes para mezclarlas con las reglas de hierro):

TL;DR (lectura rápida al entrar) — 3 líneas: etapa actual, siguiente paso, bloqueo. Se actualiza cada vez que se finaliza. Un nuevo agente no necesita leer todo el documento para saber en qué punto está.
Estrella polar en una frase — De qué trata realmente este proyecto, para quién, y qué tono tiene (estilo, objetivo de publicación/entrega, qué no debe retrasar la línea principal).
Historia/método actual — Última dirección acordada + método central + qué se ha cambiado recientemente y por qué.
Dónde estamos ahora — Se actualiza cada vez que se finaliza; de 1 a 5 instantáneas acumulativas con marca de fecha. Este es el punto de transferencia más crítico para el relevo. Los detalles incrementales van a STATUS.md; esta sección solo contiene el estado acumulativo.
Tablero de tareas — [ ]/[x] + responsable + dependencias (T1→T2, cuáles son paralelizables) + riesgos conocidos.
Reglas de hierro / Convenciones — Lo que causa retrabajo si se viola: llamadas al entorno, reglas de gráficos/datos, nomenclatura, criterio, reglas de cierre. Incluye "Lo primero que hace un nuevo agente (incluidos subagentes) al entrar: leer AGENTS.md antes de actuar". 5.5. Convenciones de ruta — Dónde van los archivos grandes, dónde vuelven los productos pequeños (para evitar colisiones multiagente y explosiones de sincronización en la nube). Sección independiente, no la entierres en las reglas de hierro.
Punteros de lectura profunda — A qué documento ir para los detalles (reglas de tarea, registro de decisiones, glosario, índice de tarjetas de tarea).
Entorno / Herramientas — Cómo invocar las rutas completas de las herramientas, bloqueo de env.

División de trabajo entre STATUS.md y §3 de AGENTS.md (para evitar superposición): STATUS.md registra el incremento (qué hizo este agente en esta ronda, qué archivos modificó, en qué escollos tropezó); §3 de AGENTS.md registra la instantánea acumulativa (progreso general actual, 1–5 puntos). No se superponen — STATUS.md es "cambios desde la última vez", §3 es "dónde estamos ahora en general".

Tabla de registro de decisiones (muy recomendada, no la trates solo como avanzada): Recoge las decisiones vinculantes en una tabla acotada y grepeable — una decisión por fila: ID | Decisión | Valor/Criterio | Razón | Fecha | Enlace de evidencia | Sustituye a. Colócala bajo el puntero §6 de AGENTS.md, o en la sección §3 adyacente. Se diferencia de los ADR libres dispersos en las narrativas largas de STATUS: acotada (una decisión por fila, siempre se puede leer completa), consultable (grep por palabra clave encuentra la fila autorizada al instante), trazable (cadena supersedes). Esta es una capa clave para evitar que "las decisiones queden enterradas en largos registros, o que un script desactualizado las sobrescriba silenciosamente". Plantilla en references/advanced.md §1.

Requisitos estrictos para la reanudación entre software (7 reglas)

Markdown puro + rutas relativas + nombres de archivo estándar — No uses sintaxis propia de un software, no codifiques rutas absolutas.
Los datos deben llevar fuente.txt (DOI/URL/fecha de descarga/criterio/unidad/problemas conocidos) — Al cambiar de persona o agente, se pueda rastrear el origen.
Las reglas de cierre deben escribirse en las reglas de hierro — Cada agente, antes de salir, actualiza §Dónde estamos ahora + §Tablero de tareas + escribe/actualiza STATUS.md (handoff incremental: qué hizo este agente en esta ronda, qué archivos modificó, en qué escollos tropezó; no repite la instantánea completa de §3). Al finalizar, ejecuta python scripts/check_handoff.py para autocomprobación — verifica que la fecha de §3 sea reciente, que TL;DR esté relleno, que STATUS.md no sea la plantilla, que la fecha de STATUS ≥ fecha de §3, que los punteros ligeros existan; también incluye dos comprobaciones advisory (si existe la tabla de registro de decisiones, si las constantes de criterio en múltiples scripts han derivado). Solo se considera entrega合格 si todo pasa.
Disciplina de ruta — "Los archivos grandes van al disco de trabajo, los productos pequeños vuelven al repositorio" "Copia, no cortes; no toques las rutas que otros están usando".
Lo primero que hace un nuevo agente (incluidos subagentes) al entrar — Leer AGENTS.md (incluido STATUS.md) antes de actuar; no confiar en el historial de la conversación ni adivinar de memoria. STATUS.md se vuelve más largo y nadie lo lee completo — por lo tanto, cualquier decisión vinculante (criterio/lista de exclusión/parámetros seleccionados) debe ascender a la sección §3 de AGENTS.md o a la tabla de registro de decisiones, un nivel acotado y de lectura obligatoria, y no quedarse solo en la larga narrativa de STATUS. Antes de extraer datos/modelar/reproducir, consulta este nivel; no confíes en una codificación fija dentro de un script.
Fuente única para cifras clave y parámetros de criterio, prevenir la deriva — Las cifras clave (medias/porcentajes/áreas, etc.) solo se escriben en un lugar (STATUS.md o §3 de AGENTS.md); en otros lugares solo se referencia, no se repiten. Los parámetros de criterio/conjuntos de muestra/listas de exclusión (qué puntos se usan, cuáles se descartan, umbrales) son iguales: introduce un único config (config/parametros.yaml o una tabla autorizada); todos los scripts lo leen; está terminantemente prohibido codificarlos fijamente en múltiples scripts — que dos scripts tengan codificaciones inconsistentes para el mismo conjunto es la fuente más oculta de accidentes de relevo (la autocomprobación no lo detecta, ni la verificación de formato). Antes de finalizar, verifica la coherencia entre todos los documentos y los scripts; si el mismo número difiere en más del 1%, o los miembros del mismo conjunto son inconsistentes, se considera un error; primero alinea y luego entrega.
Los productos defectuosos y los scripts obsoletos deben ser retirados y aislados juntos — Si se descubre que el producto de un agente es erróneo (datos/gráficos/números), inmediatamente: ① renombra el directorio añadiendo el sufijo _OBSOLETO o colócalo en un subdirectorio _descartado/; ② en la parte superior de la sección §5 Reglas de hierro de AGENTS.md, márcalo en rojo con > ⚠️ 【OBSOLETO】<ruta> (no lo marques en §3 — §3 es la instantánea acumulativa; la marca de producto defectuoso debe estar en la misma sección que las reglas de hierro/normas); ③ actualiza el estado en §4 Tablero de tareas a [x] + anotación "obsoleto"; ④ actualiza STATUS.md para reflejar la obsolescencia; ⑤ los scripts/métodos antiguos que han sido reemplazados por una decisión también deben ser retirados — añade un comentario en la parte superior del script con # _OBSOLETO → ver <script/decisión autorizado>, para que no atrape al siguiente agente como un criterio vivo. Nunca confíes solo en la memoria para decir "ese no lo uses" — que un agente downstream reutilice silenciosamente un producto defectuoso, o copie el criterio de un script desactualizado, es más letal que no tener ningún resultado.

💡 Una lección real de relevo (de aquí surgieron estas 3 reglas): Un agente necesitaba volver a ajustar una curva y copió el conjunto de muestra de un script desactualizado — ese script aún conservaba puntos malos que deberían haberse eliminado hacía tiempo, y la decisión de "eliminar ese punto" solo estaba enterrada en las 600 líneas de STATUS, y además los dos scripts tenían codificaciones opuestas para ese punto. El resultado fue que ese punto arrastró el R² de 0.5 a 0.27, y el informe externo fue rechazado. En retrospectiva, se podría haber evitado en tres puntos: la decisión no había ascendido al nivel acotado y de lectura obligatoria (regla 5), el conjunto de criterio estaba codificado fijamente en múltiples scripts en lugar de en un único config (regla 6), y el script antiguo reemplazado no tenía una marca de retiro (regla 7). Confiar en un script desactualizado, no en el registro de decisiones es la causa raíz común de este tipo de accidentes.

Flujo de trabajo central (proceso completo de relevo de agentes)

Un ciclo de vida típico de transferencia multiagente consta de 5 pasos explícitos. Saltarse el paso ③ "Revisión independiente" es la causa raíz de la mayoría de las contaminaciones de la cadena.

① Delegación → ② Ejecución + Autocomprobación → ③ Revisión independiente → ④ Aceptación e incorporación → ⑤ Handoff y registro

Explicación detallada de los pasos

① Delegación (controlador → agente ejecutor) Usa el discurso estándar (ver plantilla a continuación o assets/plantilla_delegacion_tareas.md) para especificar claramente: qué leer, qué hacer, qué no tocar, dónde poner la salida, dónde registrar las dudas.

② Ejecución + Autocomprobación (agente ejecutor) Ejecuta la tarea, al terminar ejecuta la DoD (lista de verificación de aceptación), confirma que la salida está completa, el formato es correcto y no hay errores.

③ Revisión independiente (el controlador u otro agente verifica las cifras clave) No confíes en la autocomprobación — que el agente ejecutor pase su autocomprobación no significa que el producto sea correcto (se ha demostrado repetidamente que no es suficiente).

El controlador o un tercer agente verifica las cifras clave: conservación (¿la suma de entrada ≈ suma de salida?), límites (¿hay valores fuera de rango / sin recortar?), recuento (¿el número de filas/píxeles coincide con lo esperado?), orden de magnitud (¿la unidad difiere en 10³?), coherencia (¿el mismo número en diferentes documentos es consistente?).
Si pasa → va al paso ④; si no pasa → se devuelve al agente ejecutor para que lo repare y se registra un ADR.
Criterio: "Revisión independiente aprobada" es la puerta de entrada al siguiente paso, no una opción.

④ Aceptación e incorporación Una vez confirmado que el producto es correcto, se coloca oficialmente en su lugar; se actualiza fuente.txt (si son nuevos datos) y scripts/README.md (si es un nuevo script).

⑤ Handoff y registro Actualiza §3 de AGENTS.md (estado actual) + §4 (tablero de tareas) + escribe STATUS.md. Asegúrate de que el siguiente agente pueda continuar solo con el Markdown del repositorio.

💡 Para cadenas cortas (1-2 agentes, productos simples), se puede omitir el paso ③; para productos que afectan las conclusiones de un artículo o las tuberías posteriores, es obligatorio seguir los 5 pasos.

Dos niveles de reanudación (ambos necesarios)

Reanudación dura (dependencia principal): El Markdown en el repositorio, independiente del software, legible por cualquier agente/persona. Esta es la fuente de verdad.
Reanudación blanda (mejora): Capa de memoria (Cursor memory / Claude memory) para acelerar la recuperación, pero no dejes que las conclusiones clave vivan solo en la memoria — deben volver al Markdown.

Criterio: Si se eliminan todas las capas de memoria, el siguiente agente debe poder continuar solo con el Markdown del repositorio → es合格.

Discurso estándar para delegar tareas a un agente IA

Cada vez que se delega un nuevo agente, usa un formato uniforme al principio — el efecto es mucho mejor que improvisar. Según assets/plantilla_delegacion_tareas.md:

Por favor, lee primero AGENTS.md (incluido STATUS.md para conocer el estado actual). No modifiques los datos originales () ni el código central existente (). Esta tarea solo maneja la fase X. Si encuentras dudas o nuevos problemas, regístralos en , no los corrijas directamente. La salida debe estar en . Escollos conocidos de esta tarea: [enumera los puntos de riesgo conocidos] Autocomprobación obligatoria antes de entregar: [conservación/límites/recuento/orden de magnitud..., repasa uno por uno]

El valor central de esta plantilla: permite que un nuevo agente en frío sepa inmediatamente qué leer, qué no tocar, y dónde informar si hay problemas. Las columnas "escollos conocidos" y "autocomprobación obligatoria" son incrementos clave validados en la práctica — guían al agente para que intercepte tipos de errores comunes antes de informar que ha terminado, reduciendo drásticamente la tasa de defectos.

Para tareas clave que afectan las conclusiones de un artículo o las tuberías posteriores, añade al final del discurso la instrucción "organizar una revisión independiente después de la entrega" (hay un ejemplo avanzado al final de la plantilla).

Mensaje de delegación incorporado en la tarjeta (recomendado): No dejes que el usuario tenga que rellenar este discurso cada vez — cada tarjeta de tarea incluye al final un bloque pre-rellenado 📋 Mensaje de delegación (listo para copiar y usar) (ver final de T1 en assets/plantilla_planificacion_tareas.md). Al crear la tarjeta, rellena el objetivo/límites/entrada-salida/escollos conocidos/autocomprobación/cierre; cuando el usuario quiera delegar, solo tiene que copiar ese bloque y pegarlo a cualquier agente (incluyendo entre herramientas y skills), sin tener que redactar nada sobre la marcha. plantilla_delegacion_tareas.md solo sirve como referencia de los campos.

Secciones avanzadas (activar según necesidad, ver references/advanced.md)

Además de las siete secciones centrales, estas son útiles cuando el proyecto crece, pero no las acumules todas al principio:

Registro de decisiones (ADR) — Registrar "por qué se descartó un método", para evitar que el siguiente agente vuelva a caer en el mismo error y cuestione lo ya decidido.
Glosario — Términos/abreviaturas específicas del proyecto; el nuevo agente no tiene que adivinar.
Registro de progreso — Flujo de cambios con marca de fecha, más detallado que §Dónde estamos ahora.
Concretar la aceptación — La DoD se escribe como comandos de verificación ejecutables, no como "está hecho".
Resumen de handoff estándar — Estado actual / siguiente paso / riesgos no resueltos / rutas de archivos clave.
Convenciones de nomenclatura + idempotencia — Los archivos de salida llevan _v1/fecha/sistema de coordenadas; los scripts reejecutables son idempotentes (con caché, saltan).
Bloqueo de entorno — conda env fijado con environment.yml, para prevenir deriva al reconstruir en otra máquina.
Instantánea de datos / entrada inmutable — Los datos originales son de solo lectura con hash; todos trabajan sobre copias.
Ejemplo de AGENTS.md relleno — references/example_filled_AGENTS.md, un ejemplo completo (proyecto ficticio). Es mucho más intuitivo rellenar siguiendo este ejemplo que una plantilla vacía.

Recordatorios personalizados

Este esqueleto proviene de la práctica en proyectos de investigación reales (multiagente, múltiples conjuntos de datos, tuberías largas, sincronización en la nube). Ajústalo según el dominio: para proyectos puramente frontend, puedes eliminar la parte de "disco de trabajo" de §Convenciones de ruta; para proyectos pequeños de un solo agente, simplifica el §Tablero de tareas.
Los marcadores de posición en las plantillas usan uniformemente 【Pendiente】; bórralos al completarlos.
El contenido de los archivos de puntero ligero es uniforme (ver assets/CLAUDE.md); no escribas reglas diferentes en cada uno — eso rompería el principio de "una única fuente de verdad".
No sobrescribas el AGENTS.md existente del usuario; si es el modo B de diagnóstico, lee primero, luego modifica y repara de forma incremental.

aduhappy/multi-agent-project-skill

¿Qué es multi-agent-project-skill?

Preguntar en tu IA favorita

Documentación