Las agent skills más instaladas y para qué sirven

¿Qué agentes de programación leen skills y cómo se instala una?

En nuestro artículo sobre qué es una skill explicamos qué es una skill, en qué carpeta va en Claude Code, Codex, Cursor, Gemini CLI y Copilot, y cómo se escribe un SKILL.md. Este artículo responde a la pregunta siguiente: dónde y cómo instalar skills que escribió otra persona, cuáles se instalan más y qué miden esos números.

Esos cinco ya no son los únicos agentes que leen skills. El 21 de octubre de 2026 revisamos 10 agentes de programación cuya documentación dice que leen SKILL.md. Todos leen el mismo formato; cómo instalas una skill, dónde la encuentras y cuándo llegó el soporte cambia de una herramienta a otra:

Fuente: la documentación de skills y plugins de cada agente y sus notas de versión, 21 de octubre de 2026. Versiones: Claude Code 2.0.20, Gemini CLI 0.23.0 y 0.26.0, Antigravity 1.14.2, OpenCode 1.0.190 (su nota de versión en GitHub), Cursor 2.4; gh skill requiere GitHub CLI 2.90.0 o posterior. Los plugins de Claude Code entraron en beta pública el 9 de octubre de 2025, y Codex recibió los plugins el 25 de marzo de 2026. El 18 de junio de 2026, Google cerró Gemini CLI a los usuarios gratuitos y a los suscriptores de Google AI Pro y Ultra, y lo sustituyó por Antigravity CLI; Gemini CLI sigue para quienes lo usan con una licencia de empresa o una clave de API de pago. «Su documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo diga.

Las carpetas de esas cinco herramientas las explicamos en nuestro artículo sobre qué es una skill; los agentes que no estaban en él buscan las skills aquí:

• OpenCode lee .opencode/skills en el proyecto y, por compatibilidad, .claude/skills y .agents/skills, desde la carpeta en la que estás hasta la raíz del worktree de git. Para las skills personales mira en ~/.config/opencode/skills, ~/.claude/skills y ~/.agents/skills.
• Antigravity lee .agents/skills en el proyecto; la antigua .agent/skills sigue funcionando. La CLI lee las skills personales de ~/.gemini/antigravity-cli/skills y las de los plugins de ~/.gemini/antigravity-cli/plugins/<plugin>/skills.
• Amp lee .agents/skills y .claude/skills en el proyecto. Para las personales mira en ~/.config/agents/skills, ~/.agents/skills, ~/.config/amp/skills y ~/.claude/skills, y también en la caché de plugins de Claude Code (~/.claude/plugins/cache). Si dos skills tienen el mismo nombre, usa la primera que encuentra.
• Goose lee .agents/skills en el proyecto y ~/.agents/skills para las personales; también encuentra las antiguas .goose/skills y .claude/skills.
• Pi lee .agents/skills en el proyecto, desde la carpeta en la que estás hasta la raíz del repositorio, y ~/.agents/skills para las personales.

Dos herramientas de instalación no dependen de un solo agente. El comando gh skill install de GitHub CLI, con --agent, también instala una skill en Claude Code, Cursor, Codex, Gemini CLI o Antigravity. El comando npx skills add de Vercel, según su README, instala en OpenCode, Claude Code, Codex, Cursor y 75 agentes más. Aun así, no des por hecho que una skill hará el mismo trabajo en otro agente. Según el estudio Skill Constellations, las skills copiadas a las carpetas de otros agentes llevan a menudo nombres de herramientas que solo existen en Claude Code. Mira qué herramientas llama una skill.

Además está la diferencia entre skill y plugin. La documentación de Claude Code, Codex, Cursor y Antigravity explica cómo distribuir skills de otros dentro de plugins: Cursor no importa una skill suelta de un repositorio, y Codex recomienda un plugin para distribuirlas. Pero un plugin puede traer más que skills. Según la documentación de Claude Code, un plugin puede ejecutar hooks y servidores MCP. En Codex, un plugin trae, junto a las skills, conexiones con apps y ajustes de servidores MCP; en Cursor, reglas, agentes, comandos, servidores MCP y hooks. Una skill sola, en cambio, se compone de texto, scripts y archivos de referencia. obra/superpowers, mattpocock/skills y anthropics/skills también se distribuyen como plugins.

¿Cómo se mide lo «más instalado»?

Las listas que te salen al buscar «skills más instaladas» cuentan cosas distintas. Estos son los 4 contadores que revisamos el 21 de octubre de 2026:

• skills.sh es el directorio de skills de Vercel. Según su documentación, el ranking se basa en telemetría anónima recogida por la CLI skills y solo registra qué skills se instalan. Una instalación desde un marketplace de plugins, con git clone o con gh skill no entra en este contador. Los números se llevan por skill; el «total installs» de un repositorio es la suma de sus skills y no dice cuántas personas lo instalaron. DISABLE_TELEMETRY=1 o DO_NOT_TRACK=1 desactiva la telemetría.
• El directorio de plugins de Claude (claude.com/marketplace) muestra un número de instalaciones junto a cada plugin. El número lo da Anthropic; la página no dice cómo se cuenta. Son instalaciones de plugins: además de skills, un plugin puede traer hooks, agentes y servidores MCP.
• Una estrella de GitHub cuenta que alguien guardó el repositorio como marcador, no que lo use. Según Skill Constellations, las estrellas no dicen casi nada sobre cuánto se copian las skills de un repositorio a otros repositorios («nearly uninformative»); el estudio también señala campañas de estrellas falsas.
• Las copias en GitHub las cuentan investigadores. GitSkills reunió en julio de 2026 un total de 3.797.117 archivos SKILL.md de 282.200 repositorios públicos de GitHub; al unir los contenidos idénticos quedaron 1.877.981 distintos. Según Skill Constellations, la mitad de los archivos SKILL.md de GitHub son copias literales de otro archivo; una sola skill, web-design-guidelines, se extendió, a lo largo de 12 generaciones de copias, a 972 repositorios. Los dos estudios son preprints en arXiv sin revisión por pares.

Los contadores pueden dar para el mismo paquete números que no se parecen en nada, y a veces un solo contador muestra, por sí mismo, números que no se pueden explicar. Esto es lo que vimos el 21 de octubre de 2026; no sabemos por qué:

• En skills.sh hay 6 repositorios llamados superpowers que no son obra/superpowers. Ninguno tiene más de 8 estrellas en GitHub; en skills.sh, la skill más instalada de cada uno muestra entre 341,9 mil y 825,8 mil instalaciones. Uno de ellos tiene 86 skills: 60 muestran 132 instalaciones o menos, mientras que 4 están entre 824,3 mil y 825,8 mil.
• garrytan/gstack tiene 137,1 mil estrellas en GitHub; su total en skills.sh es de 44,2 mil. Su README hace instalar el paquete con git clone, y skills.sh solo cuenta las instalaciones hechas con su propia CLI.
• El plugin mattpocock/skills tiene 1.745 instalaciones en el directorio de Claude; en skills.sh, la skill grill-me del paquete muestra por sí sola 1,4 M instalaciones. Su README recomienda el plugin para Claude Code y npx skills para muchos otros agentes; los dos contadores cuentan dos canales distintos.

La regla que sale de aquí es sencilla: lee cada número junto con el contador que lo contó. No sumes los números de dos contadores ni los compares entre sí. En la tabla de abajo también, cada contador tiene su propia columna.

¿Qué paquetes de skills se instalan más y para qué sirven?

La tabla de abajo no es un ranking. Es una selección de paquetes generales para programar que nos aparecieron a menudo en los contadores; las filas van en orden alfabético por nombre de repositorio. Las skills que una empresa escribió para su propio producto (como las de Supabase o Prisma) y los paquetes que no tratan de código no están en la tabla; mencionamos algunas skills de empresas en una sección posterior.

Fuente: las estrellas de GitHub son el número redondeado que GitHub muestra en la página del repositorio; la columna skills.sh es la skill más instalada del paquete y el número redondeado de instalaciones que skills.sh muestra en su página del repositorio; ambos del 21 de octubre de 2026. Las dos columnas son contadores distintos y no se comparan entre sí. La columna «Dónde se instala» sale del README de cada paquete: las herramientas cuya instalación describe. El README de anthropics/skills describe las skills docx, pdf, pptx y xlsx como «source-available, not open source»; vercel-labs/agent-skills no tiene archivo de licencia en la raíz, y su README indica la licencia MIT.

El directorio de plugins de Claude es un contador aparte y solo cuenta algunos de estos paquetes. Los números de instalaciones que daba Anthropic el 21 de octubre de 2026: el plugin frontend-design de Anthropic, 1.134.112; superpowers, 1.009.371; mattpocock-skills, 1.745. En el directorio, los plugins de Anthropic llevan la etiqueta «Anthropic verified»; el número también lo da Anthropic. El marketplace de Cursor y el directorio de plugins de OpenAI no muestran números de instalaciones.

¿Qué hace Superpowers y en qué herramientas funciona?

obra/superpowers monta más una forma de trabajar que un conjunto de skills sueltas. Su README lo describe como «a complete software development methodology» para agentes de programación. Su última versión es la 7.0.0 (9 de octubre de 2026), su licencia es MIT y contiene 15 skills. Cuando el agente ve que quieres construir algo, no se lanza al código: primero te pregunta qué quieres, espera a que apruebes el diseño, luego escribe el plan y hace el trabajo paso a paso:

Lo que mantiene el flujo en pie es using-superpowers, la primera tarjeta. Según el README, en Claude Code, Codex, Cursor y Gemini la carga el hook SessionStart del plugin. En Claude Code el hook se ejecuta al abrir una sesión, después de /clear y cuando se compacta el contexto; qué se pierde con la compactación lo explicamos en el artículo sobre auto-compact. El texto de la skill también le habla claro al agente: «If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.» En palabras del README, son «Mandatory workflows, not suggestions.»

La mayoría de los pasos son hábitos que, en el artículo sobre vibe coding, encontramos en común en las guías de las herramientas: primero un plan para un trabajo grande, tests que el agente pueda ejecutar, un worktree aparte para cada tarea, leer el cambio. Superpowers no los deja como consejos: los convierte en skills y hace que el agente los aplique. Nosotros también usamos obra/superpowers en nuestras sesiones mientras desarrollamos diffox, nuestra herramienta de revisión de código con IA. En un proyecto, la skill brainstorming no deja escribir código hasta que se aprueba un documento de diseño; guarda el documento en docs/superpowers/specs/, y la skill writing-plans escribe el plan en docs/superpowers/plans/. En nuestro repositorio también están en esas dos carpetas los documentos de diseño y los planes que superpowers hizo escribir.

El README explica la instalación en 16 apartados; la app y la CLI de Codex tienen uno cada una. De los agentes de este artículo, Amp y Goose no están en la lista; Devin CLI, Factory Droid, Grok Build CLI, Kimi Code, Qwen Code, Hermes Agent y Muse sí. El README te pide instalarlo por separado en cada herramienta: «If you use more than one, install Superpowers separately for each one.» Los comandos para los agentes de este artículo:

Fuente: el README de obra/superpowers, 21 de octubre de 2026. Superpowers aparece en el marketplace de Cursor con la etiqueta «Verified by Cursor», y también en el directorio de plugins de OpenAI (openai/plugins).

La carga al inicio de cada sesión no llega por el mismo camino en todas las herramientas. Según las notas de versión de Superpowers, Antigravity no tiene un hook que se ejecute al iniciar la sesión; según el README, la descripción de using-superpowers hace que el modelo la cargue al principio de la conversación. Las notas de versión dicen que lo comprobaron en 12 ejecuciones con agy 1.3.1; es una medición del propio proyecto. En Pi, una pequeña extensión añade el mismo texto al inicio de la sesión y después de la compactación. Hermes Agent no tiene un hook que se ejecute tras la compactación, así que una sesión muy larga puede perder esta carga. using-superpowers incluye archivos de referencia separados para Claude Code, Codex, Pi, Antigravity, Hermes Agent y Muse.

Ten cuidado con dos cosas. La primera es el nombre: como contamos arriba, en skills.sh hay repositorios llamados superpowers que no tienen nada que ver con obra/superpowers; escribe el nombre completo del repositorio. La segunda es un poco de telemetría: el asistente visual opcional de brainstorming carga el logo de Prime Radiant desde la web del proyecto, y en esa petición va la versión de Superpowers. El README dice que no se envía nada sobre tu proyecto, tu prompt ni tu agente. Para desactivarla existe la variable de entorno SUPERPOWERS_DISABLE_TELEMETRY; también respeta los ajustes DISABLE_TELEMETRY y CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC de Claude Code.

¿Qué skills ayudan mientras escribes código?

La mayoría de los paquetes se centran en una sola tarea. Hemos puesto juntas las skills que hacen lo mismo; los números entre paréntesis son las instalaciones que skills.sh muestra por skill (21 de octubre de 2026). Lo que decide cuál te conviene no es el número, sino lo que la skill hace hacer al agente; lee su SKILL.md antes de instalarla.

Tests. La skill test-driven-development de obra/superpowers (256,4 mil) resume su regla en una línea, «NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST», y hace borrar el código escrito antes del test. La skill tdd de mattpocock/skills (1,1 M) aplica el mismo ciclo rojo-verde-refactor dividiendo el trabajo en cortes verticales. Para probar la interfaz, webapp-testing de anthropics/skills (183,6 mil) prueba una aplicación web local con Playwright, mientras que vercel-labs/agent-browser (1,2 M) es una CLI que permite al agente usar el navegador. Cuándo debe el agente probar la interfaz por sí mismo y cuándo escribir un test permanente lo explicamos en el artículo sobre computer use y Playwright.

Depuración. systematic-debugging de superpowers (302,3 mil) prohíbe proponer un arreglo antes de encontrar la causa raíz y divide el trabajo en cuatro fases. diagnosing-bugs de mattpocock (819,4 mil) primero hace montar un bucle de feedback que reproduce el error y se pone en rojo; luego vienen la reducción, la hipótesis, la medición, el arreglo y el test de regresión. verification-before-completion de superpowers (247,9 mil) pide al agente que ejecute el comando de verificación y muestre su salida antes de decir «arreglado» o «pasa».

Interfaz. frontend-design de anthropics/skills (1,0 M) orienta la dirección visual, la tipografía y las decisiones de diseño para que la interfaz no parezca una plantilla. vercel-react-best-practices de Vercel (824,7 mil) da reglas de rendimiento para React y Next.js ordenadas por impacto; web-design-guidelines (766,1 mil) audita el código de la interfaz según reglas de accesibilidad, rendimiento y experiencia de usuario. Para un lenguaje de diseño están taste-skill (650,4 mil), ui-ux-pro-max (407,2 mil) e impeccable (349,3 mil).

Bibliotecas. Algunas empresas publican skills para sus propios productos. supabase-postgres-best-practices de Supabase (454,1 mil) está escrita para cargarse antes de escribir o cambiar algo en una base de datos Postgres; prisma-client-api de Prisma (378,2 mil) explica la API de Prisma Client para escribir consultas y filtros. Si el creador de una biblioteca que usas publica una skill, mira esa primero.

Documentos. Las skills pptx (239,8 mil), pdf (214,4 mil), docx (204,7 mil) y xlsx (185,7 mil) de anthropics/skills son las que están detrás de la función de creación de documentos de Claude. El README las describe como «source-available, not open source»: el código fuente se puede leer, pero no tiene licencia de código abierto, y el archivo de licencia dice «All rights reserved». Léelas como ejemplos y revisa la licencia antes de copiar una en tu propio paquete.

Skills que buscan y escriben skills. find-skills de vercel-labs/skills (4,0 M) busca e instala otras skills cuando preguntas «¿hay alguna skill que haga esto?». skill-creator de anthropics/skills (411,5 mil) hace escribir una skill nueva, mejora una existente y mide con qué precisión se activa; writing-skills de superpowers (215,2 mil) hace lo mismo con su propio método de pruebas. Codex trae Skill Creator integrado, y Gemini CLI añadió un skill-creator en la versión 0.26.0. Cómo escribir tu propia skill lo explicamos en nuestro artículo sobre qué es una skill.

¿Es seguro instalar la skill de otra persona?

Qué revisar antes de instalar lo listamos en nuestro artículo sobre qué es una skill, el riesgo de los servidores MCP lo explicamos en el artículo sobre seguridad MCP, y los archivos de un repositorio que pueden ejecutarse por su cuenta, en el artículo sobre workspace trust. Aquí va lo que hemos leído desde entonces.

Un plugin ejecuta código. La página de seguridad de plugins de Claude Code lo dice claro: «A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges.» Los hooks y los servidores MCP de un plugin se ejecutan con tus permisos. Las reglas de permisos y el sandbox de Claude Code cubren las llamadas a herramientas que hace Claude, no el código que el plugin ejecuta por su cuenta. Superpowers también entra en Claude Code como plugin y ejecuta un hook al principio de cada sesión. La documentación de Codex te pide revisar y aprobar los hooks de un plugin antes de que se ejecuten.

La versión que leíste puede cambiar. Si la actualización automática está activada en el marketplace del que viene un plugin, Claude Code lo actualiza en segundo plano; la documentación escribe la consecuencia: «the files you reviewed can change on disk.» La actualización automática está activada por defecto en claude-plugins-official y en la mayoría de los marketplaces oficiales, y desactivada en los de la comunidad y de terceros. El catálogo de la comunidad, por su parte, fija casi todos los plugins a un commit; Claude Code no instala otro commit que ese. El README de mattpocock/skills cuenta la diferencia en una frase: «A plugin updates itself.» npx skills, en cambio, copia los archivos en tu proyecto, y los actualizas tú.

Una copia no se arregla sola. Skill Constellations mide el riesgo en la otra dirección: «Skill copies almost never change with their source, and a fix at the source therefore rarely reaches them.» Por eso el estudio recomienda distribuir referencias con versión en lugar de copias. Al elegir cómo instalar, la verdadera pregunta es cómo cambia la skill después:

La herramienta de instalación cuya documentación explica claramente cómo fijar la versión es GitHub CLI: gh skill install … --pin fija la skill a una etiqueta o a un commit, y una skill fijada se salta al actualizar. Pero fijarla también convierte la actualización en tarea tuya. Las notas de Superpowers 7.0.0 dicen que se cerró un fallo por el que, en Windows, un repositorio podía dejar un archivo que se ejecutaba al iniciar la sesión; una instalación que se queda en una versión antigua no recibe esta corrección. Fija la versión, lee las notas de versión y actualiza tú.

Los análisis de seguridad no coinciden. skills.sh, según su anuncio del 17 de febrero de 2026, analiza las skills con Gen, Socket y Snyk y quita de la lista y de la búsqueda las que considera maliciosas; su documentación también dice que no puede garantizar la calidad y la seguridad de cada skill. Hay motivos para no fiarse solo del veredicto de un escáner. En el estudio After the Party, sobre el mercado de skills de OpenClaw, tres escáneres revisaron las mismas 61.990 skills y dieron veredictos distintos en 23.702 de ellas. Desde el lado contrario, Context Matters encontró que los informes de análisis de los mercados marcaban como maliciosas hasta el 46,8 % de las skills, pero solo el 0,52 % seguía siendo sospechoso cuando cada skill se examinaba junto con su propio repositorio. Así que ni una insignia de «aprobado» ni un aviso de «malicioso» bastan por sí solos.

Skills limpias por separado pueden ser peligrosas juntas. CompoSkill y Runaway Reaction muestran que skills que pasan el análisis una a una pueden producir un comportamiento dañino cuando se usan juntas. SkillBloat estudia otro ataque contra los agentes de programación: una skill maliciosa puede hacer que el agente gaste muchos más tokens de los que necesita la tarea; el daño aparece en la factura. Todos los estudios de esta sección son preprints en arXiv sin revisión por pares.

La documentación de skills de los agentes también avisa en distinta medida:

• OpenCode te deja poner cada skill, o un patrón, en allow, ask o deny con permission.skill en opencode.json; con ask, te pregunta antes de cargar la skill.
• Pi te pide leer las skills que no conoces y los archivos que las acompañan antes de confiar en un proyecto.
• La documentación de VS Code de Copilot dice que revises siempre las skills compartidas antes de usarlas.
• El marketplace de Cursor revisa a mano cada plugin antes de listarlo.
• Las páginas de skills de Antigravity y Goose no dan ninguna regla de seguridad: su documentación no lo dice.

¿Con qué skill empezar?

Empieza por tu trabajo, no por una lista. Lo que te recomendamos:

• Primero, encuentra la necesidad. Si el agente comete siempre el mismo error (código sin tests, un parche que no llega a la causa raíz, una interfaz con cara de plantilla), busca una skill para esa tarea. Para cambiar todo el flujo, un paquete como obra/superpowers; para arreglar una sola tarea, basta con una skill.
• Elige un paquete mantenido y con una licencia clara. ¿El README dice qué agentes soporta y cuál es su licencia, y cuándo cambió por última vez? Si el creador de una biblioteca que usas publica una skill, mira esa.
• Lee antes de instalar. Lee el SKILL.md y los scripts que lo acompañan; si es un plugin, mira también sus hooks y servidores MCP. En Claude Code, /plugin install no instala el plugin enseguida: primero abre el panel de detalles, que muestra los comandos, skills, hooks y servidores MCP que añadirá el plugin.
• Fija la versión y actualiza tú. gh skill install … --pin o un commit; si es un plugin, ten claro si la actualización automática está activada o no.
• No instales el mismo paquete por dos vías. El README de mattpocock/skills avisa: si lo instalas como plugin y además con npx skills, cada skill llega dos veces.
• Si miras un número, lee también su contador. ¿Qué contador, qué cuenta, cuándo se leyó? No pongas lado a lado números de contadores distintos para compararlos.

Preguntas frecuentes

¿Qué son las agent skills?

Una skill es una carpeta con un archivo SKILL.md: arriba van el nombre y la descripción de la skill, y debajo las instrucciones que le dicen al agente cómo hacer una tarea. Al principio de la sesión el agente solo lee el nombre y la descripción; cuando una tarea encaja con la descripción, carga las instrucciones completas. Cómo se escribe y en qué carpeta va lo explicamos en nuestro artículo sobre qué es una skill.

¿Cómo se añade una skill a Claude Code?

Tu propia skill la pones en .claude/skills/<nombre>/SKILL.md en el proyecto, o en ~/.claude/skills para ti. Las skills de otros suelen llegar en plugins: /plugin install <plugin>@<marketplace> primero muestra los detalles del plugin y lo instala cuando eliges un alcance. El marketplace oficial de Anthropic (claude-plugins-official) se añade solo en la primera sesión interactiva; para otro marketplace primero hace falta /plugin marketplace add. Recuerda que un plugin también puede ejecutar hooks y servidores MCP.

¿Cómo se instala una skill en Codex?

Para instalar una skill del catálogo de Codex, escribe $skill-installer <nombre>; Codex detecta la skill nueva por sí solo, y si no aparece, reinicia Codex. Los plugins se instalan con /plugins en la CLI y desde la pestaña Plugins en la app; la documentación de Codex recomienda los plugins para distribuir skills. Las skills que añades a mano están en .agents/skills en el proyecto y en $HOME/.agents/skills para ti. El catálogo antiguo, openai/skills, está obsoleto; los ejemplos actuales están en openai/plugins.

¿De qué carpetas lee OpenCode las skills?

En el proyecto lee .opencode/skills, .claude/skills y .agents/skills en cada nivel, desde la carpeta en la que estás hasta la raíz del worktree de git. Para las skills personales mira en ~/.config/opencode/skills, ~/.claude/skills y ~/.agents/skills. El agente carga una skill con la herramienta integrada skill; con permission.skill en opencode.json puedes permitir cada skill, hacer que pregunte antes o desactivarla. Su documentación no menciona ningún comando de instalación ni marketplace.

¿Siguen funcionando las skills de Gemini CLI?

Sí, pero no para todos. El 18 de junio de 2026, Google cerró Gemini CLI a los usuarios gratuitos y a los suscriptores de Google AI Pro y Ultra, y lo sustituyó por Antigravity CLI. Gemini CLI sigue para quienes lo usan con una licencia de empresa o una clave de API de pago; la última versión en las notas de versión es la 0.64.0 (13 de octubre de 2026). Según Google, Antigravity CLI mantiene las skills. Si pones tus skills en .agents/skills, las leen los dos; en Gemini CLI esa carpeta va antes que .gemini/skills.

¿Qué es skills.sh y qué cuentan sus instalaciones?

skills.sh es el directorio de skills de Vercel y la web de la CLI npx skills. Su ranking se basa en telemetría anónima recogida por la CLI: cuenta las instalaciones hechas con npx skills add, por skill. Las instalaciones desde un marketplace de plugins, con git clone o con gh skill no entran en ese número. El total de un repositorio es la suma de sus skills; no dice cuántas personas lo instalaron. DISABLE_TELEMETRY=1 o DO_NOT_TRACK=1 desactiva la telemetría.

¿Funciona Superpowers en Codex, OpenCode o Cursor?

El README de obra/superpowers explica la instalación en los tres. En Codex está en el directorio de plugins de OpenAI: lo buscas con /plugins en la CLI y lo instalas. En Cursor se instala con /add-plugin superpowers o desde el marketplace, donde aparece con la etiqueta «Verified by Cursor». En OpenCode le pides al agente que lea y siga .opencode/INSTALL.md del repositorio; el README pide instalar Superpowers en OpenCode por separado aunque ya lo uses en otra herramienta. Como hay otros repositorios con el mismo nombre, escribe el nombre completo del repositorio: obra/superpowers.