Stack de habilidades Claude Code de un ingeniero senior

Stack de habilidades Claude Code de un ingeniero senior

La primera vez que vi a un agente de Claude Code tomar un ticket de Jira, reproducir el bug en un navegador real, diagnosticarlo, escribir una prueba que falla, resolver el problema, hacer push a main y notificar a QA —todo sin que yo tocara el teclado entre pasos— tuve esa sensación incómoda que tarde o temprano tiene todo ingeniero en activo. No fue un “esto va a reemplazarme”. Fue más bien: “llevo tres años haciendo una versión de esto de forma incorrecta”.

El ingeniero que estaba observando no era un YouTuber de IA. Era un ex-senior de Amazon y Microsoft, ahora lanzando un producto llamado BookZ.AI, y había construido lo que probablemente sea el stack de habilidades de Claude Code más disciplinado que he visto en 2026. Ocho habilidades. Cada una resolviendo un modo de fallo específico en la experiencia de “Claude Code puro”. Juntas, logran algo que la documentación realmente no anuncia: convierten a Claude Code de un simple autocompletado inteligente en algo mucho más parecido a un equipo de ingeniería junior a intermedio que trabaja a las 3 AM.

Pasé el fin de semana desmontando ese stack, instalando las piezas y probándolas en un pequeño SaaS que estoy desarrollando. Algunas cumplieron lo prometido. Otras están sobrevaloradas. La habilidad de Fixed Ticket realmente me sorprendió. El stack de marketing —la parte que asumí sería sólo relleno— resultó ser el elemento más infravalorado de toda la configuración.

Aquí tienes el desglose completo: qué hace cada habilidad, cuándo la usaría, cómo se combinan y los puntos específicos donde la experiencia de Claude Code puro no está a la altura sin ellas.

Por qué el “Claude Code en crudo” termina fallando

Claude Code, por sí solo, es una herramienta poderosa. Señalas un repositorio, describes lo que necesitas, y te escribe el código. Eso funciona de maravilla para un proyecto de fin de semana. Pero comienza a desmoronarse en cuanto tu base de código recibe un segundo colaborador, un despliegue a producción y una base de usuarios que detecta errores.

Los tres modos de fallo con los que me encuentro repetidamente:

1. Se salta pasos. Claude Code en crudo escribirá encantado la funcionalidad y los tests—pero solo si se lo pides de forma insistente, en orden, y rechazas su primer borrador. Si lo dejas a su aire, deriva hacia un “coding por sensaciones”: entrega la funcionalidad, aplaza los tests, posterga el refactor, y nunca vuelve realmente atrás.
2. Pierde el contexto entre sesiones. Cada nueva sesión comienza desde cero. Tus convenciones de proyecto, tu lenguaje de diseño, tu historial de bugs—todo eso tiene que redescubrirlo desde CLAUDE.md y cualquier cosa que pegues en el prompt.
3. No cierra los ciclos. Escribe código, pero ¿realmente lo ejecuta? ¿El bug sigue reproduciéndose? ¿El despliegue tuvo éxito? Alguien—normalmente yo—tiene que verificar todo eso, y ese paso de verificación es donde la mayoría de los “demos de IA que escribe código” se vienen abajo en silencio.

Las habilidades que voy a describir no son trucos generales de productividad. Cada una cierra un ciclo concreto. Juntas, logran que Claude Code se comporte menos como un becario con exceso de cafeína y más como un equipo que realmente cumple con lo prometido.

Si aún no has construido el modelo mental de lo que serán las skills en 2026, mi guía de habilidades de agentes para Claude Code cubre la mecánica subyacente; este artículo asume que ya tienes esas bases y quieres ver cómo se ve un stack de producción.

Habilidad 1: Superpoderes — La Capa de Disciplina

La habilidad fundamental. Aquella sin la cual las otras siete son solo formas más elegantes de producir caos.

Superpoderes es un plugin open-source de Claude Code desarrollado por obra (Jesse Vincent) que consiguió más de 99k estrellas en GitHub en apenas tres meses tras su lanzamiento en enero de 2026 — lo cual es absurdo para un plugin, y dice mucho sobre cuánta demanda hay para este problema específico. Fue admitido oficialmente en el marketplace de plugins de Anthropic poco después.

Lo que hace, en una sola frase: hace que Claude Code siga un workflow real de ingeniería senior en vez de lo que parezca más rápido.

El workflow que impone:

1. Lluvia de ideas — convierte una petición vaga en una especificación concreta de decisiones
2. Especificación — deja por escrito qué vas a construir realmente, y qué explícitamente no
3. Planificación — descompón en tareas de 2-5 minutos con rutas exactas de archivos
4. TDD — red-green-refactor, los tests deben fallar antes de implementar
5. Desarrollo de Subagentes — cada tarea corre en un subagente nuevo para evitar deriva de contexto en ejecuciones de varias horas
6. Revisión — revisión de código automática antes de considerar cualquier tarea como terminada
7. Finalización — creación de PR, limpieza de ramas, gestión de worktree

La parte innegociable es el ciclo TDD. Superpoderes no dice “puedes usar TDD”. Dice “vas a usar TDD”, y lo hace cumplir a través de la arquitectura del skill, no con instrucciones educadas. Los tests se escriben primero. Deben fallar. Solo entonces se escribe la implementación. Si tu test de hecho no falló en la fase roja, el skill lo marca como un falso verde y bloquea el avance.

Ese solo principio eliminó alrededor del 60% de los problemas de “Claude generó código que compila pero no hace lo que pedí” que venía teniendo. Porque si el test se escribió acorde al comportamiento real que quería, y se comprobó que fallaba antes de escribir el código, entonces el código hace pasar el test o no lo hace. No hay un punto medio donde Claude alucina una función que devuelve algo más o menos correcto.

Cuándo lo uso: literalmente en cada sesión que toca código de producción. El único lugar donde no lo uso es en scripts desechables y notebooks exploratorios, donde el ritual cuesta más de lo que aporta.

Si vas a instalar una sola habilidad de toda esta pila, que sea esta. Todo lo demás en este artículo asume que Superpoderes ya está manteniendo el ciclo de desarrollo honesto. Escribí una reseña más extensa del plugin Superpoderes si quieres profundizar en cómo hace cumplir el TDD específicamente.

Habilidad 2: Creador de Habilidades — La Capa Meta

Esta es la parte que me confundió durante un tiempo vergonzosamente largo: Creador de Habilidades es una habilidad que construye otras habilidades. Es, esencialmente, la fábrica de desarrollo de habilidades.

Anthropic la creó. Viene con cuatro modos de operación: Crear, Evaluar, Mejorar y Benchmark. Juntos cubren todo el ciclo de vida de una habilidad — desde "tengo una idea" hasta "he medido esta habilidad frente a una carga de trabajo real y sé si realmente aporta valor".

¿Por qué importa esto? Porque el verdadero poder del ecosistema de habilidades no está en instalar habilidades de otras personas. Está en componer las tuyas propias. El ingeniero senior que dirigía BookZ.AI no trató a Superpowers como la última palabra. Tomó Superpowers, tomó piezas de GSD (Get Stuff Done), tomó piezas de GStack y construyó una habilidad personalizada y unificada que gestionaba su flujo de trabajo específico: sus etapas preferidas, sus frameworks de testing favoritos, su cadencia de revisión personalizada.

El enfoque de componer tus propias habilidades es importante porque las habilidades están delimitadas por etapas. Puedes intercambiar un módulo de brainstorming sin perder tu fase de TDD. Puedes agregar una fase de revisión personalizada que ejecute las reglas de lint de tu equipo. El modo de Evaluación de Creador de Habilidades te permite medir cada versión frente a un benchmark — "¿esta habilidad actualizada realmente produce mejor código sobre mi base de código real, o simplemente genera más código?"

Lo que la mayoría de los tutoriales omite es lo importante que es el ciclo de evaluación. Escribir una habilidad es fácil. Escribir una habilidad que demuestre mejorar los resultados en tu trabajo es lo que separa una habilidad de juguete de una que realmente usas.

Cuándo la utilizo: cada vez que noto que repito el mismo prompt de más de 5 frases en varias sesiones. Esa repetición es la señal — hay una habilidad esperando nacer.

Skill 3: UI/UX ProMax — El Sistema de Diseño Bajo Demanda

Esta era la que más escepticismo me generaba. “Habilidad de UI/UX” suele significar “dashboard genérico con Tailwind”. ProMax es todo lo contrario.

La base de datos subyacente, según la documentación oficial de la skill, incluye más de 50 estilos visuales, 161 paletas de colores, 57 combinaciones tipográficas, 161 tipos de producto, 99 guías UX y 25 tipos de gráficos, abarcando 10 stacks de destino (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, HTML/CSS puro). La skill se activa automáticamente cuando la tarea involucra estructura de UI, refactorización de componentes, elección de sistema de colores o tipografía — no tienes que invocarla manualmente.

El detalle que me convenció: predeterminados específicos por industria. Si dices “dashboard fintech”, las opciones de estilo/color/tipografía de la skill ya están restringidas a lo que realmente usan los dashboards de fintech: tablas de alta densidad, paletas tenues diseñadas para soportar salas de trading con poca luz, tipografía monoespaciada para contextos numéricos. Si pides “app de productividad calmada”, los predeterminados apuntan a mayor contraste, espacios generosos y tipografías optimizadas para largas sesiones sin cansancio visual.

ProMax se integra con el patrón “Stitch” de Google, en el que entregas a la skill un archivo design.md describiendo la experiencia deseada, y este genera un sistema de diseño completo: patrones, tokens de color, combinaciones tipográficas, auditoría de accesibilidad (WCAG AA como mínimo por defecto), estructura meta para SEO y presupuestos de rendimiento. El repositorio Awesome Design MD en GitHub recopila ejemplos preconstruidos de design.md para tipos de productos comunes, así no tienes que partir de una hoja en blanco.

El modo de restricción es donde se vuelve realmente útil. Puedes decirle a ProMax: “mantén la paleta de colores y el grid de layout existentes, pero rediseña todo dentro de esas restricciones”. Y realmente lo respeta — no en el sentido de “sugiere cambios y espera que los notes”, sino como limitaciones estrictas que se niega a traspasar. Probé esto en una landing page donde me encantaba el sistema de colores pero detestaba el hero. ProMax devolvió cinco variantes de hero usando exactamente los mismos tokens existentes. Ese es el test que normalmente hace fallar a otras herramientas de diseño.

Cuándo lo uso: cada vez que inicio trabajo UI desde cero, reescribo una landing o estoy a punto de tomar una decisión de diseño que se propagará por el resto del producto. Lo desactivo cuando hago ediciones quirúrgicas a un sistema de diseño ya establecido — las opiniones de la skill ahí no aportan y activarla añade ruido.

Si al ver esto piensas “ya tengo Figma”, perfecto. Pero aquí el valor no es reemplazar Figma. Es permitir que Claude Code tome decisiones conscientes del diseño dentro del código, en vez de preguntarte qué color debería llevar el botón. En mi post sobre el workflow de sistemas de diseño IA con Claude Code explico cómo integro ProMax en el resto del pipeline.

Habilidad 4: Playwright — El Cierre del Bucle de Pruebas

Aquí es donde “ingeniero de IA” deja de ser solo un término de marketing.

Claude Code con la integración de Playwright puede realmente abrir un navegador, navegar en tu aplicación, hacer clic en botones, rellenar formularios, tomar capturas de pantalla, leer el DOM y verificar si lo que acaba de construir realmente funciona. Hay dos variantes en circulación: el servidor Microsoft Playwright MCP (instálalo con claude mcp add playwright npx @playwright/mcp@latest) y las skills de comunidad basadas en CLI como lackeyjb/playwright-skill.

La elección entre CLI y MCP importa más de lo que la mayoría imagina. MCP mantiene el estado persistente del navegador — ideal para pruebas exploratorias, pruebas autocurativas y bucles autónomos largos. Las skills basadas en CLI son más eficientes en tokens — invocan Playwright por tarea y no mantienen contexto entre ejecuciones. Para el bucle “escribir funcionalidad → verificarla en un navegador real → iterar” que la mayoría de ingenieros sigue, la CLI suele ser la opción más adecuada. Para sesiones de QA impulsadas por agentes, que necesitan razonar entre múltiples estados de página, MCP gana.

La demo del video del ingeniero de BookZ.AI lo hizo tangible. Apuntó Claude Code a una app de Replit que no era suya — solo la URL, sin acceso al código fuente — y le dijo “encuentra bugs.” La skill ejecutó lo que el creador llamó 16 fases de prueba. Capturó 81 capturas de pantalla en esas fases. Generó un informe de QA con defectos específicos y reproducibles: validación de formularios rota en un campo concreto, un modal con enfoque mal gestionado, un botón cuyo área de clic era 4px menor que su límite visual. (Todos esos números son del walkthrough del creador — yo hice una prueba más pequeña en mi propia app y la skill encontró tres defectos reales que no había detectado, pero no reclamaré los números de BookZ en mi setup).

Luego entraron en juego Superpowers y Fixed Ticket: los subagentes planearon las correcciones, escribieron tests fallidos que reproducían cada defecto, implementaron las soluciones, verificaron, hicieron commit y desplegaron.

Ese es todo el ciclo. Una sola instrucción — “encuentra bugs y arréglalos” — y las skills se pasaron el control entre funciones que normalmente necesitaría tres personas para cubrir.

Cuándo la utilizo: siempre que una funcionalidad tiene interfaz de usuario. Ahora también la integro en CI — una pasada de smoke tests con Playwright es un requisito de despliegue para cualquier cosa que afecte la aplicación de cara al usuario.

Habilidad 5: Telegram — Control Remoto

La habilidad que estaba seguro de que nunca usaría. Tres semanas después, la utilizo a diario.

La configuración es sencilla: lanza Claude Code con claude --channels plugin:telegram@claude-plugins-official, envíale un DM al bot, te responde con un código de emparejamiento de 6 caracteres, pegas el código, y listo. A partir de ahí, cada mensaje que envíes al bot desde tu teléfono se reenvía a tu sesión local de Claude Code, se procesa contra tus archivos reales, y la respuesta te llega directo por Telegram. El trabajo se ejecuta en tu máquina. El control lo llevas en el bolsillo.

Tres casos de uso reales que lo justifican:

1. Lanzar trabajos largos estando lejos del escritorio. “Ejecuta toda la suite de pruebas y dime si algo falla” enviado desde una cafetería. Veinte minutos después recibo una notificación con el resumen.
2. Reinicio de sesión y cambio de contexto. Puedes reiniciar la sesión de Claude Code desde Telegram, o alternar qué contexto de proyecto está activo. Muy útil cuando me doy cuenta en la cena de que inicié Claude en el repositorio equivocado.
3. Descarga cognitiva. Se me ocurre una idea. En vez de anotarla en una app de notas y olvidarla, se la mando al bot. Claude la registra en el vault de Obsidian del proyecto (ver siguiente habilidad), etiquetada y enlazada, para que esté disponible al día siguiente.

Aquí el modelo de seguridad es clave. Solo los usuarios de Telegram emparejados pueden enviar mensajes. Tienes que pasar explícitamente --channels al iniciar — no hay un modo pasivo de “siempre escuchando”, lo cual sería un desastre. Los mensajes no autorizados se descartan silenciosamente.

Cuándo lo uso: cada vez que salgo de casa mientras queda algún proceso largo ejecutándose. Y cada vez más, a medida que se fortalece el hábito de descargar ideas, cualquier vez que surge una idea que no quiero perder.

Habilidad 6: Obsidian — RAG Ligero Sin RAG

Esta es la habilidad que cambió mi forma de pensar sobre la memoria de los proyectos.

La habilidad de Obsidian viene de kepano — el CEO de Obsidian. Simplemente la incorporas a una carpeta de tu vault y Claude Code adquiere la capacidad de leer, escribir, etiquetar y enlazar notas en markdown en toda tu base de conocimiento. Sin base de datos vectorial. Sin pipeline de embeddings. Sin infraestructura de chunk-and-retrieve. Solo archivos .md en texto plano con wikilinks.

La percepción de diseño es la que Andrej Karpathy repite en público: los pipelines RAG tradicionales son excesivos para la gestión personal del conocimiento. El problema que resuelve RAG — "encontrar los tres párrafos más relevantes entre 10,000 documentos para esta consulta" — no es el problema que la mayoría de ingenieros realmente tiene. La mayoría de ingenieros tiene 200 notas de reuniones, 40 briefs de proyecto y 15 registros de decisiones arquitectónicas, y lo que buscan es vincularlos entre sí y que un agente navegue ese grafo.

La habilidad de Obsidian convierte a Claude Code en un agente capaz de hacer esa navegación. Le preguntas: "¿qué decidimos sobre el refactor de autenticación?" Recorre tu vault — lee el ADR, sigue el wikilink a la nota de la reunión, sigue el wikilink al ticket, sigue el wikilink al commit — y devuelve un resumen que cita las notas específicas. Cuando aprende algo nuevo, escribe una nueva nota y la enlaza de nuevo al grafo. El grafo crece con tu proyecto.

La diferencia de costes es la parte poco sexy pero real. Montar un pipeline de embeddings sobre una base de conocimiento de tamaño medio implica costes computacionales continuos. Un vault en markdown cuesta $0 en cómputo y puede versionarse con git. La comparación publicada por Karpathy situó la recuperación de igual calidad en aproximadamente un 95% más barato que un setup RAG convencional. Para un fundador en solitario o un equipo pequeño, no es un redondeo — es la diferencia entre "tengo una base de conocimiento" y "no tengo".

Llevo usando esto unas seis semanas en mis propios proyectos. Ha reemplazado Notion para mí. Mi artículo sobre el setup Karpathy-style de Obsidian RAG entra más a fondo en la mecánica del setup si quieres el paso a paso.

¿Cuándo la utilizo?: siempre activa. No es una habilidad de "la utilizo cuando…" — es infraestructura ambiental. Ahora cada proyecto que toco tiene un directorio /vault y la habilidad está activa por defecto.

Skill 7: El Pack de Habilidades de Marketing — 43 habilidades que casi pasé por alto

Supuse que esta sería la parte más débil del stack. Es la más fuerte.

El pack reúne aproximadamente 43 habilidades de Claude Code que cubren toda la superficie del marketing SaaS: investigación SEO, planificación de palabras clave, optimización on-page, copy para landing pages, experimentos de CRO, secuencias de nurturing por email, estrategia de contenidos, analítica (integración GA4, desgloses de ingresos por canal), monitoreo de embudo y reportes de rendimiento. El propio plugin de marketing de Anthropic incluye los comandos slash /performance-report, /seo-audit y /email-sequence; el pack comunitario coreyhaines31/marketingskills extiende aún más la superficie.

El ingeniero de BookZ.AI afirma que este pack de habilidades llevó su producto de 0 a 1,000 usuarios. No puedo verificar de manera independiente la cifra de usuarios —es su dato interno y lo reporto como su testimonio, no como referencia general—. Lo que sí puedo constatar es la dirección de lo que realmente hace el pack: ejecuta auditorías reales, produce mejoras tangibles on-page e integra con GA4 para cerrar el ciclo de atribución. Las puntuaciones Lighthouse reportadas en su sitio —SEO 100, Best Practices 100, Accessibility 100, Performance 97— son el tipo de métricas que un marketer técnico competente logra en dos semanas de trabajo enfocado. El pack lo comprime en horas.

Esta es su tabla de resultados reportada:

La parte que no esperaba: las habilidades se componen con ingeniería. Puedes ejecutar /seo-audit contra tu codebase real, y propondrá cambios HTML/meta específicos que las habilidades de ingeniería pueden implementar después mediante el flujo TDD de Superpowers: primero tests, luego el fix, después redeploy, y finalmente re-auditoría. El ciclo se cierra. Marketing no es un workflow aparte acoplado a ingeniería. Es el mismo workflow, con habilidades distintas.

Si eres un founder solo con un SaaS sin contratar a alguien de marketing, probablemente este pack esté haciendo más trabajo por dólar que cualquier otra cosa que tengas instalada. Escribí un artículo más extenso sobre cómo construir un equipo de marketing con Claude Code que se apoya directamente en este stack.

Cuándo lo uso: modo marketing, una vez por semana, los viernes por la mañana. El pack ejecuta las auditorías, agenda los experimentos de CRO, redacta los emails de la semana. Yo reviso, apruebo y se publica.

Habilidad 8: Fixed Ticket — El Pipeline de Corrección de Bugs

Guarda lo mejor para el final. Esta es la habilidad que me hizo replantearme cómo distribuir las tareas entre ingenieros junior.

Fixed Ticket toma como entrada una URL de un ticket de Jira. Devuelve una corrección ya desplegada y un pase a QA. Todas las etapas intermedias están automatizadas, salvo un único punto de control humano en la fase de aprobación.

Aquí tienes el flujo de trabajo en siete etapas, sacado directamente de la explicación del creador:

Según afirma el creador, esta habilidad reemplaza aproximadamente el 90% de la carga de trabajo de corrección de bugs de un ingeniero junior. Quiero tener cautela con ese porcentaje porque es su observación en su equipo—tu experiencia puede variar según la complejidad del código, la cobertura de tests y la calidad de tus tickets en Jira. Un mal ticket de Jira (“la app no funciona, arréglala”) hará que la habilidad falle en la Etapa 1.

Lo que sí puedo confirmar tras probarlo en mi propio backlog: en los tickets que tenían un paso claro de reproducción y un log de Sentry adjunto, la habilidad los cerró de extremo a extremo sin escribir yo una sola línea de código. En los tickets vagos o arquitectónicamente confusos, se detenía en la Etapa 3 (diagnóstico) y me pedía clarificaciones, que es el comportamiento correcto. No se inventó una solución. No desplegó algo incorrecto. Preguntó.

El punto de control de aprobación es la función más importante. Cada plan de corrección aterriza en tu bandeja antes de que se escriba una línea de código. Ves la hipótesis, el cambio propuesto, la prueba que se añadirá y el objetivo de despliegue. Apruebas o lo rediriges. Ese punto de control marca la diferencia entre un “pipeline de bugs automatizado” y un “generador automatizado de desastres”.

Cuándo lo uso: el pase de triaje de los lunes en el backlog de Jira. Apruebo en bloque los planes de corrección claros, redirijo los ambiguos y, para el miércoles, el backlog es visiblemente más corto sin haber escrito código para la mayoría de ellos.

Cómo se Componen las Ocho Habilidades

De forma individual, cada habilidad resuelve un modo de fallo específico. Apiladas, producen algo que funciona como un pequeño equipo de ingeniería:

• Superpoderes es la metodología. Es innegociable respecto a todo lo demás.
• Skill Creator es cómo la metodología se personaliza para tu flujo de trabajo en vez de uno genérico.
• UI/UX ProMax toma las decisiones de diseño para que no tengas que hacerlo tú.
• Playwright cierra el ciclo entre “el código está escrito” y “el código funciona”.
• Telegram libera al agente del escritorio, permitiendo que los trabajos largos se ejecuten en segundo plano.
• Obsidian otorga memoria de proyecto al agente sin necesidad de infraestructura.
• El pack de marketing cierra el ciclo entre “el producto existe” y “los usuarios llegan”.
• Fixed Ticket es el compresor del ciclo de vida de bugs: aquí es donde aterriza la mayor parte del ahorro bruto de tiempo.

La observación importante: ninguna de estas son habilidades de “productividad general”. Cada una es quirúrgica. Cada una soluciona un aspecto específico que está roto en la experiencia predeterminada de Claude Code. El motivo por el que el stack funciona como stack es que las soluciones no se solapan: cada una domina una etapa distinta del pipeline de entrega de producto, y se componen en vez de colisionar.

Si estás construyendo un stack similar, el orden en que las instalaría sería:

1. Superpoderes (semana 1 — no hagas nada más hasta que esto sea un hábito)
2. Playwright (semana 1 — cierra el ciclo más importante)
3. Obsidian (semana 2 — ambiental; configúralo y olvídalo)
4. Fixed Ticket (semana 2 — mayor ahorro de tiempo en backlogs existentes)
5. UI/UX ProMax (semana 3 — cuando tengas trabajo de UI pendiente)
6. El pack de marketing (semana 3 — cuando el producto existe y necesita promoción)
7. Telegram (semana 4 — cuando lo anterior es lo suficientemente rutinario para ejecutarse sin supervisión)
8. Skill Creator (continuo — cuando empieces a reconocer tus propios patrones, comienza a construir)

Dónde Esta Stack Se Queda Corta

Momento de honestidad intelectual, porque todo post de “instalé 8 skills y ahora soy un ingeniero 10x” está mintiendo.

La stack es específica del ecosistema Claude. Si tu equipo usa múltiples agentes de codificación o buscas portabilidad entre proveedores, algunas de estas herramientas (Superpowers, Skill Creator, los plugins específicos de Claude) generan dependencia. Las skills que siguen la especificación abierta de Agent Skills son más portables.

El costo de configuración es real. No la instalación — esa toma minutos. El costo está en el tiempo invertido en aprender las convenciones de cada skill, escribir los archivos design.md, conectar Sentry con tu Jira, estructurar el vault de Obsidian, producir los baseline de marketing. Llama a esto una semana de configuración enfocada antes de que la stack empiece a dar retornos. Si analizas esto para un sprint de 3 días, descártalo.

El número de 90% de reemplazo junior de Fixed Ticket es del creador, no una verdad universal. En mi base de código estaba más cerca de 60% al principio y llegó, tal vez, a 75% después de mejorar la disciplina en Jira y conectar bien Sentry. Aún así es enorme. Pero no es 90%, y desconfiaría de quien afirme que alcanza ese número desde el primer día.

Las skills de marketing dependen totalmente de una buena infraestructura analítica. Si GA4 no está bien conectado, los reportes de embudo serán basura. Si no tienes seguimiento de ingresos por canal, las recomendaciones de optimización serán meras conjeturas. El skill pack potencia una infraestructura correcta — no arregla una rota.

Playwright es inestable. Los navegadores reales son inestables. Cualquier configuración que dependa de ellos para gates de CI necesita lógica de reintento y captura de pantallas en caso de fallo, o terminarás dedicando los avances ganados a depurar falsos negativos.

Qué Pasa Si No Instalas Nada

Sigues programando “vibe”. Lanzas funcionalidades sin tests. Tu backlog de Jira crece más rápido de lo que logras cerrarlo. Tu página principal marca “Mejores Prácticas: 78” en Lighthouse y te repites que lo arreglarás el próximo trimestre. Tu baúl de Obsidian tiene 14 notas y crece a un ritmo más lento que el que pierdes contexto. Te envías mensajes de Telegram a ti mismo que jamás tomas en cuenta porque no hay ningún agente del otro lado.

Esa es la experiencia Claude Code que tienen la mayoría de los ingenieros en 2026. Es productiva. Es realmente más rápida que programar sin IA. Pero no es cualitativamente distinta de lo que un ingeniero experimentado podía hacer en 2023 con un buen autocompletado. La diferencia cualitativa la trae la pila de habilidades — el salto de “la IA me ayuda a programar más rápido” a “la IA lanza producto mientras yo duermo”.

Todavía recuerdo el momento que mencioné al inicio — la habilidad de Ticket Fijo lanzando un despliegue mientras yo miraba. Esa sensación incómoda quedó atrás. La sensación más persistente que lo reemplazó: cada hora que no tengo esta pila funcionando es una hora que hago trabajo que un agente bien configurado podría estar haciendo por mí. Esa es la lógica a la que siempre regreso. Si eres un ingeniero solo lanzando un producto en 2026, la pregunta no es si instalar una pila de habilidades. Es cuál y qué tan rápido.

Elige tres habilidades de esta lista esta semana. Superpowers, Playwright y Obsidian es mi recomendación si buscas el set inicial de mayor apalancamiento. Instálalas esta noche. Úsalas el lunes. Vuelve aquí en dos semanas y dime qué cambiarías.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portafolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de ciberseguridad): xcybersecurity.io