Cómo instalar más de 300 especialistas en IA en Claude Code y Cursor

Instalar más de 300 personas de agentes de IA en Claude Code o Cursor con un solo comando, además del límite de OpenCode y lo que una biblioteca de personas no puede hacer.

INEZA Felin-Michel

INEZA Felin-Michel

1 September 2026

Cómo instalar más de 300 especialistas en IA en Claude Code y Cursor

Apidog para empresas

Despliegue local

SSO & RBAC

Conforme con SOC 2

Explorar Apidog Enterprise

En resumen: agency-agents es la colección curada más grande de personas de agentes de IA en GitHub, con 149,312 estrellas a partir del 1 de septiembre de 2026. Incluye más de 300 archivos de definición de agentes en aproximadamente 20 carpetas de categorías y los instala en Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Windsurf, Aider y una docena de otras herramientas con un solo comando. Lo que obtienes es un marco, no una capacidad. Las personas cambian la forma en que tu agente aborda una tarea; no le proporcionan hechos que no tiene, y no persisten más allá de la sesión.

Esto es un análisis en profundidad de una herramienta de nuestro resumen de cinco herramientas de agentes de IA de código abierto que vale la pena instalar en 2026.

Tu agente de codificación tiene una personalidad: generalista útil. Pídele que revise un flujo de autenticación y obtendrás consejos sensatos, pero olvidables. Pídele a un revisor de seguridad con un modelo de amenazas y una lista de verificación, y obtendrás hallazgos.

Esa brecha es lo que agency-agents llena. Comenzó como un hilo de Reddit sobre la especialización de agentes y creció hasta convertirse en una lista tan grande que instalarlo todo rompe al menos un tiempo de ejecución de agente popular. Esto es lo que hay realmente dentro, cómo instalar las partes que deseas y las dos cosas que una biblioteca de personas no puede hacer por ti.

Lo que realmente estás instalando

Cada agente es un archivo markdown. No es un prompt de sistema de una línea, ni un plugin con código. Un archivo contiene una identidad y personalidad, una misión principal, un proceso de trabajo, entregables técnicos con ejemplos y métricas de éxito.

Contando los archivos markdown en el árbol del repositorio el 1 de septiembre de 2026, hay 312 distribuidos en 20 carpetas de categorías de nivel superior, o 306 una vez que excluyes el directorio examples/. La distribución está desequilibrada hacia la construcción de cosas:

División Archivos de agente
ingeniería 59
especializado 58
marketing 36
desarrollo de juegos 21
integraciones 18
estrategia 16
gis 13
seguridad 12
diseño 10
ventas 9
pruebas 9
medios de pago 7
gestión de proyectos 7
académico 6
computación espacial 6
soporte 6
finanzas 5
producto 5
salud 3

Cabe señalar que el README del repositorio todavía anuncia "más de 230 agentes". Esa línea está obsoleta. El árbol ha superado los 300.

La división de ingeniería es donde la mayoría de los desarrolladores comenzarán, y la especificidad es mayor de lo que cabría esperar de una colección de prompts. Junto a las entradas obvias de Desarrollador Frontend y Arquitecto Backend, hay un Ingeniero de Redes enfocado en Cisco IOS-XE, Juniper Junos y Palo Alto PAN-OS, un Ingeniero de Firmware Embebido para objetivos ESP32, STM32 y Nordic, un Comandante de Respuesta a Incidentes para post-mortems y preparación para guardias, y un Ingeniero de Integración de Codebase escrito para explorar un repositorio de solo lectura y declarar hechos sobre él en lugar de proponer cambios.

Ese último es un buen ejemplo de que el patrón funciona. Una persona de solo lectura con un mandato explícito de no edición es una herramienta genuinamente diferente de tu agente predeterminado, y no cuesta nada más que un archivo.

Instalación sin romper tu configuración

El repositorio incluye scripts de conversión e instalación. La ruta interactiva detecta lo que tienes instalado y pregunta qué quieres:

git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh

Dirigirse a una herramienta específica y a un subconjunto de divisiones es la opción predeterminada más sensata:

# todo, en Claude Code
./scripts/install.sh --tool claude-code

# solo dos divisiones
./scripts/install.sh --tool claude-code --division engineering,security

# solo agentes nombrados
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer

# ver lo que existe antes de confirmar
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run

Los objetivos compatibles incluyen Claude Code, Cursor, Codex, Gemini CLI, OpenCode, GitHub Copilot, Windsurf, Aider, Kimi Code, Hermes, Antigravity, Osaurus y Mistral Vibe. También hay una aplicación de escritorio nativa en agencyagents.app para macOS, Linux y Windows que permite explorar la lista, instalar con un clic y se actualiza automáticamente, además de un cask de Homebrew.

Lee esto antes de instalarlo todo. El tiempo de ejecución de OpenCode actualmente solo registra alrededor de 119 agentes y descarta silenciosamente el resto, lo cual el repositorio documenta como un error de origen. Instalar un subconjunto con --division te mantiene por debajo del límite, y el instalador te advierte cuando una selección lo superaría. La truncación silenciosa es el peor modo de fallo que existe, porque el agente que querías falta y nada te lo dice.

Incluso fuera de ese error específico, instalar 300 personas es una mala idea. Una lista que no puedes recordar es una lista que no usarás. Instala las dos divisiones en las que trabajas, lee cuatro o cinco de los archivos y elimina los que no coincidan con la forma en que tu equipo realmente opera.

Lo que una persona cambia y lo que no

Una persona es un marco. Establece lo que el agente busca, el formato que produce y lo que considera terminado. Eso vale más de lo que parece, porque gran parte de la mala salida del agente no es que el modelo esté equivocado, sino que el modelo optimiza para la forma de respuesta incorrecta.

Lo que una persona no puede hacer es proporcionar información que el modelo no tiene. Este es el límite que la gente descubre a la semana, y se manifiesta con mayor dificultad en torno a las APIs.

Carga el Arquitecto Backend y pídele que escriba un cliente para tu servicio de facturación interno. Producirá código limpio e idiomático contra una forma de respuesta que inventó. No tiene forma de saber que tu servicio devuelve un 409 con un sobre de error diferente cuando una clave de idempotencia se repite, o que el cursor de paginación es opaco en lugar de un desplazamiento. La persona hizo que el código estuviera mejor organizado. No lo hizo correcto.

El mismo límite se aplica a la división de pruebas. Una persona de QA escribe pruebas exhaustivas contra su propio modelo mental de la API, por lo que las pruebas pasan y no prueban nada. Cubrimos por qué ese bucle específico es peligroso en pruebas de agentes de IA no deterministas, y qué se rompe cuando la forma real cambia en qué sucede cuando los cambios de API rompen los agentes de IA.

La solución es darle al agente el contrato en lugar de esperar que la persona compense. Si tu API está diseñada en Apidog, la especificación OpenAPI es la fuente de la verdad: esquemas reales, códigos de estado reales, sobres de error reales. El agente los lee en lugar de reconstruirlos a partir de sitios de llamada. Los mocks se generan a partir de esa misma especificación, incluyendo las ramas de error que una persona nunca pensaría en simular, y el conjunto de pruebas falla ruidosamente en CI cuando la realidad y la especificación divergen.

Ese emparejamiento es el modelo mental útil. La persona decide cómo trabaja el agente. La especificación decide qué es verdad. Lecturas relacionadas: usar tu especificación OpenAPI como herramientas para agentes y diseñar esquemas de herramientas de API para agentes. Si deseas integrar una especificación en vivo en el contexto de tu agente, descarga Apidog y apúntalo a tu proyecto existente.

El segundo límite: una persona no es un equipo

Aquí está lo que la metáfora de la lista promete y no cumple.

La propuesta es una agencia completa a tu alcance. En la práctica, activas una persona en una sesión, realiza una tarea y la sesión termina. Mañana vuelves a teclear la activación. No hay equipo, porque no hay nada persistente: ninguna asignación, ningún registro de lo que el revisor de seguridad encontró el martes pasado, y ninguna forma para que un colega vea nada de eso. Nueve de las divisiones en este repositorio describen roles que solo tienen sentido dentro de una organización, y la herramienta que las instala no tiene concepto de una.

Si quieres que la idea de la lista sobreviva más allá de una única sesión de terminal, la capa que falta es la gestión del trabajo. Sharkly está construido precisamente para eso, y el mapeo con agency-agents es lo suficientemente cercano como para que valga la pena detallarlo.

En pocas palabras: agency-agents te da las descripciones de los puestos de trabajo, y Sharkly te da el lugar donde esos trabajos se asignan, ejecutan y revisan. Usa el repositorio como una biblioteca de definiciones de roles para sembrar Agentes reales en lugar de como una carpeta que instalas y olvidas.

Escribe el tuyo propio, usando el suyo como plantilla

Lo más duradero que este repositorio te ofrece es un formato. Una vez que hayas leído algunos archivos, escribir una persona para tu propia pila toma unos quince minutos, y una específica de la casa siempre supera a una genérica.

La estructura que se repite en los archivos buenos:

Una versión propia para el trabajo de API podría verse así:

# Revisor de Contratos de API

## Misión
Verificar que los endpoints nuevos o modificados coincidan con la especificación OpenAPI en este
repositorio antes de que lleguen a revisión. Reportar las discrepancias. No editar código.

## Proceso
1. Leer la especificación de cada endpoint afectado por el diff actual.
2. Para cada uno, comparar el manejador con la especificación: códigos de estado,
   esquema de respuesta, sobre de error, encabezados requeridos, estilo de paginación.
3. Ejecutar las pruebas de contrato. Registrar los fallos textualmente.
4. Comprobar que se añadieron nuevos endpoints a la especificación, no solo al enrutador.
5. Marcar cualquier campo de respuesta presente en el código y ausente en la especificación.

## Entregables
Una tabla: endpoint, método, tipo de discrepancia, línea de especificación, línea de código, severidad.
Sin resumen en prosa. Sin soluciones sugeridas a menos que se solicite.

## Hecho cuando
Cada endpoint en el diff aparece en la tabla con un veredicto, y la
salida de la prueba de contrato se incluye como evidencia.

Ese archivo es corto y hace más por un equipo de backend que cualquiera de las 59 personas de ingeniería incluidas en el repositorio, porque nombra tu especificación, tus pruebas y tu definición de lo que está hecho. El tercer paso es la parte que importa: la persona recibe instrucciones de producir evidencia en lugar de una opinión, lo que es la diferencia entre una revisión sobre la que puedes actuar y un párrafo de tranquilidad.

El mismo truco funciona para la respuesta a incidentes, el trabajo de migración, las actualizaciones de dependencias y la integración. Toma la estructura del archivo, mantén la disciplina del proceso, reemplaza el contenido genérico con el tuyo. Cuando la salida del agente tiene que sobrevivir a una entrega a un humano o a otro agente, el contrato de formato hace la mayor parte del trabajo, que es el punto que señalamos en entrega de agente y paso de contexto.

¿Son significativos los recuentos de estrellas aquí?

149,312 estrellas es mucho, y merece una advertencia. Los repositorios de personas acumulan estrellas más rápido que casi cualquier otra categoría porque son fáciles de entender, fáciles de compartir y no cuestan nada probarlos. Una estrella significa que alguien pensó que era una buena idea, no que todavía la use.

Lo que hace creíble a este repositorio es la forma del trabajo más que el número. Tiene un historial de contribuciones real desde octubre de 2025, tiene licencia MIT, documenta sus propios límites incluyendo el tope de registro de OpenCode, y los archivos de agente contienen contenido de dominio específico en lugar de información genérica de roles. Compara eso con los muchos repositorios de “prompts impresionantes” que alcanzaron su punto máximo y se detuvieron.

Júzgalo abriendo tres archivos en una división que conozcas bien. Si el archivo de Desarrollador Frontend dice cosas que diría un buen desarrollador frontend, el resto probablemente está bien. Si parece una oferta de trabajo, omite el repositorio.

Cómo obtener valor real de ello

Un flujo de trabajo que se sostiene:

  1. Instala una división. Elige la que coincida con tu trabajo diario. Ingeniería para la mayoría de los lectores.
  2. Lee los archivos. Cuatro o cinco, de principio a fin. Estás buscando las secciones de proceso, que son la parte que vale la pena conservar.
  3. Edítalos. Añade tu pila, tus convenciones, tu definición de lo que está hecho. Una persona que describe una tienda React genérica vale menos que el mismo archivo con tus reglas de prueba.
  4. Da entradas reales a las personas editadas. Un revisor de seguridad con tu especificación OpenAPI encuentra problemas de contrato. El mismo revisor sin ella produce una lista de verificación.
  5. Promueve los que se mantengan. Cualquier persona a la que recurras dos veces por semana debería convertirse en un Agente guardado en un sistema de gestión del trabajo en lugar de un archivo que copias entre máquinas.

Ese último paso es donde los equipos o escalan esto o lo abandonan silenciosamente.

Preguntas Frecuentes

Conclusión

agency-agents es la mejor versión de una idea específica: tu agente hace un mejor trabajo cuando sabe qué papel está desempeñando. Instala una división, lee los archivos, edítalos para que coincidan con tu equipo y obtendrás un valor real con unos veinte minutos de configuración.

Luego, sé honesto sobre las dos cosas que no resuelve. Las personas no saben lo que devuelve tu API, para lo cual está Apidog, y no persisten en nada que un equipo pueda ver o revisar, para lo cual está Sharkly. Una lista es un buen comienzo. No es una organización, y no es una fuente de verdad.

botón

Practica el diseño de API en Apidog

Descubre una forma más fácil de construir y usar APIs