## Asset Header - **Asset ID:** PP-XNJ-Skills-Como-Infraestructura-Cognitiva-v01 - **Version:** v01 - **Status:** Draft - **Owner:** Victor Heredia - **IntellBank:** IB-BVH-Publications - **Tipo:** PP — Paper/Publication - **Propósito:** Skills como infraestructura cognitiva — síntesis del marco de Nate Jones - **Última actualización:** 2026-04-11 --- # Skills como infraestructura cognitiva — síntesis del marco de Nate Jones ## NJ-Skills-Como-Infraestructura-Cognitiva-v01 --- **Asset ID:** NJ-Skills-Como-Infraestructura-Cognitiva-v01 **Tipo:** Síntesis de fuente externa — documento de referencia **Fuente:** Nate Jones — Video "Agent Readable Skills" + artículo Substack (marzo 2026) **Fecha de síntesis:** 2026-03-30 **Sintetizado por:** Jay (SherpaX de Victor Heredia) **Estado:** v01 — síntesis completa, pendiente validación --- ## 1. La tesis central En octubre de 2025, Anthropic lanzó los skills como funcionalidad nativa de Claude. Seis meses después, lo que empezó como un atajo personal de prompting se convirtió en algo fundamentalmente diferente: **infraestructura organizacional cross-platform para trabajo predecible a escala**. Un skill, en su forma más básica, es una carpeta con un archivo de texto (`SKILL.md`). Tiene dos partes: metadata YAML al inicio (nombre y descripción) y un cuerpo de instrucciones en markdown debajo. Es deliberadamente simple — y esa simplicidad es su poder. > "Un skill es una carpeta con un archivo de texto. Eso es todo. Codifica instrucciones en inglés llano que le dan a un LLM contexto para hacer algo útil con un conjunto particular de inputs de manera predecible." > — Nate Jones La estructura mínima: ``` competitive-analysis/ ├── SKILL.md ← requerido; esto es todo el skill ├── references/ ← opcional; docs que Claude carga cuando necesita ├── scripts/ ← opcional; código ejecutable └── assets/ ← opcional; templates, ejemplos ``` El frontmatter tiene dos campos requeridos: ```yaml --- name: competitive-analysis description: Qué hace este skill y cuándo Claude debería usarlo. --- ``` Todo debajo del cierre `---` son las instrucciones. Esa es la estructura completa. --- ## 2. Los cuatro cambios que rompieron el marco de octubre ### Cambio 1: De configuración personal a infraestructura organizacional En octubre, un skill era algo que construías para ti. Lo escribías, lo usabas, te ahorrabas setup. Ahora los administradores de equipo y empresa despliegan skills en toda la organización con un solo upload. Son versionados, aparecen en la barra lateral, y son invocables dentro de Excel, PowerPoint, Claude, y Copilot. **Lo que esto significa:** La metodología de una organización ya no vive en la cabeza de las personas. Vive en archivos que son legibles tanto para agentes como para humanos, y se despliegan como infraestructura. ### Cambio 2: Los agentes son ahora los principales invocadores de skills En octubre, los humanos eran quienes llamaban skills — quizás algunos por conversación. Ahora los agentes hacen cientos de llamadas a skills en un solo run. La matemática simplemente no funciona para humanos. Los skills necesitan diseñarse pensando primero en agentes. **Lo que esto significa:** Los skills necesitan ser más precisos, más predecibles, y más componibles — porque cuando un agente los invoca mal, no hay humano mirando para corregir en tiempo real. ### Cambio 3: Los skills no son solo para desarrolladores Los skills no están pensados para vivir solo en la terminal o ejecutar código. Son para el resto de la vida profesional y personal. Anthropic y Microsoft tienen una alianza para llevar skills a Copilot. OpenAI los adoptó. Es ahora un estándar abierto cross-industria. **Lo que esto significa:** Cualquier persona — no solo ingenieros — puede codificar su metodología en un skill y tener un agente que la ejecute con consistencia. ### Cambio 4: Skills como estándar cross-industria cambia la dinámica del alpha Con 500,000 skills corriendo en el marketplace de SkillsMP, y el formato adoptado por Claude, ChatGPT, Copilot, Cursor, GitHub, y VS Code, los skills se convirtieron en un vehículo de infraestructura común. > "Estamos descubriendo el manual de instrucciones juntos. Con los LLMs, las mejores prácticas son descubribles, no conocidas." > — Nate Jones La gente comparte skills como quien intercambia tarjetas de baseball. El alpha no está en mantener skills cerrados — está en el efecto compuesto de mejorarlos colectivamente. --- ## 3. Skills acumulan, los prompts se evaporan Esta es quizás la idea más poderosa del marco de Nate Jones, y merece atención plena. > "Piensa en tus mejores sesiones de trabajo con IA. La sesión donde obtuviste un análisis competitivo excepcional porque explicaste tu framework en detalle. Ese trabajo fue bueno — y luego la conversación terminó, y nada de eso se transfirió hacia adelante. La próxima vez que necesitaste lo mismo, empezaste de cero. Tu mejor trabajo de prompting se está evaporando ahora mismo." **Skills son cómo tus victorias se acumulan en vez de desaparecer.** Cada vez que obtienes un gran resultado, el enfoque que lo produjo tiene valor. Un skill es lo que captura ese valor y lo hace reutilizable: por ti, por tu equipo, por un agente ejecutando el mismo workflow a medianoche. La pregunta correcta no es "¿es esta tarea lo suficientemente importante para invertir tiempo codificándola?" Es: **"¿estoy dispuesto a perder esta metodología cada vez que la conversación termine?"** ### Tres señales de que algo pertenece en un skill Las tres deben cumplirse: 1. **Es recurrente.** Un uso es una tarea. Dos pueden ser coincidencia. Tres es un patrón. Un patrón pertenece en un archivo. 2. **Requiere metodología.** Algunas tareas se resuelven con un prompt directo. Otras requieren un enfoque: frameworks, secuencias de decisión, criterios de calidad específicos del dominio. La prueba: ¿le escribirías un documento de metodología a un nuevo empleado antes de pedirle que haga esto? Si sí, el documento es un skill. 3. **La calidad depende de la consistencia.** El prompting ad-hoc produce una distribución amplia de calidad de output. Los skills elevan y fijan el piso. Si la variabilidad te está costando algo, es candidato a skill. ### Los candidatos de mayor ROI en knowledge work - Cualquier tipo de documento que produzcas en cadencia: memos para clientes, actualizaciones de board, briefs de deals - Cualquier análisis con un estándar de calidad consistente: inteligencia competitiva, revisiones de modelo, análisis de pipeline - Cualquier proceso de revisión de calidad con criterios específicos: revisión de contratos, revisión de decks, code review - Cualquier workflow donde "la forma correcta de hacer esto aquí" le toma a una persona nueva tres meses para internalizar --- ## 4. El patrón del specialist stack El patrón de producción más común en Claude ahora es lo que Nate llama el **specialist stack**: un desarrollador deja caer una carpeta de skills en un proyecto. Un skill convierte instrucciones vagas en un PRD. Otro descompone el PRD en issues de GitHub. Otro escribe los tests. Y así sucesivamente. El concepto: el skill absorbe la complejidad del prompting. El agente no necesita dirección especialista porque la dirección especialista está en el archivo. ### El caso del GP de bienes raíces @TXpaintbrush en X construyó el mismo patrón para operaciones de su negocio inmobiliario. Tiene más de **50,000 líneas de skills** a través de 50 repositorios cubriendo: estandarización de rent rolls, análisis de comparables, manejo de cash flow, protocolos de handoff entre miembros del equipo. Lo bello del ejemplo: sí, el agente puede correr y llamar esos skills de manera predecible. Pero resulta que escribir todo esto también ayuda a los humanos. Cuando incorporas a alguien nuevo, hay una capa de contexto fantástica para que entiendan qué está pasando. **La metodología ya no vive en la mente de alguien. Vive en un repositorio.** ### El patrón del orquestador Equipos más sofisticados están construyendo skills orquestadores: un skill analiza cualquier solicitud entrante y luego genera sub-agentes para atenderla basándose en skills que aprende a llamar desde ese skill maestro. Investigación, código, UI, documentación — una sola solicitud de alto nivel se rutea a múltiples sub-agentes de manera predecible. --- ## 5. Cómo construir un skill que funcione (marzo 2026) ### 5.1 La descripción: donde la mayoría de los skills mueren **La descripción es el campo más importante del skill.** No es una etiqueta para humanos — es el mecanismo por el cual Claude rutea hacia tu skill. Es la única parte que siempre está presente, siempre evaluada. Solo el frontmatter está siempre en el contexto de Claude. La descripción (máximo 1,024 caracteres) se carga en el system prompt al inicio para cada skill instalado. El cuerpo completo, las referencias, los scripts — nada de eso se carga hasta que Claude decide que el skill es relevante. Anthropic lo llama **progressive disclosure**: metadata primero, instrucciones completas solo si hay match, archivos de soporte solo cuando se necesitan específicamente. **Una mala descripción:** ```yaml description: Helps with competitive analysis. ``` Demasiado vago. No dispara en nada específico o dispara en todo tangencialmente relacionado. **Una buena descripción:** ```yaml description: Produces structured competitive analysis memos for product, market, and investment research. Use when asked to analyze competitors, assess market position, write a competitive landscape, or evaluate competitive dynamics. Applies to "analyze our competitors," "who are the players in X market," "build a comp set," or "how do we stack up against Y." Returns structured memo: market definition, player profiles, positioning matrix, strategic implications. ``` **Qué cambió:** tipos de documento especificados, frameworks de análisis nombrados, frases trigger reales incluidas, formato de output declarado. La guía de Anthropic es explícita: "Los skills tienden a sub-disparar más que a sobre-disparar. Haz la descripción un poco agresiva." **Gotcha técnico crítico:** La descripción debe ser una sola línea en YAML. Si un formateador de código la rompe en múltiples líneas, el skill desaparece silenciosamente. Claude reporta cero skills disponibles — sin error, sin indicación de qué pasó. ### 5.2 El cuerpo de metodología: cinco elementos necesarios Después del frontmatter, el cuerpo de tu SKILL.md es donde vive tu metodología. Mantenerlo bajo 500 líneas — no es un límite duro, pero es una función de fuerza. Si te acercas, necesitas mejor estructura, no más instrucciones. **1. Razonamiento, no solo pasos.** > "Dale a Claude tus frameworks, tus criterios de calidad, los principios detrás de tus decisiones. Un skill que solo tiene procedimientos lineales es un skill muy frágil — se va a romper cuando encuentre un caso que no reconoce. El razonamiento ayuda a Claude a generalizar en el dominio." **2. Formato de output especificado.** No "produce un resumen." Un documento markdown con estas secciones exactas en este orden. Un objeto JSON con estos campos. Si el output es ambiguo, cada invocador — humano o agente — tiene que interpretarlo, y la interpretación introduce variabilidad. **3. Edge cases explícitos.** Todo lo que un humano maneja con sentido común, necesita escribirse. ¿Qué pasa cuando faltan datos requeridos? ¿Cuando el input es ambiguo? ¿Cuando la solicitud está parcialmente fuera de alcance? **4. Al menos un ejemplo.** Claude es bueno haciendo pattern-matching desde ejemplos. Una ilustración concreta de cómo se ve un buen output mejora dramáticamente la consistencia. **5. Mantenerlo lean.** Un skill corto que dispara confiablemente va a superar un skill largo con instrucciones que compiten entre sí. Mover material de referencia a `references/` y linkear. Mantener el archivo principal apretado. > "No deberías bajo la mayoría de las circunstancias estar gastando más de 100 o 150 líneas en tu archivo core de skills. Invierte 80% de tu atención en el campo de descripción para asegurar que dispare, y el otro 20% en ser muy claro con el razonamiento general." ### 5.3 Construir desde tus outputs, no desde tus intenciones El consejo convencional es sentarte y articular tu metodología. Eso produce skills mediocres, porque **lo que crees que haces y lo que realmente haces son cosas diferentes**. La experiencia vive en decisiones que has tomado tantas veces que se volvieron automáticas e invisibles. No puedes articular lo que no puedes ver. **El mejor enfoque:** alimenta a Claude con 10 a 20 ejemplos de tu mejor trabajo real — tu mejor análisis competitivo, tu mejor brief de deal, tu mejor revisión de modelo — y pídele que reverse-enginee la metodología en un SKILL.md. Haz que Claude te entreviste sobre las decisiones embebidas en esos ejemplos. ¿Qué decisiones estás tomando? ¿Por qué? ¿Qué hace que este sea mejor que aquel? --- ## 6. La asimetría de fallo que nadie menciona Esta sección es crítica y cambia todo el cálculo costo-beneficio. **Un skill vago en una sesión dirigida por humanos** te cuesta quizás 10-15% de calidad de output. El humano nota que algo no está bien, redirige, se recupera. Costo pequeño. Esa recuperación es invisible — se siente como el ida y vuelta normal de trabajar con IA. **El mismo skill vago en un pipeline de agentes** no produce output ligeramente degradado. Produce output que el agente downstream trata como correcto, procesa más, y pasa al siguiente paso. El error no se hace visible donde se introdujo. Se hace visible seis pasos después, luciendo como un fallo del modelo, en una forma completamente divorciada del skill roto que lo causó. **La asimetría de costo:** - Invocador humano: 10-15% de degradación de calidad - Invocador agente: potencial 100% de fallo en cadena > "Los skills que has probado en sesiones interactivas sistemáticamente subestiman tu tasa de fallo en contextos agénticos, porque el humano en el loop absorbió los fallos. Cuando remueves al humano, esos fallos se propagan." ### Cuatro rediseños para invocadores agentes **1. La descripción como tabla de routing.** Cada frase trigger que un agente podría generar cuando necesita este tipo de skill debe aparecer en la descripción. Tratar la descripción como una entrada de tabla de routing, no como una etiqueta. **2. Formato de output no negociable.** Definirlo completamente. No "una respuesta estructurada." Un objeto JSON con estos campos específicos. No "un resumen." Un documento markdown con estas secciones en este orden, nada más. Ejemplo de manejo de edge cases estructurado: ```markdown ## Output Format Return a JSON object with exactly these fields: { "market_definition": "string, 2-3 sentences", "players": [{"name": "string", "tier": "primary|secondary", "differentiator": "string"}], "strategic_implications": ["string", "string", "string"] } ## Edge Cases If the input provides fewer than three named competitors, output: {"error": "insufficient_data", "minimum_required": 3, "provided": N} and stop. Do not attempt analysis with insufficient input. ``` **3. Composabilidad obligatoria.** Los agentes encadenan skills. El output de un skill de investigación alimenta el input de un skill de análisis que alimenta un skill de formato. Cada handoff requiere output limpio y predecible del paso anterior. **4. Para validaciones críticas, usar scripts, no lenguaje.** Las instrucciones en lenguaje son probabilísticas. Los scripts son determinísticos. Si un paso absolutamente debe tener éxito antes de que el siguiente corra — validación de campos requeridos, verificación de tipo de datos — poner esa lógica en un script en `scripts/`. > "Las instrucciones en lenguaje se respetan muy bien. Muy bien no es lo mismo que siempre. Y para un gate que debe mantenerse, la diferencia importa." --- ## 7. Arquitectura de tres tiers para equipos En un mundo donde los equipos están compuestos por una mezcla de inteligencia artificial y humanos, los skills funcionan como **contexto inmediatamente accionable**. ### Tier 1: Skills estándar Consistencia no negociable a través de la organización: voz de marca, reglas de formato, templates aprobados, requerimientos de compliance. Estos pertenecen en el panel de configuración organizacional hoy. > "Si tus outputs de IA no siguen todos los mismos estándares, no tienes estándares. Tienes diferentes personas aproximando estándares de manera diferente sin garantía de consistencia." ### Tier 2: Skills de metodología Cómo tu organización o equipo realiza trabajo de alto valor. Cómo estructuras los entregables a clientes. Cómo los practitioners senior realizan su trabajo. Lo que hace que su craft funcione. > "Piensa en los skills de Tier 2 así: ¿cuáles son las cosas que querrías comunicar a una nueva contratación que les tomaría meses aprender de otra manera?" Estos son los skills que valen 50 horas construir porque se ejecutan 10,000 veces. No es algo que un admin de empresa pueda desplegar fácilmente — este conocimiento vive dentro de las cabezas de practitioners senior en equipos individuales. **Necesita salir de esas cabezas y entrar en algo compartible.** ### Tier 3: Skills personales de workflow Cosas que hacemos bajo el escritorio para nuestro día a día. Advertencia: será tentador mantenerlos solo en tu laptop. Pero no sabes cuándo vas a estar de vacaciones, enfermo, o algo va a pasar en el trabajo y desearás que alguien pudiera usar la herramienta como la diseñaste. **Prioridad organizacional:** La mayoría de las organizaciones obtienen 80% del valor de Tier 1 y Tier 2. Si tu equipo está construyendo skills personales pero no tiene estándares organizacionales ni skills de metodología, **tienes las prioridades invertidas**. ### El efecto compuesto Cada skill de metodología eleva el piso de calidad para todos los que lo usan, permanentemente, hasta que alguien encuentra un mejor enfoque y actualiza el archivo. Cuando la actualización ocurre, se distribuye a todos inmediatamente — incluyendo cada agente corriendo el skill en pipelines automatizados. > "No estás capturando expertise una vez. Estás construyendo un sistema que mejora y propaga mejoras instantáneamente a todos lados." --- ## 8. El gap en el ecosistema de 500,000 skills La abrumadora mayoría de los 500,000 skills existentes son herramientas para desarrolladores: TypeScript, Angular, Git, optimización de queries. Tiene sentido históricamente — los desarrolladores adoptaron skills primero porque Claude Code es donde el formato se lanzó. **Pero deja un gap masivo:** > "No hay una biblioteca compartida de skills para knowledge work. No para análisis competitivo. No para revisión de modelos financieros. No para deal memos o entregables a clientes o revisión de contratos legales o metodología de marketing." Anthropic lanzó un repo open-source de knowledge-work-plugins en enero 2026 con 11 plugins iniciales cubriendo ventas, finanzas, legal, producto y operaciones. Es un punto de partida, no una biblioteca. **Lo que falta:** los skills de metodología de dominio específico que codifican cómo un tipo particular de organización hace un tipo específico de trabajo a un estándar alto. Esos todavía no existen. Simon Willison escribió en octubre que los skills iban a ser "quizás un deal más grande que MCP." Porque son solo archivos de texto que viajan a todos lados. Porque la metodología que codifican es más durable que cualquier integración. --- ## 9. Pasos accionables por nivel ### Si tienes 30 minutos Revisa tus últimas 30 conversaciones con IA. ¿Qué prompts escribiste por tercera vez este mes? Ese es tu backlog. Elige el que tiene mayor varianza de calidad y constrúyelo primero. ### Si tienes 2 horas Usa el método de extracción de outputs. Recolecta 10-20 ejemplos de tu mejor trabajo en ese dominio. Alimenta a Claude, pídele que identifique las decisiones que estás tomando y que reverse-enginee un SKILL.md. Prueba el resultado con prompts vagos y realistas. Corrige donde el output se desvíe. ### Si despliegas a agentes Audita cada skill en tu pipeline contra los cuatro criterios: - ¿La descripción contiene las frases que un agente orquestador generaría? - ¿El formato de output está completamente especificado? - ¿Los edge cases son explícitos con modos de fallo definidos? - ¿El output es componible — podría otro skill consumirlo limpiamente? ### Si manejas un equipo Identifica tu backlog de Tier 2. Tres cosas que una persona nueva necesita tres meses para aprender a hacer a tu estándar. Haz que tus seniors construyan skills desde sus outputs reales, no desde sus intenciones articuladas. ### Si lideras una organización La pregunta ya no es "¿deberíamos usar skills?" sino "¿cuáles de nuestros skills son infraestructura organizacional que necesita versionado y gobernanza, y cuáles son configuración personal?" --- ## 10. La idea final: el ritmo es el punto Cinco meses. Ese es el timeline completo desde feature interno hasta estándar cross-platform hasta infraestructura organizacional corriendo en Excel, PowerPoint y M365. Las organizaciones construyendo bibliotecas de skills ahora tendrán ventajas compuestas sobre las que no — porque sus agentes, en cada superficie, cada pipeline, cada plataforma, corren sobre metodología institucional codificada. Los agentes de todos los demás están infiriendo estándares del contexto que la tarea provea. > "Tu metodología se está evaporando ahora mismo — cada sesión, cada conversación que termina y se lleva tu mejor trabajo con ella. Los skills son cómo se acumula en vez de evaporarse." > > "El formato es aburrido. El apalancamiento no lo es." > — Nate Jones --- *NJ-Skills-Como-Infraestructura-Cognitiva-v01 · Síntesis de fuente externa · 2026-03-30* *Fuente: Nate Jones — Video "Agent Readable Skills" + Substack · Sintetizado por Jay para Victor Heredia*