El CLAUDE.md de Karpathy, explicado: un archivo detrás de una búsqueda de habilidades

En Google Trends, en todo el mundo, durante los últimos siete días y consultado el 23 de octubre de 2026, "karpathy skills" aparece como una consulta en ascenso dentro de la semilla "claude skills". Cualquiera que siga esa búsqueda llega al mismo lugar: github.com/multica-ai/andrej-karpathy-skills, un repositorio que mostraba 222.612 estrellas en GitHub, consultado el 23 de octubre de 2026. Su descripción no contiene la palabra «skill» en absoluto. Dice: "Un único archivo CLAUDE.md para mejorar el comportamiento de Claude Code, derivado de las observaciones de Andrej Karpathy sobre los errores de programación con LLM."

La brecha entre la consulta y el objeto no es una pequeña tecnicidad. Una skill y un archivo CLAUDE.md son mecanismos distintos que hacen un trabajo distinto, y casi todas las afirmaciones que la gente hace sobre este repositorio dependen de saber cuál de los dos es o asumen en silencio el equivocado. La guía que contiene es un único archivo. El repositorio que rodea ese archivo también incluye un manifiesto de plugin y una carpeta bajo skills, que probablemente sea de donde proviene la palabra en la barra de búsqueda. Separar el empaquetado de la carga útil es el primer paso útil aquí.

Las cifras, todas de GitHub y leídas el 23 de octubre de 2026: 222.612 estrellas, 22.321 bifurcaciones, creado el 27 de enero de 2026, último push el 20 de abril de 2026, licencia MIT. Ese último par es el interesante. El repositorio no ha recibido un push en aproximadamente seis meses, y aun así el número de estrellas siguió aumentando.

El archivo hace el trabajo; el empaquetado explica el término de búsqueda.

Abre el repositorio y la lista de archivos deja ver claramente la discrepancia. En la raíz está CLAUDE.md y, junto a él, CURSOR.md, EXAMPLES.md, una carpeta .cursor/rules que contiene las mismas directrices a modo de regla de proyecto de Cursor, una carpeta .claude-plugin y un directorio skills/karpathy-guidelines. La vía de instalación recomendada en el README es el marketplace de plugins, y describe el resultado como algo que hace que "la skill esté disponible en todos tus proyectos".

El término de búsqueda no es tanto incorrecto como impreciso. Hay una carpeta de skills. Hay un plugin. Lo que no hay es un conjunto de skills separadas, cada una haciendo una tarea distinta, que es la forma que la gente suele dar a entender con un skill pack: una carpeta que contiene un SKILL.md y los archivos de apoyo que esa capacidad necesite, invocada para una tarea. Aquí toda la guía es un único documento de instrucciones permanentes, y el plugin existe para entregar ese documento a un proyecto.

Que esa distinción te importe o no depende de lo que esperabas encontrar en la búsqueda. Si buscabas una caja de herramientas, esto no lo es. Si querías un libro de reglas breve que cambie cómo se comporta un agente de programación a lo largo de un proyecto, eso es exactamente lo que es, y vale la pena entender por qué alguien lo escribiría como un archivo en lugar de como skills.

Las quejas contra las que se escribió

La fuente declarada en el README es una publicación de Andrej Karpathy en X, que el README cita por tres quejas sobre cómo escriben código los modelos. Vale la pena leerlas en su totalidad, porque los cuatro principios se corresponden con ellas casi uno a uno.

El primero: los modelos «hacen suposiciones erróneas en tu nombre y simplemente siguen adelante con ellas sin comprobarlas», y «no gestionan su confusión, no buscan aclaraciones, no sacan a la luz las inconsistencias, no presentan disyuntivas, no oponen resistencia cuando deberían». Fíjate en lo que se está describiendo. No es una queja sobre respuestas incorrectas. Es una queja sobre respuestas incorrectas fluidas entregadas sin dudar, donde la incertidumbre que debería haber producido una pregunta produjo, en cambio, código seguro de sí mismo.

El segundo: «realmente les gusta complicar demasiado el código y las API, inflar las abstracciones, no limpiar el código muerto… implementar una construcción inflada de más de 1000 líneas cuando con 100 bastaría». Esa le resulta familiar a cualquiera que haya pedido una funcionalidad y haya recibido un framework.

El tercero es más sutil y, para cualquiera que revise diffs, el más costoso: «todavía a veces cambian/eliminan comentarios y código que no entienden lo suficiente como efectos secundarios, incluso si son ortogonales a la tarea». Una edición ortogonal a un comentario es pequeña por sí sola. Multiplicada por todo un código base, es así como una cola de revisión se llena de cambios que nadie pidió, y como un comentario que explica una solución alternativa desaparece antes de que nadie llegue a saber por qué existía esa solución alternativa.

Cuatro principios, y la prueba que cada uno deja tras de sí

El archivo codifica cuatro principios. Cada uno viene con un breve conjunto de reglas, y dos de ellos enuncian una prueba de una línea que puedes aplicar a un diff sin instalar nada. Las reglas son donde se muestra el carácter del archivo.

Piensa antes de programar

La instrucción del encabezado es «No des nada por supuesto. No ocultes la confusión. Expón las contrapartidas». Debajo: declara las suposiciones de forma explícita y pregunta en lugar de adivinar; presenta varias interpretaciones cuando la solicitud sea ambigua; muestra desacuerdo cuando exista un enfoque más sencillo; detente cuando estés confundido, nombra lo que no está claro y pide aclaración. Esto apunta directamente a la primera queja. El mecanismo no es «tener más cuidado», sino convertir las decisiones silenciosas en visibles, para que quien revise pueda discrepar antes de que exista el código y no después.

La simplicidad primero

La regla es el mínimo código que resuelve el problema, sin nada especulativo: ninguna función más allá de lo que se pidió, ninguna abstracción para código de un solo uso, ninguna flexibilidad ni configurabilidad que nadie haya solicitado, ningún manejo de errores para escenarios imposibles y, si 200 líneas pudieran ser 50, reescríbelo. La prueba es una sola pregunta —¿diría un ingeniero sénior que esto está sobredimensionado?—, que es una cuestión de criterio y, abiertamente, así es.

Cambios quirúrgicos

Aquí el archivo divide la instrucción en dos, que es lo más útil que contiene. Al editar código existente: no mejores el código, los comentarios ni el formato adyacentes; no refactorices lo que no está roto; adapta el estilo existente aunque tú lo harías de otra manera; menciona el código muerto no relacionado en lugar de eliminarlo. Cuando tus propios cambios creen huérfanos: elimina las importaciones, variables y funciones que tus cambios hayan dejado sin usar, pero deja en paz el código muerto preexistente salvo que se te pida lo contrario. La prueba es que cada línea modificada se remonte directamente a la solicitud.

Ejecución orientada a objetivos

Define los criterios de éxito y repite en bucle hasta verificarlos. El README muestra la transformación como pares. En lugar de "añadir validación", escribe pruebas para entradas inválidas y luego haz que pasen. En lugar de "corregir el error", escribe una prueba que lo reproduzca y luego haz que pase. En lugar de "refactorizar X", asegúrate de que las pruebas pasen antes y después. Para el trabajo de varios pasos, solicita un plan breve en el que cada paso indique su propia verificación. El README cita de nuevo a Karpathy aquí: "Los LLM son excepcionalmente buenos repitiendo en bucle hasta que alcanzan objetivos específicos… No le digas qué hacer; dale criterios de éxito y míralo avanzar."

Un archivo, una habilidad y un plugin son tres cosas diferentes

Vale la pena ser preciso sobre el mecanismo, porque el comportamiento práctico difiere. CLAUDE.md es un archivo de instrucciones de proyecto: texto que Claude Code lee como contexto permanente de un repositorio, presente tanto si alguien lo pidió en este turno como si no. Una skill es una carpeta con un SKILL.md que describe cuándo debe usarse la capacidad, y se carga cuando una tarea lo requiere y no antes. Un plugin es un paquete de distribución, instalado a través de un marketplace, que puede contener skills, comandos y otros componentes. Las distinciones tienen que ver con cuándo entran las instrucciones en el contexto y quién decide, no con la calidad.

En ese sentido, un CLAUDE.md es el más contundente de los tres. Siempre está activo en ese proyecto, se aplica a todas las tareas de este y ocupa contexto en cada turno, tanto si el trabajo consiste en corregir una errata de una línea como en una migración. El propio README del archivo reconoce el costo en una sección llamada Tradeoff Note: las directrices se inclinan hacia la cautela en lugar de la velocidad y, para tareas triviales —correcciones simples de errores tipográficos, obvias soluciones de una sola línea—, deberías usar tu criterio. Afirma que el objetivo es reducir los errores costosos en el trabajo no trivial, no ralentizar las tareas simples.

Esa es una descripción justa de lo que puede hacer un archivo de instrucciones permanentes. No puede añadir una capacidad que el modelo no tiene. Solo puede hacer que el comportamiento existente del modelo sea más o menos probable. Por eso el archivo está escrito como restricciones —no hagas esto, pregunta antes de aquello— en lugar de como un estímulo para ser mejor.

Qué miden 222,612 estrellas

Miden la atención. Eso no es un desdén y no es poca cosa: un repositorio creado en enero de 2026 y con su último push en abril alcanzó 222.612 estrellas y 22.321 forks el 23 de octubre de 2026, en GitHub, leído ese día, lo que significa que se compartió ampliamente y que lo bifurcaron personas que querían tener su propia copia. El número de estrellas es un indicador razonable de cuántas personas encontraron algo que valía la pena guardar.

No es un proxy del efecto, y el repositorio no pretende lo contrario. Lo que no se publica en ninguna parte de él: ningún benchmark que compare resultados con y sin el archivo, ninguna metodología para medir si funciona y ninguna comparación con un control. No hay un antes y un después en un código base real, ni un estudio con revisores, ni una tasa de incidentes. Un archivo como este es una hipótesis sobre el comportamiento del modelo, formulada con elegancia, y nadie ha ejecutado el ensayo.

Lo que el README ofrece en su lugar es una sección llamada Cómo saber que está funcionando, que enumera cuatro cosas que podrías observar: menos cambios innecesarios en los diffs, menos reescrituras debido a la sobrecomplicación, preguntas aclaratorias que llegan antes de la implementación en lugar de después de los errores, y pull requests mínimos y limpios. Esas son señales sensatas. También son exactamente lo que escribirías si no hubieras medido nada, y las reporta quien esté aplicando el archivo. Léelas como una lista de verificación con la que evaluar el archivo en tu propio repositorio, no como evidencia de que ya lo aprobó.

Lo que realmente escribes para instalarlo

El README ofrece dos rutas. La recomendada se ejecuta dentro de Claude Code: añade el marketplace, luego instala el plugin, tras lo cual las directrices están presentes en todos los proyectos en lugar de por repositorio. La segunda es por proyecto: traer el CLAUDE.md en bruto a un nuevo repositorio, o añadirlo a uno existente. También hay una regla de proyecto de Cursor versionada, de modo que las mismas directrices se aplican cuando la carpeta se abre en Cursor — un detalle que indica que el archivo se escribió para ser portable entre herramientas que leen un archivo de instrucciones a nivel de proyecto, y no estar atado al cargador de un solo proveedor.

Un detalle problemático que vale la pena señalar, porque te toparás con él si sigues el README al pie de la letra. Los nombres de los comandos del marketplace son forrestchang/andrej-karpathy-skills, mientras que la URL del repositorio en la parte superior de la página es multica-ai/andrej-karpathy-skills. Ambas cadenas aparecen en el mismo README, leído el 23 de octubre de 2026. Puedo ver la discrepancia y no puedo decirte por qué existe, así que el consejo honesto es probar la otra ruta si una falla, y considerar que una de las dos cadenas está desactualizada.

Lo otro que hay que notar en la página principal: el repositorio lo mantiene multica-ai, y la cita en bloque inicial del README promociona Multica, «una plataforma de código abierto para ejecutar y gestionar agentes de programación con habilidades reutilizables». Eso es una divulgación legítima, y también es una pista de por qué el empaquetado tiene el aspecto que tiene. Es probable que un proyecto interesado en habilidades reutilizables distribuya su propia guía como algo instalable, que es lo que es el plugin.

Utilizarlo sin heredar sus supuestos

La sección de Personalización es la parte que la mayoría de los lectores se salta. El archivo está diseñado para fusionarse con instrucciones específicas del proyecto en lugar de reemplazarlas, y los ejemplos que ofrece son concretos: usa el modo estricto de TypeScript, todos los endpoints de la API deben tener pruebas, sigue los patrones de manejo de errores existentes en un archivo determinado. Eso no es decoración. Es la diferencia entre un manual genérico y un conjunto de instrucciones que sabe dónde vive tu código.

Hay una razón práctica para fusionar en lugar de apilar. Si pegas el archivo tal cual y tu proyecto tiene sus propias convenciones, los dos conjuntos de instrucciones pueden entrar en conflicto, y un modelo que reconcilia un desacuerdo es precisamente la confusión que el primer principio intenta eliminar. Escribir tus convenciones en el mismo archivo, con la misma voz, mantiene la superficie de instrucciones lo bastante pequeña como para auditarla.

Y deberías auditarlo. Este es un documento breve de instrucciones de comportamiento que se aplicará a cada solicitud en el repositorio. La pregunta correcta no es si 222.612 personas pueden estar equivocadas —ese planteamiento no resuelve nada—, sino si cada regla se corresponde con un fallo que hayas visto realmente. Si tus diffs nunca han contenido reescrituras de comentarios hechas al pasar, la sección Surgical Changes te hace gastar contexto sin beneficio. Elimínala. El archivo tiene licencia MIT y está pensado para ser editado.

Un nivel más abajo, nada de esto cambia qué modelo responde. Un archivo CLAUDE.md determina cómo se gestiona una solicitud una vez que llega a un modelo; no dice nada sobre el modelo que la recibe. Esa segunda decisión corresponde a lo que esté delante del modelo. Una forma de organizarlo es un único endpoint compatible con OpenAI que ofrece más de 200 modelos bajo una sola clave, con conmutación automática por error entre proveedores y los precios de lista de los proveedores trasladados con un margen del 0 %. Alojamos modelos; no creamos Claude Code, y nada de tu repositorio es visible para nosotros.

La búsqueda seguirá diciendo «skills», porque esa es la palabra que usa la gente para referirse a algo que instalas para hacer que un agente se comporte de forma distinta, y el empaquetado de este repositorio también la usa. El artefacto es un archivo: un documento de instrucciones permanentes, redactado en respuesta a tres quejas concretas, con cuatro principios y un conjunto de pruebas que puedes aplicar a mano. Júzgalo por si esas quejas suenan como tu repositorio. Esa es una mejor pregunta que el recuento de estrellas, que nunca ha medido más que cuántas personas tuvieron la misma reacción que acabas de tener.