El 26 de octubre de 2026 ejecutamos tres skills de un repositorio de GitHub que circulaba por todas partes, las aplicamos a nuestro propio sitio web y luego cotejamos cada hallazgo con las páginas activas. El resultado más útil fue incómodo. Nuestra página de inicio envía el botón principal directamente a un pago de 990 € sin decir qué incluye la Marketing Review. En nuestra página de orquestación de agentes de IA, tres modalidades de proyecto distintas (Discovery Sprint de 2 a 3 semanas, Prototype Build de 4 a 8 semanas y Agent Operating System de 8 a 16 semanas o más) enlazan todas a ese mismo pago de 990 €, y el precio nunca aparece en la página. Las tres skills encontraron alguna variante de este problema de oferta.
Qué es el repositorio
El repositorio es github.com/coreyhaines31/marketingskills, de Corey Haines, bajo licencia MIT. Es una biblioteca de Agent Skills para agentes de código como Claude Code, Codex y Cursor. En el commit que probamos (e85f3cb, 19 de octubre de 2026) contenía 52 carpetas de skills. Cada skill lee primero un archivo de contexto de «product-marketing» que describe tu producto. GitHub mostraba 56.578 estrellas el 26 de octubre de 2026 a las 09:47 CET. Durante la semana del 20 de octubre, varias publicaciones en X promovieron el repositorio ante audiencias grandes, y una de @RoundtableSpace tuvo unas 65.800 vistas.
El README dice que los «Verified Partners» financian el trabajo y que aparecen «listed alongside the neutral options and never influencing what the core skills recommend». Conviene recordarlo cuando una skill recomienda una herramienta concreta.
Cómo lo hicimos
Ejecutamos cro, seo-audit y copywriting contra dos páginas activas: nuestra página de inicio y nuestra página de orquestación de agentes de IA. Las instrucciones completas de cada skill actuaron como prompt del sistema, y los datos de la página salieron de una descarga en directo del HTML. El modelo fue Claude Sonnet 5.5 a través de OpenRouter. No teníamos un archivo de contexto de product-marketing, así que pedimos al modelo que explicitara sus suposiciones y que no inventara números. No tocamos nada del sitio. Después cotejamos cada hallazgo con las páginas activas con nuestras propias peticiones a esas páginas.
Revisamos 22 hallazgos. 14 se confirmaron, algunos solo en parte o como opinión defendible. 3 eran incorrectos o exagerados, 3 eran débiles o cuestión de criterio, 1 era una colección de consejos genéricos y 1 lo causó nuestra propia configuración.
Lo que se confirmó
Aparte del problema de la oferta, las skills encontraron problemas más pequeños de los que cuesta ver en tu propio sitio. Dos de nuestras tarjetas de «where growth gets stuck» se leían como soluciones en lugar de problemas. Los enlaces a «Guides» y «Cases» en la navegación van a la misma página. El pie de página sigue diciendo «Updated: August 2026». Nuestras páginas de agradecimiento llevan una etiqueta noindex, pero robots.txt bloquea esas páginas, así que Google nunca llega a ver la etiqueta.
La skill de copywriting fue la más cuidadosa de las tres. Escribió un H1 nuevo para la página de orquestación, «AI agent workflows your team can check, approve and audit», usando solo afirmaciones que ya estaban en la página. También enumeró lo que no escribiría sin hechos: el plazo de entrega y la política de reembolso. Nos pareció más útil que una suposición presentada con total seguridad.
Lo que estaba mal, y la culpa fue nuestra
Las tres skills señalaron una ruta de imagen con «imges» en el nombre de la carpeta como posible error tipográfico que podría estar roto. La imagen carga sin problemas. La skill de CRO dijo que nuestra página de Contacto podría dar un 404. Carga, y la URL en minúsculas redirige a ella. La skill de SEO calculó mal la longitud de nuestras metadescripciones por unos caracteres; nosotros medimos 157 y 150. Cada afirmación de «podría estar roto» era una suposición, y bastó con cargar la página una vez para resolver cada una.
Un hallazgo salió de nuestra propia configuración. La skill de SEO dijo que nuestro sitemap no tenía alternativas de idioma. Tiene 122. Lo que pasa es que solo le habíamos pasado la lista de URLs, no el archivo completo. Esa misma ejecución vio solo los primeros 1.500 caracteres de nuestros datos estructurados porque nuestro script de extracción los truncó, y la skill lo señaló ella misma. Las skills solo pueden juzgar lo que les das.
El grupo genérico era la lista de siempre: añade una garantía, añade un testimonio, ejecuta estas pruebas A/B. Son sugerencias que encajarían en casi cualquier página, así que no nos decían nada concreto sobre la nuestra.
Si quieres repetir esto, un detalle técnico: nuestra primera ejecución de SEO no devolvió nada porque el modelo gastó todo su presupuesto de tokens en razonamiento. La repetimos con un presupuesto mayor y obtuvimos un informe completo.
Cómo usaríamos estas skills
Si las volvemos a ejecutar, seguiremos cuatro reglas:
- Rellenar primero el archivo de contexto de product-marketing. Sin él, el modelo tiene que adivinar tu posicionamiento.
- Pasar los datos completos de la página: el sitemap entero, los datos estructurados enteros y el HTML entero. Con una entrada truncada, los hallazgos quedan incompletos, pero el tono sigue sonando a certeza absoluta.
- Comprobar cada afirmación de «podría estar roto» cargando la página de verdad. Todos nuestros hallazgos erróneos sonaban plausibles, y cada comprobación llevó solo unos segundos.
- Tratar el resultado como una lista de comprobación para una persona que decide (hablamos de esto en «Agents do the busywork. People make the call.»). 8 de nuestros 22 hallazgos necesitaron que una persona los rebajara, los descartara o los reclasificara.
Todavía no hemos corregido los problemas. Los enlaces de pago, el pie de página desactualizado, la entrada de navegación duplicada y el resto pasarán por nuestro proceso de lanzamiento habitual, como cualquier otro cambio. Las skills encontraron problemas reales en nuestras páginas. Decidir qué cambiar y publicarlo sigue siendo trabajo nuestro.