claude-red con 8.489 estrellas: su propio CONTRIBUTING.md dice que los skills sin frontmatter no cargan, y 28 de 79 no lo tienen mientras concentran el 77% de los bytes

SnailSploit/Claude-Red se presenta como “una biblioteca curada de skills de seguridad ofensiva para el sistema de skills de Claude”, y 8.489 personas le han dado estrella. Su CONTRIBUTING.md enuncia la regla de formato de la que depende toda la biblioteca, con palabras muy claras:

“El frontmatter YAML es obligatorio. Los skills sin él no cargan en el sistema de skills de Claude.”

Veintiocho de los 79 archivos SKILL.md del repositorio no tienen frontmatter YAML. No empiezan por ---: empiezan por # SKILL: seguido de un bloque markdown ## Metadata. Esos 28 archivos suman 2.753.891 de los 3.565.194 bytes de texto de skills del repositorio, el 77,2%. Los cinco archivos más grandes de la biblioteca están todos en ese conjunto, incluido uno de 567.484 bytes y 15.151 líneas.

Ese solo número es el artículo: una biblioteca en la que la mayoría del contenido vive en archivos que su propia guía de contribución declara no cargables, y en la que el recuento de marketing (78, en la insignia) no coincide con el disco (79) ni con el manifiesto generado (78 entradas, 28 de ellas con la descripción vacía).

Hay un segundo número que importa igual. SECURITY.md afirma: “Este repositorio está firmado por SnailSploit. Verifique las firmas de los commits con: git log --show-signature”. Lo ejecuté. Los 45 commits devuelven N: sin firmar. Cero.

Todo lo siguiente se midió el 24 de octubre de 2026 sobre un git clone completo de main (HEAD a8de813, del 2026-10-12), la API REST de GitHub y las herramientas del propio repositorio ejecutadas localmente. No instalé nada en ningún entorno de Claude, ningún modelo llegó a cargar un skill y no se ejecutó ninguna técnica ofensiva de la biblioteca. Los recuentos salen de analizar archivos con Python, así que cada cifra es reproducible con git clone y un script. Cuando cito la documentación de Anthropic, la cita es de las páginas en vivo y la frase está reproducida tal cual.

Lo que la plataforma exige de verdad

Antes de entrar en los hallazgos conviene fijar la mecánica, porque “skill” no es sinónimo de “archivo markdown con un título bonito”. La documentación de Agent Skills de Anthropic enumera los campos obligatorios:

Campos obligatorios: name y description name: máximo 64 caracteres · solo minúsculas, números y guiones · sin etiquetas XML · sin las palabras reservadas “anthropic” ni “claude” description: no puede estar vacío · máximo 1.024 caracteres · sin etiquetas XML “La description debe incluir tanto qué hace el skill como cuándo debe usarlo Claude.”

Y describe tres niveles de carga, que es justo de lo que depende cualquier discurso de “los skills no cuestan nada hasta que los usas”:

Dos comportamientos más son decisivos aquí. Primero, la guía de autoría es explícita: “Mantén SKILL.md por debajo de 500 líneas. Mueve el material de referencia detallado a archivos separados.” Segundo, sobre persistencia: “cuando tú o Claude invocáis un skill, el contenido renderizado de SKILL.md entra en la conversación como un único mensaje y permanece ahí en los turnos siguientes”, y tras la compactación automática “Claude Code vuelve a adjuntar la invocación más reciente de cada skill después del resumen, conservando los primeros 5.000 tokens de cada uno. Los skills re-adjuntados comparten un presupuesto combinado de 25.000 tokens”.

Es decir: los metadatos son baratos, el cuerpo no lo es, y su coste se paga en cada turno posterior de la sesión.

Ahora los números del repositorio.

78, 79 y 28

El README lleva una insignia skills-78 y categories-23. La tabla de categorías suma 78. claude-skills.json, generado por el propio tools/build_manifest.py del repositorio, declara "skill_count": 78. El sistema de archivos tiene 79 archivos SKILL.md repartidos en 23 categorías.

El que falta es Skills/active-directory/offensive-netexec/SKILL.md, creado el 2026-09-14; el manifiesto se regeneró por última vez el 2026-08-26 y nunca más. La fila de Active Directory en el README dice 1 skill; el directorio tiene 2. Si vuelves a ejecutar python3 tools/build_manifest.py imprime “Wrote … with 79 skills across 23 categories”: la herramienta funciona, simplemente nadie la lanzó después de añadir el último skill. Es un detalle pequeño, pero dice mucho: el manifiesto no forma parte de ningún proceso de publicación, es un archivo que se regenera a mano cuando alguien se acuerda.

Y luego está la división importante:

Reparto de esos 28 por categoría:

La categoría ai está 1/1: el único skill de seguridad de IA de una biblioteca de seguridad de IA no tiene metadatos. Web, la categoría más grande (16 skills) y la que el README usa como escaparate, está 11 de 16 sin frontmatter. Wireless es la más sana: 14 de 14 completos.

Ese 77% no es solo más grande, es contenido distinto

Sería fácil suponer que los 28 archivos son los antiguos o los de menos esfuerzo. Es lo contrario: son los más grandes del repositorio.

Las conversiones de bytes a tokens son estimaciones a cuatro bytes por token (la misma convención que usan las heurísticas de tamaño de GitHub) y son lo bastante grandes como para que el margen de error no cambie la conclusión: un solo skill de 567 KB son unos 142.000 tokens. La guía de Anthropic para el nivel 2 habla de “menos de 5k tokens”, y todo el presupuesto de re-adjunción tras compactar para todos los skills de una sesión son 25.000 tokens. Un archivo de esta biblioteca equivale a 5,7 veces ese presupuesto combinado antes de compactar y a 28 veces la porción de 5.000 tokens por skill después.

En conjunto:

Aquí es donde la frase del README merece revisión: “Los skills cargan bajo demanda según disparadores conversacionales: no pagas contexto por los skills que no usas”. La primera mitad es correcta y es lo que promete la plataforma. La segunda solo es cierta en el nivel 1. Cuando uno de estos archivos se activa, el cuerpo entero entra en la conversación como un único mensaje y se queda ahí: en los cuatro más grandes, eso son entre 88.000 y 142.000 tokens en un turno, sobre un modelo cuya ventana de contexto es una fracción del agregado de la biblioteca. Nada en el repositorio parte esos cuerpos en archivos de referencia de nivel 3, que es exactamente el patrón que recomienda la guía de autoría.

Hay una consecuencia perversa que conviene nombrar sin rodeos: los archivos sin frontmatter son justo los que Claude Code sí va a intentar cargar. Según la documentación de Claude Code, “todos los campos son opcionales. Solo se recomienda description… Si falta, se usa la primera línea no vacía del contenido markdown”, y “Claude Code lee el frontmatter solo cuando el --- de apertura es la primera línea del archivo. En caso contrario trata el archivo entero, marcadores --- incluidos, como contenido del skill”.

Así que por la vía de Claude Code —la que recomienda el README, git clone … ~/.claude/skills/claude-red— esos 28 skills sí cargan, con una descripción derivada de su H1:

• # SKILL: Week 5: Basic Exploitation (Linux with Mitigations Disabled)
• # SKILL: Week 4: Crash Analysis and Exploitability Assessment
• # SKILL: OSINT Methodology

Un encabezado de semana de curso se convierte en la descripción del disparador. Eso no describe qué hace el skill ni cuándo usarlo: es una etiqueta de temario. Y va pegada a un cuerpo de 354 KB. Por la vía de subida a la API o a claude.ai, donde name y description son campos obligatorios, esos mismos 28 son directamente inválidos. Las dos lecturas de la frase del repositorio —“no cargan”— son defendibles; lo incómodo es que “cargan mal, con un título de temario y 142.000 tokens detrás” es el resultado más probable para la mayoría de usuarios.

Incluso entre los 51 archivos que sí tienen frontmatter, 18 descripciones superan el máximo de 1.024 caracteres de la plataforma (la más larga: 1.525 caracteres, privesc/offensive-windows-privesc). En Claude Code la descripción combinada se trunca a 1.536 caracteres en el listado de skills, así que esas 18 sobreviven ahí con 11 caracteres de margen; en cualquier sitio donde se aplique la regla de campos obligatorios, fallan la validación. La higiene de nombres, al menos, está limpia: en los 51, name coincide con el nombre del directorio y ninguno pasa de 64 caracteres.

De dónde salen esos 28 archivos

Los archivos sin frontmatter comparten un estilo propio que no es el del resto de la biblioteca:

# SKILL: Week 5: Basic Exploitation (Linux with Mitigations Disabled)

## Metadata
- **Skill Name**: basic-exploitation
- **Folder**: offensive-basic-exploitation
- **Source**: https://github.com/SnailSploit/offensive-checklist/blob/main/5-basic-exploitation.md

## Description

Son otro artefacto: material de curso de formato largo, un archivo por semana o por tema, copiado del repositorio offensive-checklist del propio autor, con la URL de origen conservada en una línea **Source**. El pipeline previsto para convertir esto en skills es convert_skills.py, que analiza exactamente esa estructura ## Metadata / # SKILL: y emite frontmatter YAML. Nunca se ha ejecutado sobre estos 28 archivos; o, si se ejecutó, la salida no se commiteó.

Ese conversor merece una lectura, porque explica buena parte del estado del repositorio:

• INPUT_DIR = Path("skills") — en minúsculas. El directorio del repositorio es Skills/. En un sistema de archivos insensible a mayúsculas (macOS, la plataforma del autor a juzgar por el .DS_Store del primer commit) funciona. En Linux no. Lo ejecuté: ❌ Carpeta no encontrada: …/Claude-Red/skills.
• Cuando falla, imprime ese error y sale con código 0. No hay ninguna ruta de salida distinta de cero en main(): el fallo es invisible para cualquier script que compruebe $?.
• Sus valores de reserva son cadenas en español: meta['description'] = 'Sin descripción disponible.' y meta['body'] = '# Instructions for Claude\n[Contenido no parseado]'. Si el parser no encuentra ni la sección de descripción ni el cuerpo, el skill generado se publica con la descripción literal “Sin descripción disponible.”, que es el tipo de cosa que descubres en el momento del disparo, no en el build.

Cinco de los archivos sin frontmatter llevan además un comentario de procedencia que no aparece en ninguna parte de la documentación del repositorio:

<!-- Written by AnotherOne from @Pwn3rzs Telegram channel -->

Los cinco: exploit-dev/offensive-basic-exploitation, exploit-dev/offensive-crash-analysis, infrastructure/offensive-windows-mitigations, fuzzing/offensive-fuzzing-course y fuzzing/offensive-vuln-classes. Juntos, 1,44 MB del repositorio. La sección de agradecimientos del README acredita “Original Checklists: Sahar Shlichov — la colección de checklists ofensivos sobre la que se construyen muchos de estos skills”, y ese crédito es real y concreto. Ni “AnotherOne” ni “Pwn3rzs” aparecen en README.md, CONTRIBUTING.md ni CHANGELOG.md. Bajo licencia MIT esto es legalmente cómodo y periodísticamente relevante: el bloque de contenido más grande de la biblioteca está atribuido dentro de un comentario HTML, invisible en el markdown renderizado, a un canal de Telegram.

La afirmación sobre firmas, comprobada

SECURITY.md tiene una sección titulada Integridad de la cadena de suministro. Su primera frase es una afirmación fáctica sobre este repositorio: “Este repositorio está firmado por SnailSploit”. La segunda es una instrucción: “Verifique las firmas de los commits con: git log --show-signature”.

$ git log --pretty='%G?' 2>/dev/null | sort | uniq -c
     45 N

Todos los commits devuelven N: no hay firma. No existe cabecera gpgsig en ningún objeto commit. La instrucción no es un consejo: es el control de cadena de suministro que el repositorio ofrece, y verifica contra nada. Quien la siga verá 45 commits sin firma, lo cual es al menos una señal clara; quien confíe en la frase seguirá creyendo en una cadena de firmas que no existe.

Los autores de los commits también merecen una tabla, porque matizan la palabra “curada”:

Trece de 45 commits los firma Claude, con Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> y, en algunos casos, un trailer Claude-Session: que apunta a una URL de sesión. Es el 29% del historial: el modelo es el segundo committer más activo de una biblioteca cuyo producto son instrucciones para un modelo. No es un escándalo —un flujo asistido por agente es normal en 2026 y los commits son legibles en el log—, pero significa que “curada” describe un resultado, no un proceso de revisión humana documentado. El proceso de revisión de CONTRIBUTING.md está descrito en prosa; no hay ninguna comprobación de CI que lo haga cumplir, como demuestra el recuento de frontmatter.

Ritmo de commits por mes: marzo 5, abril 4, mayo 13, junio 0, julio 0, agosto 14, septiembre 8, octubre 1. Dos meses de silencio en mitad del año y después la ráfaga que coincide con la aparición del repositorio en las listas de tendencias.

Y el commit inicial explica un patrón que corroboran la línea de copyright y el changelog. 86d1449, del 2026-03-04, contiene 43 archivos y 83.322 líneas insertadas, incluidos 38 archivos SKILL.md. El LICENSE dice “Copyright (c) 2024-2025 SnailSploit / Kai Aizen”; las entradas del CHANGELOG están fechadas “0.2.0 — 2025-05” y “0.3.0 — 2025-08”, ambas anteriores a que el repositorio existiera en GitHub. Esto no es un proyecto que creció en GitHub: son casi dos años de checklists y material de curso privados publicados en un solo push y después ampliados por fases. Es una forma legítima de liberar trabajo, y también predice la forma de mantenimiento que debes esperar: dos etiquetas en total (Snail, v0.3.0), ninguna obligación de roadmap y un manifiesto que se desvía porque el acontecimiento fue publicar el archivo, no empezar un proyecto.

El manifiesto cuenta lo que ven los programas

claude-skills.json es el índice legible por máquina. Lo genera tools/build_manifest.py, que analiza el frontmatter y recurre al nombre del directorio cuando no obtiene nada:

entry = {
    "name": fm.get("name", skill_dir.name),
    "category": category,
    "path": str(skill_md.relative_to(ROOT)),
    "description": fm.get("description", ""),
}

Ese valor de reserva es toda la historia. En el manifiesto commiteado, 28 de 78 entradas tienen "description": "", exactamente los 28 archivos sin frontmatter:

{
  "name": "offensive-windows-boundaries",
  "category": "infrastructure",
  "path": "Skills/infrastructure/offensive-windows-boundaries/SKILL.md",
  "description": ""
}

Un skill de 567 KB, indexado por las propias herramientas del proyecto, con la descripción vacía. Cualquiera que construya sobre este manifiesto —un enrutador, un registro, una página de índice, un arnés de evaluación— obtiene un nombre, una ruta y nada contra lo que emparejar. Longitudes de las 50 descripciones no vacías: mínimo 322 caracteres, mediana 825, máximo 1.525.

Lo que sí está bien hecho

Una auditoría que solo enumera defectos no es una auditoría, es una acusación. Así que, medido con el mismo método:

Esa última fila merece énfasis porque es la comprobación que invita el propio SECURITY.md (“una ruta de instalación propensa a typosquatting o un comando de shell inseguro en install.sh”): el instalador es una copia simple. Es trabajo honesto. Lo ejecuté en un directorio temporal y respondió “Installed 79 skill(s)” y luego “Claude should now auto-discover them on next session start”, que es donde termina la honestidad, porque 28 de esos 79 no tienen metadatos de descubrimiento y una categoría entera (ai) no tiene ninguno.

Patrones peligrosos en los cuerpos, por completitud y con la advertencia de que en una biblioteca de seguridad ofensiva son el producto, no el defecto: construcciones de reverse shell en 5 de 79 skills, fragmentos de instalación curl … | sh en 7, un pipeline de decodificación base64 en 1 (web/offensive-rce) y literales IPv4 en 36 archivos (359 apariciones, en su mayoría direcciones de laboratorio RFC1918 y objetivos de ejemplo). Bloques de código: 2.531 aperturas de bloque, de las cuales 226 (8,9%) no llevan etiqueta de lenguaje, contra la regla 5 del propio CONTRIBUTING.md.

La distribución del lenguaje de seguridad es la única asimetría que plantearía al mantenedor. SECURITY.md limita la biblioteca a “pruebas de penetración autorizadas con alcance y reglas de enfrentamiento documentadas”, “programas de bug bounty con permiso escrito explícito” y similares. Dentro de los archivos, 18 de 79 no contienen ninguna mención a autorización, alcance, legalidad o consentimiento, entre ellos web/offensive-xss, web/offensive-waf-bypass, wireless/offensive-evil-twin e infrastructure/offensive-shellcode. Un decimonoveno (wireless/offensive-bluetooth-classic) menciona el alcance solo en la descripción de su frontmatter, que el modelo lee al descubrir el skill pero no arrastra como instrucción. Exactamente 1 contiene una cláusula explícita de “permiso escrito” (forensics/offensive-anti-forensics). Cuando un skill se pega en el system prompt de un proyecto, SECURITY.md no viaja con él: el archivo es el conjunto de instrucciones completo, y la política vive un nivel más arriba, en un documento que el modelo nunca lee.

El proveedor dentro del CI, y la nota que medía el análisis sintáctico

Dos workflows vienen de un proveedor externo: skill-preview.yml ejecuta tesslio/skill-review-and-optimize en cada PR que toque un SKILL.md con optimize: true y un secreto TESSL_API_TOKEN, y skill-optimize-apply.yml ejecuta la misma acción en mode: apply cuando alguien comenta en un PR.

La condición del segundo es esta, literal:

on:
  issue_comment:
    types: [created]
jobs:
  apply:
    if: >
      github.event.issue.pull_request &&
      contains(github.event.comment.body, '/apply-optimize')
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: write

Comprueba que el comentario esté en un pull request y que el cuerpo contenga la cadena /apply-optimize. No comprueba github.event.comment.author_association y no hay lista blanca de github.actor. Los comentarios en repositorios públicos están abiertos a cualquier cuenta de GitHub. No lo probé —activar una acción externa con contents: write en un repositorio que no es mío sería exactamente el comportamiento que prohíbe su SECURITY.md—, pero la condición es legible y su forma es “cualquiera que pueda comentar puede invocar la acción del proveedor con permiso de escritura”. Si la acción en sí es segura es una pregunta sobre la acción, cuyo SHA fijado (90e919d50ecb…) es al menos una buena práctica.

Los empleados del mismo proveedor aparecen en el log. El commit 4e21414 de abril de 2026, de Yogesh Rao, se titula “feat: improve skill scores for Claude-Red” y contiene el documento de diagnóstico más útil del repositorio. Su cuerpo:

“Pasé tus skills por tessl skill review en el trabajo y encontré mejoras concretas.”

Skill	Antes	Después	Cambio
offensive-fuzzing	5%	97%	+92%
offensive-sqli	5%	86%	+81%
offensive-shellcode	5%	83%	+78%
offensive-jwt	10%	86%	+76%
offensive-osint	10%	65%	+55%

“Los cinco skills puntuaban 5-10% porque les faltaba el frontmatter YAML: la herramienta de revisión no podía ni ejecutar el juez LLM. El cambio principal en todos fue añadir el frontmatter --- correcto con name en kebab-case y una description entrecomillada con términos de activación y una cláusula ‘Use when…’.”

Léelo despacio. Un 5% no era un juicio sobre la calidad del contenido: era la herramienta diciendo que no podía evaluar el archivo. El titular del “+92%” es una corrección de analizabilidad sintáctica. Es un dato muy útil sobre las herramientas de puntuación de skills en general, y lo dice sin rodeos quien la ejecutó, en el cuerpo de un mensaje de commit y no en el README.

También significa que la corrección existía, dentro del repo, hace seis meses, para cinco archivos. Cuatro siguen con su frontmatter. Uno no: recon/offensive-osint-methodology tenía --- / name: offensive-osint el 2026-04-15 y hoy empieza por # SKILL: OSINT Methodology, porque el commit de mayo de 2026 “Reorganize skills into 13 categories” (70e0c89) reemplazó el cuerpo del archivo entero y se llevó por delante la cabecera. Una reorganización masiva revirtió en silencio la mejora de un proveedor sobre un skill, y nada en el CI se entera, porque nada en el CI valida frontmatter: la acción del proveedor solo corre en PRs.

Qué dice el roadmap y qué hacer con él

La tabla de roadmap lista nueve fases: tres Complete, cinco Planned (+16 división AD/Windows, +10 identidad cloud, +10 IoT, +8 fundamentos web, +10 web avanzado), una Complete para “Documentation and tooling polish” y un objetivo de “~130 skills en 23+ categorías”. Hoy hay 79. Es decir, el número del escaparate tiene 51 skills de crecimiento planificado por delante, mientras 28 de los 79 actuales están en un formato que la propia guía del repositorio dice que no carga y el conversor que los arreglaría no puede ejecutarse en Linux.

Si estás evaluando esta biblioteca para trabajo autorizado, estas son las comprobaciones, cada una con su señal de paso o fallo. Todas son baratas y ninguna requiere instalar nada en un entorno de Claude:

Resultados previstos en el main de hoy: comprobación 1 → 28, comprobación 2 → 45 sin firmar, comprobación 3 → una entrada nueva (offensive-netexec), comprobación 4 → 43 archivos por encima de 20 KB, comprobación 5 → 18 archivos sin coincidencias. Ejecuté las cinco; esas son las salidas.

Lo que ninguna de estas comprobaciones puede decirte —y lo que el repositorio no puede decirte en absoluto— es si el contenido es bueno. Si la cobertura de ADCS ESC1-ESC15 es correcta, si los arneses de fuzzing compilan, si los apuntes de shellcode reflejan las mitigaciones actuales: eso requiere a una persona con criterio experto leyendo 3,5 MB de markdown, y ningún recuento de estrellas ni insignia de puntuación lo sustituye. La documentación es tajante sobre lo que está en juego: “Usa skills solo de fuentes de confianza: los que hayas creado tú o los obtenidos de Anthropic… un skill malicioso puede dirigir a Claude a llamar herramientas o ejecutar código de formas que no coinciden con el propósito declarado del skill”. Para una biblioteca de este tamaño, de un editor con dos releases, 45 commits y una política de seguridad cuya única afirmación verificable verifica contra nada, “auditar a fondo” no es una formalidad.

Preguntas frecuentes

¿Un SKILL.md sin frontmatter no carga? Depende de la superficie, y el CONTRIBUTING.md del repositorio exagera en una dirección y subestima el peligro en la otra. En Claude Code el archivo sí carga: la documentación dice que description se recomienda, no se exige, y que “si falta, se usa la primera línea no vacía del contenido markdown”. Así que la descripción del disparador pasa a ser # SKILL: Week 5: Basic Exploitation (Linux with Mitigations Disabled). En la especificación de Agent Skills, name y description son campos obligatorios, así que el mismo archivo no valida. En ambos casos pierdes aquello para lo que existe el frontmatter: una descripción que diga qué hace el skill y cuándo usarlo.

¿567 KB en un solo SKILL.md es realmente un problema? Sí, y es mecánico, no estilístico. El cuerpo entra en la conversación como un único mensaje al activarse el skill y permanece el resto de la sesión; la guía de autoría dice “menos de 5k tokens” y “por debajo de 500 líneas”; el presupuesto de re-adjunción tras compactar es de 5.000 tokens por skill y 25.000 combinados. Un cuerpo de 567 KB son unos 142.000 tokens, 28 veces la porción por skill, y su marco de seguridad, si existe, está donde lo puso el autor, posiblemente más allá del punto donde la compactación corta.

¿La biblioteca es maliciosa? Nada de lo que medí lo sugiere. Cero concesiones de allowed-tools, cero líneas de contexto dinámico ! fuera de bloques de código, cero credenciales, cero claves privadas y un instalador que solo copia archivos. Los riesgos aquí son organizativos: contenido no descubrible, procedencia no declarada, una política de seguridad no aplicable, una afirmación falsa de cadena de suministro y acceso de escritura automático disparado por una cadena de texto en un comentario. Son reales, pero no son lo mismo que una carga maliciosa.

¿Por qué importan las estrellas frente a los watchers? 8.489 estrellas frente a 58 watchers es el 0,68%: el número de estrellas dice que el repositorio se vio, el de watchers dice que casi nadie quiere recibir notificaciones sobre él. Los 1.100 forks (13%) dicen que la gente copia en lugar de seguir. Para una biblioteca cuyo valor está en los archivos, ese cociente es esperable; también significa que su prueba social mide alcance, no mantenimiento ni validación del contenido.

¿Quién escribió el contenido? El README acredita al autor Kai Aizen (SnailSploit) y a “Original Checklists: Sahar Shlichov”. Dentro de los archivos, cinco de los más grandes llevan <!-- Written by AnotherOne from @Pwn3rzs Telegram channel -->, un crédito que no aparece en la documentación. 28 skills están convertidos del propio repositorio offensive-checklist del autor, según las líneas **Source**. Las técnicas de la biblioteca citan HackTricks (6 skills), PortSwigger (11), PayloadsAllTheThings (4), GTFOBins (1) e identificadores MITRE ATT&CK (28 skills), que es un hábito de citación razonable para este tipo de material.

¿Lo instalaría? Tal cual, no, y desde luego no clonando todo dentro de ~/.claude/skills. Si necesitas una técnica concreta, toma el archivo suelto, comprueba que empieza por ---, reescribe tú la descripción para que el disparador coincida con cómo hablas realmente de la tarea, recorta el cuerpo a lo que vas a usar en la próxima hora y deja el resto en un archivo de referencia al que el skill apunte. Son 20 minutos por skill y produce algo para lo que el modelo de carga de la plataforma fue diseñado. Lo que no deberías hacer es aceptar el recuento de la insignia como inventario: la distancia entre 78 anunciados y 51 utilizables es toda la lección.

El número que hay que recordar

No 8.489 estrellas. No 78 skills. El número es 28 de 79, y en concreto que esos 28 archivos concentran el 77,2% de los bytes, que el mayor de ellos ronda los 142.000 tokens frente a una guía documentada de 5.000, y que la propia guía de contribución del repositorio nombra el defecto antes que cualquier auditor.

Una biblioteca de skills no se mide por cuánta metodología contiene, sino por cuánta de esa metodología puede el modelo alcanzar, describir y cargar con seguridad, y por si las afirmaciones verificables del editor sobreviven a que alguien las verifique. Aquí, el recuento de frontmatter, las cadenas vacías del manifiesto, los commits sin firmar y la puerta de /apply-optimize apuntan en la misma dirección: es un cuerpo de material grande y genuinamente investigado publicado como archivo, no operado como sistema. Publicar eso está bien. Es una cosa distinta de lo que sugiere la insignia.