Voy a ser directo: hay un número enterrado en un paper reciente de Microsoft Research que debería cambiar cómo tu equipo construye skills de agentes — y la mayoría de la cobertura lo está tratando como una curiosidad académica en vez del cambio operativo que realmente es.
Acá está el número. Sobre GPT-5.5, un skill document optimizado por SkillOpt sumó +19.1 puntos corriendo dentro del harness de Claude Code, y +24.8 puntos dentro de Codex — comparado con correr el mismo modelo frozen sin skill alguna. Mismo modelo. Mismo harness. Mismo costo de inferencia. Lo único que cambió fue el archivo Markdown que le dice al agente cómo trabajar.
Si ahora mismo mantenés un CLAUDE.md, un AGENTS.md, o cualquier skill.md a mano, esa es la parte para quedarse pensando un rato.
La premisa: tu skill doc es estado entrenable, no documentación
Durante dos años, toda la conversación de IA y código giró alrededor de los modelos. GPT-5.5 vs Opus 4.8. Cuál escribe mejor código, cuál alucina menos, cuál sostiene más contexto. SkillOpt viene desde un ángulo completamente distinto: dejá el modelo frozen y tratá al skill document como la cosa que optimizás.
El framing está deliberadamente prestado del deep learning. Tenés epochs, minibatches, un learning rate y validation gates — solo que todo eso aplica a un archivo Markdown en vez de a los pesos del modelo. La skill es “estado externo” de un agente frozen, y la entrenás de la misma forma que entrenarías cualquier otra cosa: corrés, puntuás, ajustás, te quedás con lo que mejora.
Esto no es prompt engineering con pasos extra. La disciplina es justamente el punto.
Cómo funciona el loop en realidad
Cuatro etapas, repetidas:
Rollout. El modelo target frozen corre las tareas usando la skill actual y registra trajectories puntuadas — cada tool call, generación de código, output del compilador y resultado del verifier. Pensalo como el forward pass.
Reflect. Un modelo optimizer separado (un frontier model, distinto del que hace el trabajo) analiza batches de éxitos y fracasos por separado, buscando procedimientos reutilizables. Este es el backward pass a nivel lenguaje.
Edit. El optimizer propone operaciones acotadas de add / delete / replace sobre el skill document. Y acá está la parte más ingeniosa: hay un edit budget que funciona como un learning rate textual. Limita cuánto puede cambiar el doc en un solo paso. Sin eso, el self-editing se vuelve errático — el agente sobrescribe reglas que estaban funcionando y pierde su lugar. El budget es lo que mantiene la evolución gradual y reproducible en vez de ser una moneda al aire.
Gate. Un edit candidato se acepta solo si mejora estrictamente un validation score held-out. Si no mejora, se rechaza — y los edits rechazados se vuelven feedback negativo para que el optimizer no vuelva a meterse en el mismo callejón sin salida. Esto convierte la reflexión en optimización del tipo proponer-y-testear, en vez del enfoque incondicional de “dejá que el agente reescriba sus propias instrucciones” que tiende a derivar.
El modelo en sí nunca cambia. Terminás con un artifact best_skill.md deployable que tiene cero costo extra de inferencia.
Por qué el resultado cross-harness es el titular
El barrido de benchmarks es amplio: 7 modelos target, 6 benchmarks, dos harnesses de ejecución reales — Codex y Claude Code. SkillOpt fue el mejor o empató en el mejor en las 52 celdas (modelo × benchmark × harness). Le ganó a las skills escritas a mano, y le ganó a los enfoques automatizados previos (TextGrad, GEPA, EvoSkill).
Dos cosas importan más que los scores crudos para cualquiera que maneje un equipo:
Primero, funciona dentro de los harnesses que ya usás. No es un benchmark que solo vive en un cuaderno de laboratorio. Los números de Codex y Claude Code dicen que la skill optimizada se transfiere a las herramientas concretas que tus devs abren cada mañana.
Segundo, las skills aprendidas se transfieren entre modelos y harnesses. Una skill entrenada contra un setup arrastra ganancias a otros. Para un equipo que está estandarizando workflows agénticos, esa es la diferencia entre mantener un único artifact entrenado y volver a escribir instrucciones para cada herramienta y cada bump de modelo.
Los caveats honestos — porque esto no es un plugin
Acá es donde frenaría un poco antes de que alguien de tu equipo clone el repo esperando un comando /install-skill.
SkillOpt es un framework de investigación, con licencia MIT y público en github.com/microsoft/SkillOpt (~3.2K stars y subiendo). No es un plugin de un clic para Claude Code. Para correrlo necesitás una API de LLM o un endpoint de Azure OpenAI, un modelo optimizer separado, y cómputo real para los batches de rollout. Los datasets de los benchmarks no vienen incluidos — traés tu propia data, formateada según lo que espera cada environment. Y las ganancias, aunque consistentes, varían muchísimo por benchmark: algunas celdas muestran un dígito, otras saltan 50+ puntos. Tu dominio decide dónde caés.
También hay una trampa de nombres que vale la pena marcar: andan dando vueltas repos de “skill factory” no relacionados que hacen de bridge entre Claude Code y Codex. Esos no son este. SkillOpt es el optimizer de Microsoft Research, y la distinción importa cuando estás buscando.
Qué haría yo con esto
No esperes el plugin pulido. La idea es el activo acá, y la podés adoptar antes de que el tooling alcance.
Si tu equipo tiene una tarea agéntica recurrente — un ciclo estricto plan→dev→test→deploy, un flujo de review documentado, cualquier cosa que ya intentaste codificar en una skill escrita a mano — eso es un candidato. Corré tu agente frozen contra un set de specs representativas, puntuá las trajectories con honestidad, y dejá que un modelo más fuerte proponga edits acotados al doc, gated según si realmente mejoran los resultados. Incluso una versión manual de ese loop le gana al status quo, que para la mayoría de los equipos es: escribir la skill una vez, esperar que generalice, y nunca más tocarla.
El skill.md escrito a mano siempre fue un placeholder. SkillOpt es el argumento de lo que lo reemplaza.