🫥 Costo de contexto de la skill

En el módulo 3.1 viste qué es una skill y que tiene un frontmatter con una description. Ahora viene la parte que casi nadie nota: en palabras de Matt Pocock, "cada skill filtra tu" description en la ventana de contexto". Es decir: en cuanto instalas una skill, la frase que la describe empieza a ocupar espacio en la ventana de contexto del modelo, en cada turno, uses esa skill o no.

¿Por qué se filtra? Porque así es como el modelo descubre que la skill existe. Para que decida "ah, para esta tarea podría usar la skill X", tiene que haber leído antes la descripción de X. Entonces el sistema inyecta todas las descripciones desde el principio. El por qué importa: la ventana de contexto es finita y se mide en tokens; cada description filtrada deja menos espacio para lo que de verdad importa (tu código, tu pedido). El error común es instalar una skill «porque es bueno tenerla»: cada una cobra un peaje silencioso, aunque esté inactiva.

Una skill filtra muy poco — quizá una o dos frases. «Entonces, ¿cuál es el problema?», preguntas. El problema es la multiplicación. Como dice Pocock directamente: "100 skills = 100 descripciones en el contexto". Suma eso a tu CLAUDE.md, a los archivos abiertos y al historial de la conversación, y de repente ya se habrá consumido buena parte de la ventana incluso antes antes de que el modelo empiece a pensar en tu tarea.

Esto se conecta directamente con el concepto de bloat de contexto. Cuando la ventana se llena, aparecen dos efectos negativos: se vuelve más caro (pagas por tokens) y se vuelve más tonto — con muchas cosas compitiendo por la atención, el modelo «se pierde» y razona peor sobre lo que realmente importa. El error común aquí está la mentalidad de coleccionista: «instalé 80 skills del repositorio, ahora soy productivo». En la práctica, solo llenaste la mesa de reglas. Menos skills visibles suele dar mejores resultados.

Aquí está el botón que resuelve el problema de los temas 1 y 2. En el frontmatter de la skill existe la clave disable-model-invocation: true. Cuando la activas, pasan dos cosas, en palabras de Pocock: "solo el usuario invoca [la skill], y la description NO se filtra". En palabras sencillas: (1) el el modelo ya no puede llamar esa skill por tu cuenta — se convierte en una procedure pura, activada solo por ti; y (2) como el modelo ya no necesita «saber» de la skill para decidir usarla, la description deja de filtrar en el contexto. Recuperas ese espacio.

El ejemplo que da Pocock es la skill "engineering zoom out": es un procedimiento suyo, que invoca cuando quiere; no tiene sentido que el modelo decida usarlo por sí solo, así que lo oculta con disable-model-invocation: true. O porqué es directo: cambias la «conveniencia» de que el modelo elija la skill automáticamente por contexto más limpio — y, en el caso de los procedures, de todos modos ibas a iniciar la skill manualmente. El error común es conectar esto a una ability (una skill cuyo valor está en que el modelo la active por sí solo, como "coding standards"): así rompes precisamente lo que la hacía útil.

---
name: engineering-zoom-out
description: Sai do detalhe e reavalia a arquitetura geral antes de continuar.
# Esconde a skill do modelo: SO o humano invoca (/engineering-zoom-out).
# Efeito colateral bom: a description acima NAO vaza na janela de contexto.
disable-model-invocation: true
---

# Engineering zoom out

Quando eu te chamar, pare de mexer no codigo linha a linha e:
1. Resuma em 3 bullets o que o sistema faz hoje.
2. Aponte a decisao de arquitetura mais arriscada em aberto.
3. Liste 2 caminhos possiveis (trade-offs) e recomende um.
So depois que eu aprovar, volte a escrever codigo.

Ocultar descriptions no es solo un ahorro técnico: es una filosofía de control. Pocock dice explícitamente: él "oculta la mayoría de las descripciones de la IA y mantiene el conocimiento en manos del humano". La frase suya que lo resume todo: "I know my skills, I don't want to delegate my thinking" — conozco mis skills, no quiero delegar mi pensamiento. Él decide qué procedure ejecutar, no el modelo.

Por eso Pocock prefiere procedures a abilities (viste los dos tipos en el 3.1): quieres estar al volante. Aquí hay una diferencia interesante entre escuelas: el proyecto Superpowers ("Obra") prefiere lo contrario: dejar que el el modelo al mando, eligiendo skills por su cuenta. Ninguno está "mal"; son apuestas diferentes. El error común de quien está empezando es copiar a ciegas la configuración de otra persona sin darse cuenta de que incorpora una filosofía. Pregúntate: ¿quiero que la IA elija por mí o quiero elegir yo? La respuesta cambia cuáles skills ocultas.

Si la description se filtra y cada palabra cuesta, la conclusión práctica es: escribe skills concisas. Esto tiene dos caras. Primero, la description corta: debe ser solo lo suficiente para que el modelo (o tú) sepa cuándo sirve la skill; las frases gigantes solo aumentan la filtración. La propia grill-me que verás más adelante es elogiada por ser "unreasonably effective" en apenas 4-5 frases: el poder no se mide por el tamaño.

Segunda cara: evita el exceso de instrucciones dentro del cuerpo de la skill. Aquí va la advertencia central de Pocock sobre el contexto — "todo el mundo llena su ventana de contexto con demasiadas cosas". Una skill concisa hace que algo muy; si se está convirtiendo en un monstruo de diez responsabilidades, divídelo en skills más pequeñas y encadenables (como grill-me → two-PRD → to-issues, que ves en el 3.6). El error común es tratar la skill como un "depósito de todo lo que sé sobre el tema". Una skill no es una wiki; es un procedimiento preciso.

Al cerrar el módulo: convierte todo esto en un hábito. De vez en cuando, haz una auditoría de contexto de tus skills. La regla práctica es la del engineering zoom out: si es una procedure (siempre la invocas manualmente), ocúltala con disable-model-invocation: true y recupere el contexto; si es una ability de valor real (el modelo tiene que encontrarla por sí solo), déjala visible, pero entonces esfuérzate en escribir una description breve. El error común es no revisar nunca: instalas, te olvidas y, seis meses después, tienes 60 descriptions filtrándose sin recordar ni la mitad.

Usa la lista de verificación de abajo para depurar tus skills. Aplica, en orden, todo lo que vimos: identificar lo que se filtra, decidir por cada skill y medir el resultado. Cópiala dentro de tu proyecto.

FAXINA DE SKILLS - toda skill instalada vaza sua description.
Para CADA skill, decida:
[ ] EU USO? Se nao uso ha semanas -> desinstale (para de vazar de vez).
[ ] PROCEDURE (eu sempre invoco na mao)? -> disable-model-invocation: true
    (esconde do modelo + a description deixa de vazar)
[ ] ABILITY (o modelo precisa achar sozinho, ex.: coding standards)?
    -> deixe visivel, MAS encurte a description ao minimo necessario.
[ ] DESCRIPTION enxuta? Corte tudo que nao ajuda a decidir "quando usar".
[ ] CORPO enxuto? 1 skill = 1 coisa. Monstro de 10 responsabilidades? quebre.
Meta: menos descriptions vazadas = mais janela pro raciocinio (e mais barato).