## Asset Header - **Asset ID:** MePB-BMF-Skills-DomainMetaFactory-v01 - **Version:** v01 - **Status:** Draft - **Owner:** Victor Heredia - **IntellBank:** IB-XX-Maestro - **Tipo:** MePB — MetaPlaybook - **Propósito:** MetaPlaybook de Skills — Domain MetaFactory para activos cognitivos ejecutables - **Última actualización:** 2026-04-11 --- # MetaPlaybook de Skills — Domain MetaFactory para activos cognitivos ejecutables ## MPB-SKILLS-DomainMetaFactory-v01 --- ## 0. Asset header **Asset ID:** MPB-SKILLS-DomainMetaFactory-v01 **Título:** MetaPlaybook de Skills — Domain MetaFactory (L2) **Versión:** v0.1 **Estado:** Draft **Owner:** Victor Heredia **Project Class:** BIG METAFACTORY (L2) **Tipo taxonómico:** Type D — Domain MetaFactory MetaPlaybook **Dominio:** Skills / Activos cognitivos ejecutables **Hereda de:** BMF-MPB-Kernel-v01 (L0), MPB-OF-MPB-MetaPlaybookOfMetaPlaybooks-v01 (L0.5), MFB-MPB-MetaFactoryBuilder-v01 (L1) **Fuentes externas:** NJ-Skills-Como-Infraestructura-Cognitiva-v01, Framework de diseño de skills de Anthropic (skill-creator) **Audiencia primaria:** Arquitectos de dominio, practitioners senior, operadores de SherpaX --- ## 0.1 Propósito Definir la arquitectura canónica para diseñar, construir, testear y desplegar skills dentro del ecosistema BigMetaFactory — tanto para uso interno (factorías y agentes del ecosistema) como para uso comercial (clientes de SherpaX, MONEX, y MasterPlaybooks). Este MetaPlaybook aplica tanto a organizaciones como a individuos. Un CEO construyendo su primer skill personal y un equipo de 50 personas desplegando skills como infraestructura organizacional siguen la misma arquitectura — lo que varía es la escala y los tiers de despliegue, no los principios de diseño. ## 0.2 Scope **In scope:** - Qué es un skill y qué no es un skill (definición canónica del dominio) - La arquitectura de un skill: estructura, componentes, principios de diseño - Los tiers de skills dentro de una organización o ecosistema personal - El proceso de diseño: de la señal a la versión operativa - Los estándares de calidad para skills agent-first - Los contratos de artefactos que un skill debe cumplir - Las interfaces con IntelliBank, BrainOS y EmpowerTeamX **Out of scope:** - Cómo se almacenan, indexan y recuperan skills como activos de inteligencia → pertenece al MetaPlaybook de IntelliBank (pendiente) - Cómo se opera una factoría de skills día a día (cadencia, WIP, defectos) → pertenece a un Type E Operations MetaPlaybook (L3) - Cómo se produce un skill específico para un cliente particular → pertenece a un Type F Production MetaPlaybook (L4) - Cómo se construyen MetaPlaybooks (el documento que estás leyendo sigue las reglas del Builder, pero no las define) → pertenece a MFB-MPB-MetaFactoryBuilder-v01 (L1) ## 0.3 Non-negotiables - Builder-grade language (sin marketing) - Separación de capas respetada - Todo skill debe poder ser invocado tanto por agentes como por humanos - Todo skill debe tener un contrato de output explícito - La descripción de un skill es una señal de routing, no una etiqueta - Herencia del Kernel es explícita — INV-01 a INV-07 aplican - Todo skill debe tener Asset ID, versión, y tier declarado (INV-06) - Todo skill debe ser registrado en el workspace del equipo o en IntelliBank — un skill sin registro es un skill huérfano --- ## 1. Orientación ### 1.1 Qué es un skill Un skill es **metodología codificada en formato ejecutable por agentes y legible por humanos**. Es una carpeta con un archivo de texto (SKILL.md) que contiene: metadata de routing (nombre y descripción) e instrucciones de metodología en markdown. Un skill no es un prompt. Un prompt es instrucción de uso único que se evapora cuando la conversación termina. Un skill es un activo persistente que acumula valor cada vez que se ejecuta, se corrige y se versiona. Los prompts son consumibles. Los skills son infraestructura. Un skill no es documentación. La documentación describe cómo algo funciona. Un skill prescribe cómo algo debe ejecutarse — con criterios de calidad, formatos de output, manejo de edge cases, y contratos que un agente puede evaluar sin intervención humana. Un skill no es un MetaPlaybook completo. Un MetaPlaybook es un sistema canónico de restricciones operativas con herencia, gobernanza, invariantes y contratos de artefactos formales. Un skill es una unidad ejecutable más ligera — puede vivir dentro de un MetaPlaybook o ser independiente, pero su complejidad es deliberadamente menor. > "Un skill codifica instrucciones en lenguaje natural que le dan a un LLM contexto para hacer algo útil con un conjunto particular de inputs de manera predecible." > — Nate Jones ### 1.2 Por qué los skills importan ahora Cuatro cambios convergentes han convertido los skills de configuración personal en infraestructura organizacional: **Los agentes son los principales invocadores.** Un agente puede hacer cientos de llamadas a skills en un solo run. Los skills diseñados solo para humanos fallan silenciosamente cuando un agente los invoca sin supervisión. Diseñar agent-first ya no es opcional — es el estándar. **Los skills son cross-platform.** El formato SKILL.md es un estándar abierto adoptado por Claude, ChatGPT, Copilot, Cursor, VS Code, Excel y PowerPoint. Un skill escrito una vez funciona en todas las plataformas. Eso lo convierte en el vehículo de infraestructura más portable que existe para codificar metodología. **Los skills acumulan donde los prompts se evaporan.** Cada sesión de trabajo que termina sin capturar la metodología en un skill es valor perdido. Cada skill que se corrige y versiona es valor compuesto. La pregunta correcta no es "¿vale la pena codificar esto?" sino "¿estoy dispuesto a perder esta metodología cada vez que la conversación termine?" **El gap de knowledge work es masivo.** Existen 500,000+ skills en marketplaces — casi todos para desarrollo de software. No hay bibliotecas compartidas de skills para análisis competitivo, revisión financiera, deal memos, metodología de consultoría, gestión de eventos, o criterio de CEO destilado. Ese es exactamente el territorio del ecosistema BMF. ### 1.3 El skill como unidad fundamental del IntelliBank Dentro del ecosistema BigMetaFactory, el skill ocupa una posición específica: ``` BrainOS (memoria del CEO) ↕ alimenta y consulta IntelliBank (banco de inteligencia curada) ↕ almacena, indexa, recupera Skills (unidades ejecutables de metodología) ↕ invocados por Agentes + Humanos (EmpowerTeamX, SherpaX, operadores) ↕ producen Activos (documentos, análisis, decisiones, entregables) ``` El skill es la unidad atómica de inteligencia ejecutable. Es lo que convierte el criterio almacenado en IntelliBank en acción concreta. Sin skills, IntelliBank es una biblioteca que nadie consulta. Sin IntelliBank, los skills no tienen la profundidad del criterio acumulado que los hace superiores a un template genérico. **Esta interdependencia es deliberada.** El MetaPlaybook de IntelliBank (pendiente de construcción) definirá cómo se almacenan, indexan, tagean y recuperan los skills como activos de inteligencia. Este MetaPlaybook define cómo se diseñan, construyen y validan. --- ## 2. Definiciones canónicas del dominio ### 2.1 Términos del dominio **Skill:** Carpeta con un archivo SKILL.md requerido que codifica metodología ejecutable. Puede incluir carpetas opcionales de references/, scripts/, y assets/. **Descripción (de un skill):** Campo de metadata de máximo 1,024 caracteres que funciona como señal de routing — el mecanismo por el cual un LLM decide si invocar el skill. Es la única parte del skill que está siempre en contexto. No es una etiqueta para humanos — es un contrato de activación para agentes. **Body (de un skill):** El cuerpo de instrucciones en markdown debajo del frontmatter. Contiene la metodología, los criterios de calidad, el formato de output, los edge cases, y los ejemplos. Se carga en contexto solo cuando el skill es invocado. **Progressive disclosure:** Arquitectura de carga en tres niveles: (1) metadata siempre en contexto (~100 palabras), (2) body del SKILL.md cuando dispara (<500 líneas ideal), (3) recursos bundled solo cuando se necesitan. Esta arquitectura existe para preservar el context window — un skill lean en metadata cuesta ~50-100 tokens, y 20 skills instalados cuestan ~1,500 tokens de system prompt. **Output contract:** Declaración explícita del formato exacto que el skill produce. Define campos, estructura, y tipos. Un skill sin output contract produce resultados que varían con cada invocación — variabilidad que se absorbe cuando un humano mira pero que rompe pipelines cuando un agente procesa. **Edge case handling:** Instrucciones explícitas para situaciones que un humano manejaría con "sentido común" pero que un agente no puede inferir: datos faltantes, inputs ambiguos, solicitudes parcialmente fuera de scope. Deben producir outputs determinísticos (códigos de error estructurados, no prosa). **Agent-first design:** Principio de diseño donde el invocador primario es un agente, no un humano. Implica: descripción como routing, output como contrato, edge cases determinísticos, y composabilidad obligatoria. **Composabilidad:** Propiedad de un skill cuyo output puede ser consumido directamente como input por otro skill sin necesidad de parsear prosa o interpretar formato. Un skill componible produce output que otro skill puede procesar automáticamente. **Specialist stack:** Patrón de producción donde una carpeta de skills se recorre secuencialmente para completar un trabajo complejo. Un skill convierte instrucciones vagas en spec, otro descompone la spec en tareas, otro ejecuta cada tarea, otro verifica calidad. ### 2.2 Términos heredados del Kernel (no redefinidos) Los siguientes términos se usan en este MetaPlaybook con su definición canónica del Kernel (BMF-MPB-Kernel-v01, Sección 2.1): Asset, Station, Run, Defect, Change, Control Plane, Invariant, Module, Pipeline, QA, Template, Instance. --- ## 3. Arquitectura de un skill ### 3.1 Estructura de carpeta ``` skill-name/ ├── SKILL.md ← requerido — metadata + metodología ├── references/ ← opcional — documentos que se cargan bajo demanda ├── scripts/ ← opcional — código ejecutable para lógica determinística └── assets/ ← opcional — templates, ejemplos, iconos, fonts ``` **SKILL.md** es el único archivo requerido. Todo lo demás es opcional y se carga solo cuando se necesita (progressive disclosure). ### 3.2 Estructura del SKILL.md ```yaml --- name: nombre-del-skill description: Descripción completa en una sola línea YAML. Incluye qué produce, cuándo debe disparar, frases trigger específicas, y formato de output esperado. Máximo 1,024 caracteres. Debe ser "pushy" — mejor sobre-disparar que sub-disparar. --- # Instrucciones de metodología ## Propósito Por qué este skill existe y qué problema resuelve. ## Metodología El razonamiento, frameworks, criterios de calidad y principios detrás de las decisiones — no solo los pasos. ## Formato de output Especificación exacta de la estructura del output. ## Edge cases Qué hacer cuando los inputs son incompletos, ambiguos o fuera de scope. ## Ejemplo Al menos un ejemplo concreto de output correcto. ``` ### 3.3 Los cinco componentes obligatorios del body Basado en el framework de Anthropic y validado por la práctica documentada por Nate Jones: **1. Razonamiento, no solo procedimientos.** El body debe explicar el *por qué* detrás de cada instrucción. Un skill que solo tiene pasos secuenciales es frágil — se rompe cuando encuentra un caso no previsto. Un skill con razonamiento permite que el LLM generalice dentro del dominio. La diferencia: - Frágil: "Paso 3: Agrega una sección de riesgos después de las recomendaciones." - Robusto: "Los riesgos siempre van después de las recomendaciones porque el lector necesita contexto de qué se propone antes de evaluar qué puede salir mal. Si las recomendaciones son condicionales, los riesgos deben mapearse a cada condición." **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 específicos. Si el output es ambiguo, cada invocador interpreta diferente, y la interpretación introduce variabilidad que se amplifica en cadena. **3. Edge cases explícitos.** Todo lo que un humano maneja con sentido común necesita escribirse. El formato recomendado es determinístico: ```markdown ## Edge cases Si el input proporciona menos de tres datos requeridos: → Output: {"error": "insufficient_data", "minimum_required": 3, "provided": N} → Detener ejecución. No intentar análisis con input insuficiente. Si el alcance de la solicitud es ambiguo: → Output: {"clarification_needed": "descripción de la ambigüedad"} → Detener ejecución. No adivinar el alcance. ``` **4. Al menos un ejemplo.** Los LLMs son excelentes haciendo pattern-matching desde ejemplos. Una ilustración concreta de output correcto mejora dramáticamente la consistencia. El ejemplo puede ir en el body o en un archivo separado en assets/. **5. Mantener el skill lean.** Un skill de 200 líneas que dispara confiablemente supera un skill de 800 líneas donde cada instrucción compite por atención. Guía de referencia: | Componente | Líneas recomendadas | Atención a invertir | |-----------|-------------------|-------------------| | Descripción (frontmatter) | 3-5 líneas YAML | 80% del esfuerzo de diseño | | Body completo | 100-150 líneas core, máx 500 | 20% restante | | Referencias | Sin límite (se cargan on-demand) | Según necesidad | Si el skill se acerca a 500 líneas, necesita mejor estructura, no más instrucciones. Mover material de referencia a references/ y linkear desde el body. ### 3.4 La descripción como señal de routing La descripción es el campo más importante del skill y donde la mayoría de los skills fallan. No es una etiqueta informativa — es el mecanismo de routing. **Arquitectura de carga:** Solo la metadata (nombre + descripción) está siempre en el contexto del LLM. El body completo, las referencias, los scripts — nada se carga hasta que el LLM decide que el skill es relevante. La descripción es la puerta de entrada. **Principios de una buena descripción:** - **Nombrar los tipos de output que produce.** No "ayuda con análisis" sino "produce memos de análisis competitivo estructurados." - **Incluir frases trigger reales.** Las frases que un humano o agente usarían al necesitar este skill: "analiza a nuestros competidores," "quiénes son los jugadores en este mercado," "arma un comp set." - **Declarar el formato de output.** "Retorna memo estructurado: definición de mercado, perfiles de jugadores, matriz de posicionamiento, implicaciones estratégicas." - **Ser "pushy."** Anthropic es explícito: los skills tienden a sub-disparar más que a sobre-disparar. Mejor que el skill se active de más (y se pueda refinar) a que nunca se active. **Restricción técnica crítica:** La descripción debe permanecer en una sola línea en YAML. Si un formateador de código la rompe en múltiples líneas, el skill desaparece silenciosamente. Sin error, sin indicación. El LLM reporta cero skills disponibles. **Ejemplo de descripción débil vs. fuerte:** ```yaml # Débil — demasiado vago, no dispara en nada específico description: Helps with competitive analysis. # Fuerte — tipos de output, frases trigger, formato declarado 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 with market definition, player profiles, positioning matrix, and strategic implications. ``` --- ## 4. Tiers de skills para organizaciones e individuos ### 4.1 El modelo de tres tiers Todo ecosistema de skills — ya sea una organización de 500 personas o un individuo con un negocio personal — se organiza en tres tiers. Los tiers determinan quién construye, quién usa, y cómo se despliega cada skill. ### Tier 1: Skills de estándares **Qué son:** Consistencia no negociable a través de todo el ecosistema. Voz de marca, reglas de formato, templates aprobados, requerimientos de compliance, convenciones de naming. **Quién los construye:** El arquitecto del ecosistema o el admin de equipo/empresa. **Cómo se despliegan:** Provisión centralizada — disponibles automáticamente para todos los usuarios y agentes. En Claude, los admins de Team y Enterprise los provisionan workspace-wide con un solo upload. **Test de pertenencia a Tier 1:** 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. **Ejemplos en el ecosistema BMF:** - Skill de voz de marca EmpowerLabs - Skill de nomenclatura de activos (convención BMF) - Skill de formato de Asset Header - Skill de QA binary (PASS/FAIL) **Para individuos:** Tu Tier 1 es tu identidad — cómo suenas, qué formato usan tus entregables, qué estándares no negocias. Es tu SKILL_PERSONAL_DNA. ### Tier 2: Skills de metodología **Qué son:** Cómo tu organización o tú realizas trabajo de alto valor de manera predecible. No es qué haces — es cómo piensas sobre lo que haces. El criterio que un junior no tiene y que un senior lleva años acumulando. **Quién los construye:** Los practitioners senior que realmente saben cómo se hace el trabajo bien. No el admin de empresa — el experto de dominio. **Cómo se despliegan:** Distribución por equipo o dominio. Disponibles para todos los que hacen ese tipo de trabajo. **Test de pertenencia a Tier 2:** ¿Le escribirías un documento de metodología a un nuevo empleado antes de pedirle que haga esto? ¿Le tomaría tres meses aprender a hacerlo a tu estándar sin ese documento? Si sí, es un Tier 2. **El método de construcción correcto:** No sentarse a articular la metodología desde la intención. Alimentar al LLM con 10-20 ejemplos del mejor trabajo real del practitioner y pedirle que reverse-enginee la metodología. Lo que crees que haces y lo que realmente haces son cosas diferentes — la expertise vive en decisiones que se volvieron automáticas e invisibles. > "Alimenta a Claude con 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." > — Nate Jones **Ejemplos en el ecosistema BMF:** - MetaPlaybook de Rebelocity convertido a skill (criterio de eventos premium) - Skill de SherpaX Ignition (onboarding de CEOs) - Skill de análisis de viabilidad de sponsors - Skill de diagnóstico WERK - Skill de High Ticket Sales **Para individuos:** Tus Tier 2 son tus superpoderes codificados — las cosas que haces mejor que nadie en tu dominio y que quieres poder replicar sin empezar de cero cada vez. **El valor comercial de Tier 2:** Un skill de Tier 2 con criterio destilado de practitioner senior es un activo vendible. Es lo que diferencia a un MetaPlaybook de un template genérico — tiene la profundidad de alguien que ha vivido el dominio. Un skill genérico dice "cómo hacer análisis competitivo." Un Tier 2 dice "cómo piensa sobre análisis competitivo alguien que ha hecho 200 en su industria específica — los filtros que solo se aprenden con la experiencia, los patrones que solo se ven después de años." ### Tier 3: Skills personales de workflow **Qué son:** Automatizaciones personales para el día a día. Cómo procesas tu inbox, cómo preparas tus reuniones, cómo haces tu revisión semanal. **Quién los construye:** El individuo, para su propio uso. **Cómo se despliegan:** Instalación personal. Pueden ser compartidos con el equipo cuando se demuestra su valor. **Advertencia:** No los mantengas solo en tu laptop. No sabes cuándo vas a estar de vacaciones, enfermo, o cuando alguien necesite usar tu herramienta y no pueda. **Prioridad de inversión:** La mayoría de las organizaciones obtienen 80% del valor de Tier 1 y Tier 2. Si estás construyendo skills personales pero no tienes estándares organizacionales ni skills de metodología, las prioridades están invertidas. ### 4.2 Mapa de priorización ``` PRIORIDAD DE CONSTRUCCIÓN Tier 1 (Estándares) ████████████████████ Primero — fundamento Tier 2 (Metodología) ████████████████████ Segundo — donde está el alpha Tier 3 (Personal) ██████████ Tercero — complemento ``` --- ## 5. Diseño agent-first: la asimetría de fallo ### 5.1 El problema que nadie ve Un skill diseñado para humanos y un skill diseñado para agentes no tienen el mismo estándar de calidad. La diferencia es una asimetría de fallo: **Con humano mirando:** Un skill vago cuesta 10-15% de calidad de output. El humano nota algo raro, redirige, se recupera. Costo pequeño. La recuperación es invisible — se siente como el ida y vuelta normal. **Con agente en pipeline:** El mismo skill vago no produce output ligeramente degradado. Produce output que el agente downstream trata como correcto, procesa, 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," completamente divorciado del skill roto que lo causó. **La asimetría:** - 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. ### 5.2 Los cuatro rediseños para agent-first **Rediseño 1: 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. No escribir la descripción para humanos que la leen en un panel de settings — escribirla para agentes que la escanean al procesar un goal. **Rediseño 2: Output como contrato no negociable.** Definir 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. El modo de fallo cuando no se hace: el agente llama el skill, recibe prosa conversacional, no puede extraer los datos estructurados para el siguiente paso, y o falla silenciosamente o alucina una estructura. **Rediseño 3: Edge cases con modos de fallo explícitos.** El agente downstream necesita saber exactamente cómo se ve el éxito y exactamente qué códigos de fallo esperar. Esto es manejo de edge cases determinístico — no "si falta información, nótalo en el análisis." **Rediseño 4: Composabilidad obligatoria.** Al escribir un skill, preguntar: si otro agente estuviera consumiendo este output, ¿qué necesitaría para hacer algo útil con él? Si la respuesta es "parsear prosa para extraer datos estructurados," hay un problema de composabilidad. Arreglar el formato de output antes de que el pipeline lo rompa. ### 5.3 Cuándo usar scripts en vez de lenguaje Las instrucciones en lenguaje natural 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, autenticación — poner esa lógica en un script en scripts/. Los LLMs siguen instrucciones en lenguaje "muy bien." Muy bien no es lo mismo que "siempre." Y para un gate que debe mantenerse, la diferencia importa. --- ## 6. El proceso de construcción de un skill ### 6.1 De la señal al skill operativo El proceso sigue el algoritmo cognitivo SEÑAL→CASCADA del ecosistema: ``` SEÑAL Un patrón recurrente, una frustración repetida, un workflow que se pierde con cada conversación ↓ CONEXIÓN ¿Qué frameworks aplican? ¿Qué criterio ya existe? ¿Hay ejemplos de output real? ↓ EXTRACCIÓN Reverse-engineer la metodología desde outputs reales (NO desde intenciones articuladas) ↓ DRAFTING Escribir SKILL.md v0.1: descripción + body + ejemplo ↓ TESTING Correr el skill con prompts vagos y realistas (NO con test cases ingenierizados) ↓ ITERACIÓN Corregir donde el output se desvíe. Versionar. Repetir hasta que sea confiable. ↓ VALIDACIÓN ¿Pasa los cuatro criterios agent-first? ¿Pasa QA PASS/FAIL del ecosistema? ↓ DESPLIEGUE Instalar en el tier correspondiente. Registrar en IntelliBank con badge ⬡ si aplica. ``` ### 6.2 El método de extracción de outputs Este es el método más efectivo para construir skills de Tier 2 — validado tanto por Nate Jones como por el framework de Anthropic: **Paso 1: Recolectar 10-20 ejemplos del mejor trabajo real.** No intenciones — outputs reales. Los mejores análisis, las mejores decisiones, los mejores entregables. Esto es el ground truth. **Paso 2: Pedirle al LLM que reverse-enginee la metodología.** "Aquí están 15 ejemplos de mi mejor trabajo en [dominio]. Identifica las decisiones que estoy tomando consistentemente. ¿Qué frameworks estoy usando implícitamente? ¿Qué criterios de calidad estoy aplicando? Reverse-enginea esto en un SKILL.md." **Paso 3: Entrevista de profundización.** El LLM te entrevista sobre las decisiones embebidas en los ejemplos. ¿Por qué este es mejor que aquel? ¿Qué habrías hecho diferente? ¿Cuándo este enfoque no aplica? **Paso 4: Generar SKILL.md v0.1** con: descripción optimizada para routing, body con razonamiento (no solo pasos), formato de output especificado, edge cases explícitos, y al menos un ejemplo. **Paso 5: Testear con prompts vagos.** No prompts ingenierizados — los prompts a medias que llegan en la vida real. "Hazme un análisis de la competencia." Si el skill produce output consistente con prompts vagos, está bien diseñado. ### 6.3 Testing cuantitativo (framework Anthropic) Para skills que se desplegarán en pipelines agénticos o como producto comercial, el testing cualitativo no es suficiente. El framework de Anthropic define un proceso de testing cuantitativo: **Evals:** Un conjunto de prompts de prueba realistas con assertions verificables. Se almacenan en evals/evals.json dentro del workspace del skill. **Benchmark comparativo:** Cada versión del skill se corre contra el mismo set de evals. Se compara: con skill vs. sin skill, y versión nueva vs. versión anterior. Métricas: pass_rate por assertion, tiempo de ejecución, tokens consumidos. **Optimización de descripción:** Un proceso automatizado que genera 20 queries de prueba (mitad should-trigger, mitad should-not-trigger), evalúa la tasa de disparo real, y propone mejoras iterativas a la descripción. Se ejecuta con un loop automatizado de hasta 5 iteraciones. **El estándar:** Un skill está listo para producción agéntica cuando pasa todas las assertions en el 90%+ de las ejecuciones, y su descripción dispara correctamente en el 85%+ de los queries de trigger y no dispara en el 90%+ de los queries de no-trigger. --- ## 7. Estaciones del pipeline de skills ### 7.1 Archetypes de estación | Estación | Propósito | Input | Output | Gate | |----------|-----------|-------|--------|------| | **Señal** | Identificar candidato a skill | Patrón recurrente, frustración, workflow que se pierde | Candidato declarado con justificación de las 3 señales (recurrente, requiere metodología, calidad depende de consistencia) | Las 3 señales presentes = PASS | | **Extracción** | Reverse-engineer metodología desde outputs reales | 10-20 ejemplos de mejor trabajo + entrevista de profundización | Metodología draft extraída, frameworks implícitos identificados, criterios de calidad destilados | Metodología refleja los outputs reales, no intenciones = PASS | | **Drafting** | Producir SKILL.md v0.1 | Metodología extraída + estándar de estructura (Sección 3) | SKILL.md completo con: descripción, body con 5 componentes, ejemplo | Los 5 componentes presentes + descripción en 1 línea YAML = PASS | | **Testing** | Validar funcionamiento con prompts realistas | SKILL.md v0.1 + set de 3-5 prompts vagos y realistas | Resultados de ejecución + evaluación cualitativa + evals.json si aplica | Output consistente y correcto en 80%+ de prompts = PASS | | **Hardening** | Aplicar rediseño agent-first | Skill testeado + feedback de testing | SKILL.md vN con: descripción como routing, output como contrato, edge cases determinísticos, composabilidad | Los 4 rediseños agent-first verificados = PASS | | **Despliegue** | Instalar en tier correspondiente y registrar | Skill hardened + decisión de tier (1/2/3) | Skill instalado + entrada en registro + badge IntelliBank ⬡ si validado | Instalación confirmada + registro actualizado = PASS | ### 7.2 Contratos de artefactos **Contrato de output del pipeline completo:** Todo skill que sale de este pipeline debe contener: - Asset ID (formato: SKILL-[DOMINIO]-[NOMBRE]-v[NN]) - SKILL.md con frontmatter válido (name + description en 1 línea) - Body con los 5 componentes obligatorios - Al menos 1 ejemplo de output correcto - Evaluación documentada (cualitativa mínimo, cuantitativa para producción agéntica) - Declaración de tier (1, 2, o 3) - Versión (vNN) --- ## 8. Módulos configurables ### 8.1 Template registry del dominio | Template | Propósito | Formato | Aplicado en | Referencia | |----------|-----------|---------|-------------|------------| | **SKILL.md Standard Structure** | Estructura base de todo SKILL.md con frontmatter + 5 componentes | Markdown | Estación Drafting | Sección 3.2 de este MPB | | **Output Contract (JSON)** | Template para contratos de output en formato JSON con campos, tipos, y error codes | JSON | Estación Hardening | Sección 5.2, Rediseño 2 | | **Output Contract (Markdown)** | Template para contratos de output en formato markdown con secciones obligatorias | Markdown | Estación Hardening | Sección 5.2, Rediseño 2 | | **Edge Case Handler** | Template para manejo determinístico de edge cases con structured error responses | Markdown | Estación Hardening | Sección 3.3, componente 3 | | **Eval Set (evals.json)** | Template para set de evaluaciones con prompts, expected outputs, y assertions | JSON | Estación Testing | Sección 6.3 | | **Trigger Eval Set** | Template de 20 queries (10 should-trigger + 10 should-not-trigger) para optimización de descripción | JSON | Estación Hardening | Sección 6.3 | | **Skill One-Pager** | Resumen ejecutivo de un skill: qué hace, para quién, qué produce, tier, estado | Markdown | Estación Despliegue | Adaptado del Ultra-Min del MFB-MPB | Los templates viven en una carpeta `templates/` dentro de la instancia de la factoría de skills. Son versionados y actualizados a través del ChangeLog protocol estándar del Kernel. ### 8.2 Módulos por instancia | Módulo | Propósito | Opciones | Default | |--------|-----------|----------|---------| | **Voice Pack** | Voz y tono del output del skill | Voz del CEO, voz de marca, voz técnica, voz neutral | Voz neutral | | **Domain Profile** | Dominio de aplicación | Publishing, Consulting, HR, Coaching, Eventos, Tech, Personal | Según uso | | **Output Format** | Formato del entregable | Markdown, JSON, YAML, documento Word, PDF | Markdown | | **Agent Stack** | Plataforma de ejecución | Claude (Cowork/Code), ChatGPT, Copilot, Cursor | Claude Cowork | | **QA Intensity** | Nivel de rigor en testing | Qualitativo (mínimo), Cuantitativo (producción), Full benchmark (agéntico) | Qualitativo | | **Tier de despliegue** | Alcance de distribución | Tier 1 (org-wide), Tier 2 (equipo/dominio), Tier 3 (personal) | Tier 3 | --- ## 9. Delegation contracts con Factory Builders (L1) ### 9.1 Contrato L2 → L1 (lo que este MetaPlaybook entrega al Builder) Cuando un Factory Builder (L1) construye una instancia de factoría de skills, este MetaPlaybook le entrega: | Artefacto entregado | Contenido | Formato | |---------------------|-----------|---------| | **Station archetypes** | Las 6 estaciones definidas en Sección 7.1 con inputs, outputs, y gates | Tabla markdown | | **Template pack** | Todos los templates del registry (Sección 8.1) | Carpeta templates/ | | **Module defaults** | Configuración default de los 6 módulos (Sección 8.2) | Tabla markdown | | **Artifact contract** | Contrato de output del pipeline (Sección 7.2) | Spec markdown | | **Anti-patterns** | Los 5 anti-patterns documentados (Sección 10) | Referencia a sección | ### 9.2 Contrato L1 → L2 (lo que el Builder debe entregar de vuelta) El Factory Builder debe producir y entregar: | Artefacto requerido | Criterio de aceptación | Gate | |---------------------|----------------------|------| | **Instancia configurada** | Estaciones instanciadas con módulos configurados para el contexto específico (CEO, equipo, dominio) | Todas las estaciones operativas = PASS | | **Checklists por estación** | Operativos, no conceptuales — un operador nuevo puede ejecutar sin preguntas | Operador diferente al Builder ejecuta 1 ciclo sin improvisación = PASS | | **Pilot run completado** | Al menos 1 skill producido end-to-end con evidencia | Skill pasa los 5 componentes obligatorios + gate de estación = PASS | | **Run log del piloto** | Run_ID, operador, fecha, outputs, QA result | Log completo y auditable = PASS | ### 9.3 Escalación y error handling - Si el Builder encuentra ambigüedad en los station archetypes → escalación a este MetaPlaybook (L2) para clarificación, no resolución autónoma - Si el Builder necesita un módulo no contemplado → propuesta documentada al Owner de este MetaPlaybook con justificación - Si el pilot run produce un FAIL sistémico → suspender build, documentar el defecto, escalar a L2 para determinar si es defecto de diseño (L2) o de instanciación (L1) ### 9.4 Versionado de la interfaz El contrato L2↔L1 está versionado junto con este MetaPlaybook. Cambios Track A (que afectan significado) en los station archetypes, templates, o artifact contracts requieren notificación a todos los Builders activos y re-validación de instancias afectadas. --- ## 10. Interfaces con otros componentes del ecosistema ### 10.1 Interface con IntelliBank **Este MetaPlaybook → IntelliBank:** - Todo skill que pasa QA puede ser candidato a recibir badge ⬡ IntelliBank - La validación y tagging de skills como activos de inteligencia es responsabilidad del MetaPlaybook de IntelliBank (pendiente) - Los skills de Tier 2 son los candidatos primarios para IntelliBank — representan criterio destilado de practitioner **IntelliBank → Este MetaPlaybook:** - La fase de Extracción consulta IntelliBank para identificar frameworks y criterio existente antes de reverse-engineer - Los skills heredan profundidad de los activos ya validados en IntelliBank - IntelliBank es lo que diferencia un skill genérico de un skill con criterio acumulado **MetaPlaybook pendiente recomendado:** MPB-INTELLIBANK-GestionActivosCognitivos-v01 — definiría cómo se almacenan, indexan, tagean (badge ⬡), recuperan contextualmente, y deprecan los activos de inteligencia, incluyendo skills. ### 9.2 Interface con BrainOS - BrainOS alimenta la fase de Extracción con el contexto y la historia del CEO - Los skills producidos alimentan BrainOS con metodología formalizada - La voz del CEO en BrainOS informa el Voice Pack del skill ### 9.3 Interface con EmpowerTeamX - Los agentes L1 de EmpowerTeamX son los principales invocadores agénticos de skills - Los skills de Tier 1 y Tier 2 deben estar disponibles para todos los agentes del equipo - El diseño agent-first (Sección 5) es especialmente crítico para skills invocados por EmpowerTeamX ### 9.4 Interface con SherpaX (producto comercial) - SherpaX Ignition incluye la construcción de los primeros skills del CEO como parte del onboarding - Los skills de Tier 2 del CEO se convierten en activos comerciales vendibles (MetaPlaybooks como producto) - La demo de SherpaX puede mostrar skills en acción como evidencia del valor de la continuidad cognitiva --- ## 11. QA de este MetaPlaybook ### 11.1 Distinción importante La Sección 6.3 define cómo se testean los **skills producidos** por este pipeline. Esta sección define cómo se evalúa **este MetaPlaybook mismo** como documento de gobernanza Type D. ### 11.2 QA hard gate para este MetaPlaybook **Structural QA (verificable por inspección):** - [ ] Todas las secciones universales requeridas presentes (Asset Header, Orientation, Canonical Definitions, Scope/Boundaries, QA Standard, Control Plane Pointers, Inheritance Declaration) - [ ] Todas las secciones Type D presentes (Domain declaration, Inheritance stack, Station archetypes, Artifact registry, Module registry, Template registry, Delegation contracts, QA model extensions, Control Plane hooks) - [ ] Asset Header completo con todos los campos obligatorios - [ ] Inheritance stack declarado explícitamente - [ ] Scope in/out definidos con ownership mapping **Semantic QA (requiere juicio):** - [ ] Sin cross-layer leakage (no hay procedimientos de ejecución L3 ni tácticas L4) - [ ] Definiciones no conflictúan con términos canónicos del Kernel - [ ] Invariantes se expresan como absolutos (sin lenguaje hedge) - [ ] Contenido prohibido para Type D está ausente - [ ] Overrides al Kernel son explícitos y justificados (ninguno en v0.1) ### 11.3 Definition of Done para este MetaPlaybook **Trainable:** Un arquitecto de dominio o practitioner senior que lea este MetaPlaybook puede entender qué es un skill, cómo se diseña, qué estándares debe cumplir, y cómo se clasifica por tier — sin necesidad de preguntar. **Enforceable:** Las reglas de este MetaPlaybook pueden producir decisiones PASS o FAIL sobre un skill concreto. Si un skill no tiene los 5 componentes obligatorios del body, es FAIL. Si la descripción no está en 1 línea YAML, es FAIL. Si no tiene output contract, es FAIL. --- ## 12. Anti-patterns ### 10.1 El skill-prompt **Patrón:** Un skill que es simplemente un prompt largo pegado en un archivo markdown. No tiene razonamiento, no tiene edge cases, no tiene output contract. Es un copy-paste con formato. **Por qué falla:** Hereda todos los problemas de los prompts (evaporación de contexto, variabilidad, no composable) sin ganar ninguna de las ventajas de los skills (acumulación, testing, versionado). **La cura:** Si el skill no tiene los 5 componentes obligatorios del body, no es un skill — es un prompt con pretensiones. Reescribir con razonamiento, output contract, y edge cases. ### 10.2 El skill-enciclopedia **Patrón:** Un skill de 800+ líneas que intenta cubrir todo el dominio. Cada instrucción compite por atención del LLM. El context window se llena de ruido. **Por qué falla:** Los LLMs procesan instrucciones con atención limitada. Instrucciones que compiten entre sí producen outputs impredecibles. Un skill largo no es un skill profundo — es un skill confundido. **La cura:** Dividir en skills más pequeños y componibles. Si el dominio es grande, usar el patrón specialist stack: varios skills lean que se invocan en secuencia. ### 10.3 El skill sin descripción **Patrón:** Una descripción genérica tipo "Helps with analysis" que no contiene frases trigger, no nombra outputs, y no declara formato. **Por qué falla:** El skill nunca dispara (demasiado vago) o dispara en todo (demasiado genérico). En contexto agéntico, el agente orquestador no puede hacer routing preciso. **La cura:** Invertir 80% del esfuerzo de diseño en la descripción. Incluir frases trigger reales, tipos de output, y formato esperado. ### 10.4 El skill humano-only **Patrón:** Un skill que funciona bien cuando un humano mira y corrige, pero que produce output ambiguo, no estructurado, o sin edge case handling cuando lo invoca un agente. **Por qué falla:** La asimetría de fallo (Sección 5.1). Lo que cuesta 10-15% con humano cuesta potencialmente 100% con agente. **La cura:** Aplicar los 4 rediseños agent-first (Sección 5.2) antes de desplegar a cualquier pipeline agéntico. ### 10.5 El skill huérfano **Patrón:** Skills que viven en descargas, en una carpeta personal, sin versión, sin registro, sin que nadie más pueda usarlos. **Por qué falla:** Cuando el creador no está disponible, el skill se pierde. No alimenta IntelliBank. No se beneficia del efecto compuesto. Es expertise que sigue atrapada en una persona — solo que ahora está atrapada en su laptop en vez de en su cabeza. **La cura:** Todo skill debe tener Asset ID, versión, y tier declarado. Los skills de Tier 2 deben estar registrados y accesibles para el equipo. Pensar sistémicamente: ¿quién necesita acceder a esta expertise cuando yo no esté? --- ## 13. Boundaries y fuera de scope ### 11.1 Lo que este MetaPlaybook no hace | Tema | Dónde pertenece | |------|----------------| | Cómo almacenar, indexar y recuperar skills como activos de inteligencia | MPB-INTELLIBANK (pendiente) | | Cómo operar una factoría de skills (cadencia semanal, WIP, defectos) | Type E — Operations MetaPlaybook (L3) | | Cómo producir un skill específico para un cliente particular | Type F — Production MetaPlaybook (L4) | | Las reglas constitucionales del ecosistema | BMF-MPB-Kernel-v01 (L0) | | Cómo clasificar MetaPlaybooks por tipo | MPB-OF-MPB (L0.5) | | Cómo construir MetaFactories | MFB-MPB-MetaFactoryBuilder-v01 (L1) | ### 11.2 MetaPlaybooks recomendados como siguiente paso **Prioridad 1:** MPB-INTELLIBANK-GestionActivosCognitivos-v01 — Completa el ciclo: este MetaPlaybook define cómo se construyen los skills; IntelliBank define cómo se almacenan, acumulan y hacen recuperables. Sin IntelliBank, los skills acumulan localmente pero no sistémicamente. **Prioridad 2:** Un Type E Operations MetaPlaybook para la factoría de skills — Define la cadencia semanal, los rituales de review, el proceso de version bump, y cómo se manejan defectos en skills en producción. --- ## 14. Declaración de herencia Este MetaPlaybook hereda y cumple: - **BMF-MPB-Kernel-v01 (L0):** Todas las invariantes INV-01 a INV-07 aplican. En particular: INV-01 (pipeline requerido — Sección 7), INV-03 (QA puede fallar — gates en Sección 7.1), INV-06 (identidad de asset requerida — Sección 7.2). - **MPB-OF-MPB (L0.5):** Clasificado como Type D, Layer L2, Domain: Skills/Activos Cognitivos, Function: MetaFactory, Audience: Arquitecto/Practitioner, Risk: Medium. - **MFB-MPB-MetaFactoryBuilder-v01 (L1):** Sigue el proceso Thinking→Design→Build→Operate. Este documento es el output de la fase Design. --- *Asset ID: MPB-SKILLS-DomainMetaFactory-v01 | Version: v0.1 | Status: Draft | Owner: Victor Heredia* *Fuentes: NJ-Skills-Como-Infraestructura-Cognitiva-v01 + Framework Anthropic (skill-creator) + Arquitectura BMF*