reverse-skill: el router de ciberseguridad para tu agente

Le pides a tu agente que analice un APK y empieza a improvisar.

Que si unzip, que si a lo mejor jadx está instalado, que si busco los strings a ver qué sale. Veinte minutos después tienes una carpeta llena de basura, cero conclusiones y la sensación de haber pagado tokens por ver a alguien dar palos de ciego con estilo.

El problema no es que el modelo no sepa de ingeniería inversa. Es que no sabe por dónde empezar y nadie se lo ha dicho.

reverse-skill es un repositorio que se dedica exactamente a eso: decirle a tu agente por dónde empezar. No es un instalador, no es un framework, no es una colección de prompts. Es un router: mira la tarea, decide qué metodología aplica, comprueba qué herramientas tienes en la máquina y solo entonces deja que el agente toque nada.

Esto es lo que vamos a ver:

• Para qué sirve exactamente y qué problema resuelve (spoiler: el de la parálisis por herramientas)
• Cómo se usa: del git clone a tu primer caso, con los comandos reales
• Cómo funciona la escalera de routing con 40 reglas y por qué es lo mejor del paquete
• El scope.md que bloquea al agente hasta que hay autorización por escrito
• La “ingeniería de obediencia” que hay dentro, que te sirve aunque no toques la seguridad ni con un palo
• Lo que escribe en tu ~/.claude/CLAUDE.md y por qué eso merece una lectura con lupa

Vamos al lío.

Para qué sirve reverse-skill ¶

reverse-skill sirve para que un agente de código (Claude Code, Codex CLI, Cursor, Cline, Windsurf, Kiro) sepa qué metodología aplicar ante una tarea de seguridad, en lugar de inventarse comandos sobre la marcha. Le das un APK, un binario, un JS ofuscado, un reto de CTF o un objetivo de pentest autorizado, y el paquete lo encamina a un playbook concreto antes de que ejecute nada.

El propio README lo explica sin rodeos con cuatro motivos:

• Los agentes de IA no saben si toca jadx, apktool, Frida, IDA o BurpSuite para una tarea dada
• Un APK, un ELF, un JS y un PCAP necesitan playbooks distintos
• Las herramientas, servidores MCP y scripts están desperdigados por la máquina
• Los mismos errores se repiten porque la experiencia no se reutiliza

Fíjate en que ninguno de esos cuatro problemas es de capacidad del modelo. Todos son de contexto y de orden. El modelo sabe qué es apktool; lo que no sabe es que en tu máquina está en una ruta rara, que antes de descompilar conviene hacer triaje estático, y que el resultado hay que guardarlo en un sitio concreto para que el informe salga solo al final.

🔑 reverse-skill no le enseña seguridad a tu agente. Le enseña procedimiento. Y en trabajo de seguridad el procedimiento es la mitad del oficio.

El flujo completo que propone cabe en seis líneas:

Tarea del usuario
  → RULES.md
  → MASTER-ROUTING / master-route.ps1 (PRIMARY)
  → case-init / scope.md (autorización + perfil de red; sin esto no se toca el objetivo)
  → Skill del escenario → herramientas / MCP / scripts
  → timeline + Evidence→Finding→Path
  → informe + field-journal

Cada flecha de ahí es una decisión que normalmente tomas tú a mano y mal. El paquete las congela en ficheros markdown.

Una aclaración importante antes de seguir, porque el nombre despista: aquí “skill” no significa siempre una Agent Skill de Anthropic con su SKILL.md y su frontmatter estándar. reverse-skill usa la palabra en un sentido más amplio, el de “módulo de metodología”. Hay ficheros SKILL.md por todas partes, sí, pero el paquete está pensado para leerse como documentación dirigida al agente, no para instalarse en ~/.claude/skills/.

Cómo se usa reverse-skill: del clone al primer caso ¶

La instalación son dos pasos: clonar y refrescar el índice de herramientas. Nada de instaladores, nada de Docker, nada de base de datos.

git clone https://github.com/zhaoxuya520/reverse-skill.git

Y después, según tu plataforma:

Ese segundo paso no es opcional y es el que más gente se salta. El fichero skills/tool-index.md no viene en el repositorio: está en el .gitignore a propósito, porque es específico de tu máquina. Si no lo generas, las reglas de routing intentan leerlo, no lo encuentran y el enrutamiento se rompe. El propio README_AI.md lo marca con un aviso en negrita para que el agente lo ejecute antes que nada.

Lo que genera es un inventario de qué tienes y qué te falta:

Disponibles: node, python, pip, java...
Faltan (auto-instalables): jadx, radare2...
Faltan (instalación manual): zipalign, apksigner, IDA Pro

Ese inventario es la única fuente de verdad sobre herramientas. La regla que el paquete le mete al agente es tajante: nunca adivines una ruta, léela del tool-index. Y si una herramienta aparece como disponible, no la reinstales, aunque otro CLI la haya puesto ahí.

El tercer paso: apuntar a tu agente al fichero correcto ¶

Aquí está el truco de uso real. No hay comando reverse-skill init. Lo que haces es abrir tu agente en el directorio del repo y decirle algo tan tonto como:

Lee README_AI.md y sigue las instrucciones al pie de la letra.

README_AI.md empieza con un aviso explícito para humanos (“si eres una persona, vuelve al README normal”) y a partir de ahí es una secuencia de arranque escrita para que la lea un modelo. Detecta la ruta de instalación, detecta el sistema operativo, enruta a la documentación de plataforma que toque (Kali, Linux genérico, macOS), lee RULES.md y empieza a trabajar.

A partir de ahí, para cualquier tarea concreta:

# Triaje en un solo tiro: te dice qué skill es la PRIMARY
powershell -File skills\scripts\master-route.ps1 -Hint "<tu tarea>"

# Crear el caso: directorio de trabajo con scope, timeline y workitems
powershell -File skills\scripts\case-init.ps1 -Hint "<tu tarea>" -CaseName "mi-caso"

# Caso listo para actuar, con autorización y perfil de red declarados
powershell -File skills\scripts\case-init.ps1 -Hint "<tarea>" -CaseName "mi-caso" `
  -AuthGranted -TargetUrl "https://objetivo/" -NetworkProfile authorized_target_only

⚠️ Sí, los scripts son PowerShell. Windows es la plataforma primaria del paquete y se nota. En Linux y macOS tienes los .sh equivalentes para el índice de herramientas y el bootstrap, pero master-route.ps1, case-init.ps1 o append-evidence.ps1 te piden pwsh instalado. Si no lo tienes, la alternativa es abrir MASTER-ROUTING.md y escribir el scope.md a mano siguiendo la plantilla. Funciona, pero es más trabajo.

Si el paquete te ha cuadrado hasta aquí, el resto del post va de lo que hay debajo del capó. Y hay bastante más de lo que parece.

Curso gratis · paso a paso

Dale método a tu agente sin montarte un router entero

La idea de fondo de reverse-skill (procedimiento antes que improvisación) la aplicas a tu día a día con Spec Driven Development: instalas OpenSpec, recorres el ciclo completo sobre un proyecto de juguete y ves los cuatro artefactos funcionando antes de coger tú el volante.

Entra en el curso gratis →

Qué hace tu agente cuando lee README_AI.md ¶

La secuencia de arranque tiene nueve pasos numerados y está escrita en imperativo puro. Merece la pena verla resumida porque explica el diseño entero:

1. Ejecutar refresh-tool-index para generar el índice local
2. Detectar la ruta real de instalación del paquete (a partir de dónde está el propio fichero)
3. Detectar el sistema operativo y la distribución
4. Seguir el documento de despliegue de esa plataforma
5. Leer RULES.md y ejecutar todo lo que hay dentro
6. Enrutar con MASTER-ROUTING.md o master-route.ps1
7. Puerta de operaciones: crear el caso y el scope.md, con auth.status=granted y network_profile antes de tocar el objetivo
8. Abrir el SKILL.md de la skill PRIMARY y ejecutar su sección ACTION REQUIRED
9. Continuar hasta el informe, vía docs-generator y field-journal

Hay un detalle en el paso 5 que conviene subrayar. RULES.md se autodefine como “la única fuente de verdad” y abre con un bloque en mayúsculas cuyo mensaje es: si respondes “entendido” en vez de ejecutar, has fallado. Literalmente. El fichero está escrito para pelearse con la tendencia del modelo a confirmar en lugar de actuar.

Volveremos a eso más adelante, porque es la parte más interesante del repo para quien escribe sus propias skills.

Cómo decide qué skill abrir: la escalera de 40 reglas ¶

MASTER-ROUTING.md es una escalera de prioridad con 40 reglas, de R0 a R39, que se evalúan de arriba abajo. La primera que casa gana y se convierte en la PRIMARY. Si no casa ninguna con fuerza, cae a R0 (ingeniería inversa genérica) y sugiere abrir la matriz completa de routing.md.

Un extracto para que veas la lógica:

La matriz completa de routing.md sube el nivel: enruta por tres ejes en vez de uno. Tipo de objetivo (APK, ELF, PCAP, contenedor…), intención del usuario (analizar, explotar, documentar) y cadena de herramientas disponible. Y trae una regla que me parece la más sana de todo el paquete:

Si la ruta no casa → propón una skill nueva, no fuerces el encaje.

Esa línea vale su peso en oro. La alternativa, que es lo que hace un agente sin router, es meter un problema de firmware dentro de un playbook de APK porque “se parecen” y perder dos horas.

El paquete además tiene un script de coherencia, verify-routing-coherence.ps1, que comprueba que las tablas de routing, el script y el mapa de dominios no se hayan desincronizado. Detalle de mantenimiento que no esperas en un repo de tres semanas.

Qué es el scope.md y por qué el agente no toca nada sin él ¶

Esta es la parte que separa un repositorio serio de una colección de exploits con buenas intenciones. skills/ops/scope-contract.md define un contrato obligatorio: antes de actuar contra cualquier objetivo, tiene que existir un scope.md en el directorio del caso.

Sin scope.md, el agente solo puede leer documentación y enrutar. Escanear, hookear o explotar queda prohibido.

La plantilla es markdown puro, sin base de datos, y tiene estos bloques:

## auth
- status: granted | pending | denied
- basis: written_contract | bug_bounty_scope | ctf_public | own_system | lab_only
- evidence_of_auth: {ticket/ruta}
- MUST NOT proceed if status != granted

## in_scope
- assets: []      # hosts, dominios, rutas de APK, binarios, URLs

## out_of_scope
- activities: []  # p.ej. DoS, phishing a usuarios reales, exfiltración

## network_profile
- mode: offline | lab_only | authorized_target_only | unrestricted_lab

El network_profile es lo que más me gusta. Es un campo de una línea que responde a la pregunta “¿hasta dónde puede llegar la red?” y tiene cuatro valores con semántica clara:

Y el checklist de firma final, que es lo que convierte ready_for_act en true, exige cuatro cosas: autorización concedida, activos en scope no vacíos, modo de red elegido y out_of_scope revisado.

🛡️ Si vas a usar esto, el scope.md no es burocracia: es la diferencia entre una prueba de penetración y un delito. La autorización por escrito no la sustituye ningún fichero markdown, pero al menos el fichero te obliga a pararte a pensar si la tienes.

Cómo se documenta un hallazgo: Evidence → Finding → Path ¶

El paquete impone una cadena de tres eslabones para todo lo que se descubre. Es un contrato de campos en markdown, inspirado de forma explícita en el “Evidence Plane” de la plataforma Z3r0 pero reducido a ficheros.

Evidence es una observación inmutable. Cada una lleva su source_type (comando, captura, fichero, log, memoria, red), su content_hash si es un artefacto, un extracto anonimizado y, lo importante, un repro_command que un tercero pueda ejecutar.

Finding es la conclusión de seguridad. Severidad, categoría, estado, ubicación, impacto, confianza, pasos de reproducción y remediación. La regla dura: un Finding debe referenciar al menos una Evidence, y si su estado es validated no puede tener confianza baja.

Path es la secuencia: ruta de ataque en pentest, flujo de llamadas en ingeniería inversa, pasos de solución en un CTF. Cada paso enlaza con su evidencia.

powershell -File skills\scripts\append-evidence.ps1 -CaseRoot work\mi-caso `
  -Id E-001 -Title "..." -ReproCommand "..." -Severity info -Status observed

¿Por qué te cuento esto si no haces pentesting? Porque es un patrón exportable. Un agente que trabaja sobre un problema difícil tiende a saltar de la observación a la conclusión sin dejar rastro, y cuando le preguntas “¿de dónde sacas eso?” te improvisa una justificación. Obligarle a separar lo que vi de lo que concluyo y a guardar el comando exacto que lo reproduce es una técnica que funciona en depuración, en análisis de rendimiento y en revisión de código.

Qué escenarios cubre: el mapa completo ¶

La tabla de escenarios soportados es larga. Estos son los que trae la versión actual:

Y el changelog añade otra tanda que no está en esa tabla principal: protocol-reverse, ghidra-reverse, cloud-k8s, windows-ad, digital-forensics, code-audit, threat-hunting, wifi-wireless, browser-extension-reverse, ot-ics, macos-reverse, thick-client, go-rust-reverse, hardware-security, database-security, email-security, identity-federation y radio-sdr.

Un apunte de honestidad sobre el reparto de calidad: no todas esas carpetas tienen la misma profundidad. Las de APK, IDA, JS y pentest son las que llevan más recorrido. Las de la última tanda (R28 a R38) se añadieron en bloque y se nota que son más esqueléticas. El propio changelog las lista como “high-quality skills” añadidas de golpe, lo cual ya te dice que se generaron con criterio de cobertura, no de uso.

También hay una eliminación que dice mucho del mantenimiento: game-reverse/ se quitó porque “no es un foco de producto”. Un repo que borra cosas es un repo con criterio.

Qué es la “ingeniería de obediencia” y por qué te interesa aunque no toques la seguridad ¶

Aquí está la joya escondida del repositorio, y no tiene nada que ver con el pentesting.

En skills/llm-security/references/agent-obedience-engineering.md hay un documento sobre un problema que sufres a diario si trabajas con agentes: le das un flujo de trabajo, te dice que lo ha entendido y no hace nada.

El diagnóstico del documento es que la causa no es falta de capacidad del modelo, sino que el lenguaje natural deja “espacio de escape semántico”. Y enumera cinco raíces:

• Decaimiento de atención: lo que está en mitad de un documento largo se pondera menos. El agente solo “ve” bien el principio y el final.
• Reinterpretación creativa: al optimizar por ser útil, el modelo convierte un MUST DO X en “se sugiere hacer X”.
• Lenguaje pasivo tomado como opcional: “cuando estés listo, invoca X” se lee como consejo, no como instrucción.
• Sin máquina de estados externa no hay forma de detectar que se ha saltado un paso.
• Corrupción silenciosa: el agente produce algo estructuralmente correcto y semánticamente mal, y el error se acumula sin avisar.

Las técnicas que propone son directamente aplicables a cualquier CLAUDE.md, AGENTS.md o skill que escribas tú:

1. Instrucción al principio. Lo que hay que hacer va arriba, el contexto abajo. Nunca 70 líneas de background y luego el “siguiente paso”.

2. Lenguaje directivo nivel RFC 2119. Sustituir “puedes intentar” por MUST, “se recomienda leer routing.md” por REQUIRED: antes de entrar en cualquier submódulo.

3. Tabla de refutación de excusas. Esta es la que más me ha hecho pensar. Consiste en anticipar las excusas típicas del agente y refutarlas por escrito, antes de que las genere:

4. Autoverificación en banda. Antes de decir “terminado”, el agente ejecuta un autochequeo: ¿me he saltado algún paso?, ¿he adivinado alguna ruta?, ¿está el checklist completo? Si alguna respuesta falla, vuelve atrás y no declara nada.

5. Layout del contexto. El documento propone una distribución de atención (alta al principio, baja en medio, alta al final) y coloca a propósito la tabla de excusas y el checklist duro al final, en la zona de atención recuperada.

Hay una sexta técnica que cita una investigación de Microsoft de 2026 sobre identificadores opacos: los nombres de parámetro semánticos disparan la tendencia del modelo a “mejorar” los valores. Según la tabla del propio repositorio, un parámetro llamado top: 9 se respeta el 68,4% de las veces, mientras que un código opaco tipo code: "alpha" sube al 100%. No he podido verificar la fuente primaria de ese dato, así que tómalo como lo que es: una cifra citada de segunda mano en un fichero de un repo.

💡 Si solo te llevas una cosa de este post y no haces seguridad: copia la idea de la tabla de refutación de excusas a tus propias instrucciones de agente. Escribe las tres excusas que más te repite y refútalas por adelantado, al final del fichero. El cambio de comportamiento se nota.

Si te interesa este terreno, tenemos un post entero sobre buenas prácticas al escribir skills que va en la misma dirección desde el lado del diseño.

De la teoría al SKILL.md

Escribe skills que tu agente respete de verdad

Todo lo que acabas de leer sobre instrucción al principio, lenguaje directivo y checklists duros se aplica a las skills que escribes tú. En la guía verás cómo montar un SKILL.md reutilizable que funciona en Claude Code, OpenCode, Copilot y compañía.

Destripar el método →

Plantillas SKILL.md descargables incluidas

Qué escribe reverse-skill en tu ~/.claude/CLAUDE.md ¶

Y ahora la parte que hay que mirar con lupa.

RULES.md contiene una sección llamada Global Injection cuya instrucción es que el agente, en el primer uso, escriba las reglas de routing en la configuración global de su propio cliente. En Claude Code eso significa crear o añadir contenido a ~/.claude/CLAUDE.md. En Kiro, un fichero en ~/.kiro/steering/. En Cursor, Cline y Windsurf, como no puede escribir ficheros, pide al usuario que pegue el bloque a mano en los ajustes.

El objetivo declarado es razonable: que el routing se dispare en cualquier proyecto, no solo dentro del repo clonado.

El efecto secundario también es real: una lista de palabras clave de seguridad, bilingüe y muy larga, pasa a estar en el contexto de todas tus sesiones. La lista incluye términos como “reverse engineering”, “análisis binario”, “escaneo de puertos”, “escalada de privilegios” o “red team”, en inglés y en chino. Si un lunes cualquiera escribes “quiero hacer ingeniería inversa de esta API” pensando en documentar un endpoint, has activado un router de pentesting.

Mi recomendación es simple y no requiere renunciar a nada:

1. Deja que el paquete te enseñe el bloque que quiere escribir, pero escríbelo tú
2. Ponlo en el CLAUDE.md del proyecto donde vayas a hacer este tipo de trabajo, no en el global
3. Si aun así lo quieres global, delimítalo con un comentario para poder quitarlo de un tirón

Recuerda que todo lo que metes en el fichero global viaja en cada petición de cada sesión. Si te interesa el detalle de cómo Claude Code gestiona esos ficheros, lo desmenuzamos en el post sobre la memoria de Claude Code.

Al mérito del repositorio hay que decir que es consciente del problema. skills/ops/skill-supply-chain.md es un documento sobre seguridad de la cadena de suministro de skills que enumera los riesgos de instalar skills de terceros: skills envenenadas, permisos excesivos, MCP sin auditar, inyección de prompts dentro del texto de una skill, deriva de alcance. Y trae un checklist de instalación que incluye leer todos los scripts antes de ejecutar nada.

También hay un docs/PACKAGE-SECURITY-AUDIT.md con una auditoría estática de sus propios ejecutables, y el changelog registra cosas como fijar jadx a la v1.5.6 y apktool a la v3.0.2 con SHA256 publicado, o verificar el digest de las descargas de GitHub y borrar el fichero si no cuadra.

⚠️ Que un repositorio audite su propia cadena de suministro no significa que la auditoría sea completa ni imparcial. Significa que el autor se ha hecho la pregunta. Es mucho más de lo que hacen la mayoría, y sigue sin ser un sustituto de que lo mires tú.

Si te preocupa este vector, existen herramientas específicas para escanear skills antes de instalarlas: SkillSpector hace exactamente eso.

En qué se diferencia de un catálogo de 754 skills de ciberseguridad ¶

Pregunta legítima, sobre todo si ya leíste nuestro repaso a las 754 skills de ciberseguridad para agentes. ¿Para qué quieres un router si puedes tener un catálogo enorme?

Porque son cosas distintas y resuelven problemas distintos.

El propio IDENTITY.md del repositorio es tajante con esto: dice de forma explícita que no van a incorporar como submódulo una librería gigante de skills comunitarias, por superficie de envenenamiento y coste de mantenimiento, y que prefieren demostrar que “skills profundas + routing” gana a “apilar skills fragmentadas”.

Ese mismo fichero es un ejercicio de honestidad poco común: dedica media página a decir qué no es el paquete. No hay panel React, no hay control plane con FastAPI, no hay PostgreSQL de evidencias, no hay pool de contenedores. Solo markdown, scripts y un directorio work/ en el .gitignore.

Un repo que se define por lo que no hace suele haber pensado bastante en lo que sí hace.

Limitaciones honestas ¶

Las cosas que no me convencen, o que directamente te van a molestar:

Está muy sesgado a Windows. Los scripts principales son .ps1. Hay paridad en Bash para el índice de herramientas y el bootstrap, pero el triaje, el case-init, el guard de scope y el append de evidencias van por PowerShell. En macOS te toca pwsh o trabajo manual.

Buena parte de la documentación interna está en chino. El README, README_AI.md, RULES.md y routing.md tienen versión en inglés. Pero los contratos de skills/ops/, el MASTER-ROUTING.md y varios documentos de referencia están en chino. No es bloqueante (tu agente lo lee sin problema, y tú también con un traductor), pero si esperabas revisar tú a mano cada instrucción antes de dársela al modelo, prepárate.

El proyecto es muy joven. La v1.0.0 se etiquetó el 18 de julio de 2026. Está en la lista de tendencias de Trendshift y crece rápido, pero las cifras de estrellas que verás citadas por ahí varían mucho según el agregador, así que mírala en el propio repositorio antes de citarla en ningún sitio.

Las licencias son un mosaico. El grueso es MIT, pero CTF-Sandbox-Orchestrator va con GPLv3 y hay dependencias AGPL-3.0 declaradas aparte. Si esto entra en un contexto comercial, léelo con calma.

El diseño empuja al agente a actuar sin pausa. La tabla de refutación de excusas y las instrucciones de tipo “no esperes confirmación” son eficaces, pero están apuntando justo al mecanismo que hace que un agente se pare a preguntar. En una herramienta de seguridad, esa pausa a veces es lo único que hay entre un análisis y un incidente. El scope.md compensa en parte, porque bloquea la actuación hasta que hay autorización. Aun así, yo no dejaría esto trabajando sin supervisión.

No es una skill instalable al uso. Si esperabas un /plugin install y listo, no es eso. Es un repositorio que clonas y al que apuntas tu agente.

Mi veredicto ¶

reverse-skill me interesa por una razón que casi no tiene que ver con la ciberseguridad: es el ejemplo mejor documentado que he visto de una capa de decisión explícita para un agente.

La idea de fondo es que el agente no elija sobre la marcha entre veinte caminos. Que haya una escalera de reglas, una puerta de autorización, un formato de evidencias y un checklist de cierre. Todo en markdown, todo versionado, todo auditable a ojo. Eso es transferible a cualquier dominio donde tu agente tenga que elegir entre metodologías: migraciones, incidentes de producción, revisiones de arquitectura.

¿Lo instalaría en mi configuración global? No. ¿Lo clonaría para estudiar cómo está montado MASTER-ROUTING.md, scope-contract.md y el documento de obediencia? Ya lo he hecho.

Si trabajas en seguridad ofensiva con autorización, es de lo más completo que hay ahora mismo para agentes. Si no, léelo como lo que también es: un manual de cómo se le pone barandilla a un agente que puede hacer daño.

TL;DR ¶

• 🧭 reverse-skill es un router, no un instalador: mira tu tarea de seguridad, elige metodología con una escalera de 40 reglas y solo entonces deja que el agente ejecute
• ⚙️ Se usa en tres pasos: git clone, refresh-tool-index (obligatorio, el índice está en .gitignore) y apuntar tu agente a README_AI.md
• 🛡️ El scope.md bloquea la acción hasta que hay autorización concedida y perfil de red declarado: sin eso el agente solo puede leer y enrutar
• 🧠 La joya escondida es agent-obedience-engineering.md: instrucción al principio, lenguaje RFC 2119, tabla de refutación de excusas y autoverificación, aplicable a cualquier skill que escribas
• ⚠️ Ojo con la inyección global: quiere escribir sus reglas en tu ~/.claude/CLAUDE.md y eso mete un router de pentesting en todas tus sesiones

Preguntas frecuentes sobre reverse-skill ¶

¿Qué es reverse-skill exactamente?
Es un repositorio de GitHub que funciona como router de metodologías de ciberseguridad para agentes de código. Ante una tarea (APK, binario, JS cifrado, CTF, pentest autorizado) decide qué playbook aplicar, comprueba qué herramientas hay en la máquina y guía al agente por un flujo de trabajo repetible.

¿Cómo se instala reverse-skill?
Clonas el repositorio con git clone https://github.com/zhaoxuya520/reverse-skill.git y ejecutas el script de refresco del índice de herramientas de tu plataforma (refresh-tool-index.ps1 en Windows, refresh-tool-index.sh en Linux, macOS o Kali). Después abres tu agente en ese directorio y le pides que lea README_AI.md.

¿Funciona con Claude Code o solo con un cliente concreto?
Funciona con cualquier cliente que admita instrucciones de proyecto o reglas globales. El repositorio menciona Claude Code, Codex CLI, Cursor, Cline, Windsurf y Kiro. Claude Code es el que aparece como recomendado en la tabla de dependencias, porque puede escribir la configuración global por su cuenta.

¿Necesito instalar todas las herramientas antes de usarlo?
No. El script de índice detecta qué tienes y marca lo que falta en tres categorías: disponible, instalable de forma automática por el bootstrap e instalación manual obligatoria (IDA Pro, apksigner, zipalign). El bootstrap solo instala capacidades declaradas en su manifiesto.

¿Por qué falla el routing nada más clonar el repositorio?
Porque skills/tool-index.md no viene incluido: está en el .gitignore a propósito, ya que depende de tu máquina. Hasta que no ejecutas refresh-tool-index, las reglas intentan leer un fichero que no existe y el enrutamiento se rompe.

¿Es legal usar esto?
El paquete en sí es documentación y scripts de organización. Lo que puede ser ilegal es lo que hagas con él. Por eso incluye el contrato de scope: exige autorización concedida (auth.status=granted) con una base declarada (contrato escrito, alcance de bug bounty, CTF público, sistema propio o laboratorio) antes de permitir cualquier acción contra un objetivo.

¿Qué es el network_profile?
Es un campo del scope.md que declara hasta dónde puede llegar la actividad de red del caso. Tiene cuatro valores: offline (sin conexiones salientes), lab_only (solo laboratorio o CTF), authorized_target_only (solo los activos listados como in-scope) y unrestricted_lab (red aislada con autorización escrita).

¿Qué diferencia hay entre reverse-skill y un catálogo de skills de ciberseguridad?
Un catálogo resuelve la cobertura: que exista una skill para tu caso. reverse-skill resuelve la selección: que el agente entre en la metodología correcta y siga un procedimiento. Además no se instala en tu agente como skills sueltas, se lee como documentación desde el repositorio clonado.

¿Escribe algo en mi configuración de Claude Code?
Sí, si le dejas. RULES.md incluye una sección de inyección global que pide al agente escribir las reglas de routing en ~/.claude/CLAUDE.md en el primer uso. Puedes evitarlo pidiéndole que te enseñe el bloque y colocándolo tú en el CLAUDE.md del proyecto concreto donde vayas a trabajar.

¿Qué licencia tiene?
Principalmente MIT, con excepciones: el módulo CTF-Sandbox-Orchestrator está bajo GPLv3 y hay dependencias con AGPL-3.0 declaradas aparte. Revísalo antes de meterlo en un contexto comercial.

Fuentes ¶

• Repositorio reverse-skill en GitHub
• README_AI.md, la secuencia de arranque para agentes
• RULES.md, la fuente de verdad del comportamiento
• skills/MASTER-ROUTING.md, la escalera de prioridad
• skills/ops/scope-contract.md, el contrato de autorización
• skills/ops/evidence-finding-path.md, la cadena de evidencias
• skills/llm-security/references/agent-obedience-engineering.md
• CHANGELOG.md del proyecto

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter