El proceso del punto A al punto B. Qué hace primero, qué después, y qué preguntar si falta un dato. Aquí es donde casi todo el mundo se queda.
## Los pasosTercera vez esta semana que le explicas a Claude cómo quieres el informe. Las mismas cinco cosas: que empiece por el resumen, que las cifras vayan en tabla, que no use la palabra «sinergia», que cierre con los siguientes pasos y que lo firme con tu web. Y sale bien. Sale bien las tres veces, porque se lo has explicado las tres veces.
Esta guía va de dejar de explicarlo. No con un prompt más largo ni con un documento que le pegas al principio de cada conversación: con un fichero que él abre solo cuando toca, y que contiene tu proceso escrito una vez.
Se llama skill. Y lo importante no es instalarse las que hay por ahí: es aprender a escribirse la que te haga falta el martes que viene.
Revisada el 5 de septiembre de 2026 · escalón: automatizar · unas 6 horas al mes en tareas que ahora mismo se hacen dos veces.
01 el problema
Hay una diferencia grande entre pedirle algo a Claude y montarle un proceso, y casi nadie la cruza. Se queda en pedir. Pides, corriges, vuelves a pedir, y al día siguiente empiezas de cero porque la ventana es nueva.
Está en que cada explicación sale un poco distinta. Tú no dictas exactamente lo mismo el lunes que el jueves: un día se te olvida decir que las cifras van en tabla, otro día no mencionas el cierre. El resultado es que tienes cinco informes con cinco formatos parecidos pero no iguales, y ninguno se puede comparar con el anterior.
Números de ejemplo, no una medición: cámbialos por los tuyos. Lo que se cuenta no es lo que tarda Claude, sino lo que tardas tú en explicárselo y en corregir lo que salió distinto.
| Lo que se repite | Veces/mes | Minutos | Al año |
|---|---|---|---|
| Explicarle el formato otra vez | 5 | 6 | 6 h |
| Corregir lo que salió con otro formato | 5 | 8 | 8 h |
| Volver a buscar el ejemplo bueno para pegárselo | 3 | 5 | 3 h |
| Rehacer entero lo que salió mal del todo | 1 | 25 | 5 h |
| Total | 22 h |
Veintidós horas al año en un solo proceso, y lo peor no es el número: es que ninguna de esas horas mejora nada. Al año siguiente vuelven a estar ahí.
Y hay un segundo coste, más caro y más silencioso: cuando no está escrito, no se puede mejorar. Si el informe sale flojo no sabes si es porque el proceso es malo o porque ese día lo explicaste peor. No hay nada que corregir, porque no hay nada fijo.
02 el concepto
Una skill es una carpeta con un fichero de texto dentro. Nada más. El fichero se llama SKILL.md, empieza con dos líneas de identificación y sigue con tu proceso escrito en castellano llano.
Las dos líneas de arriba son las que deciden cuándo se activa. Van entre guiones, y son exactamente dos: cómo se llama y cuándo hay que usarla.
--- name: informe-mensual description: Escribe el informe mensual con el formato de la casa — resumen arriba, cifras en tabla, cierre con siguientes pasos. Úsalo cuando se pida "el informe del mes", "el informe de septiembre" o "prepara el mensual". --- # Informe mensual ## Cuándo se dispara Cuando se pida el informe de un mes concreto. Si no se dice el mes, se pregunta antes de escribir nada. ## Los pasos 1. Resumen de cuatro líneas arriba del todo. Sin adjetivos. 2. Las cifras del mes en una tabla, con la variación contra el mes anterior. 3. Lo que ha salido mal, con su motivo. Este apartado nunca se omite. 4. Siguientes pasos, en forma de lista con responsable. ## Lo que NO se hace - No se inventa una cifra que no esté en los datos de entrada. - No se usan las palabras "sinergia", "disruptivo" ni "ecosistema". - No se cierra sin el apartado de lo que ha salido mal, aunque esté vacío.
Eso es una skill entera. Si lo guardas en .claude/skills/informe-mensual/SKILL.md dentro de tu proyecto, Claude lo lee cuando alguien pide el informe del mes.
La diferencia está en quién decide cuándo se usa. Un prompt guardado lo pegas tú cuando te acuerdas; una skill se activa sola porque su descripción encaja con lo que has pedido. Eso cambia quién carga con recordar el proceso, y ése era todo el problema.
Es el campo que más se descuida y el que decide si la skill sirve. Claude lee todas las descripciones que tiene disponibles y elige por ahí. Una descripción que dice «ayuda con informes» no se dispara nunca, porque no compite con nada. Una que dice cuándo usarla y con qué palabras, sí.
Fíjate en la del ejemplo: dice qué hace y luego con qué frases se pide. Esas frases son las que tú usas de verdad, no las que suenan bien.
Y a veces la respuesta es que no necesitas una skill.
Si el proceso lo haces 1 vez al mes o menos, escribir la skill te va a costar
más que hacerlo a mano las próximas seis veces. El umbral sale de la cuenta de
arriba: si repites algo 4 o 5 veces al mes y cada vez te cuesta explicarlo,
la skill se paga sola en dos semanas. Si lo haces 1 vez al trimestre, una
plantilla en un documento normal te resuelve lo mismo y no hay que mantenerla.
Y hay un caso peor: el proceso que todavía no tienes claro. Escribir una skill
de algo que aún estás decidiendo cómo se hace congela una decisión mala. Primero
se estabiliza el proceso a mano, y cuando ya sale igual dos veces seguidas,
entonces se escribe.
03 el inventario
Cuatro cosas que conviene saber antes de escribir la primera, porque explican casi todos los fallos del principio. Cada una con su documentación al lado: esto lo cambian ellos, no yo.
Se carga en tres tiempos, y por eso la descripción decide. Al arrancar, Claude solo tiene en la cabeza el nombre y la descripción de cada skill. El cuerpo del SKILL.md no se lee hasta que una de ellas encaja con lo que has pedido, y los ficheros de al lado solo se abren si hacen falta. Por eso una descripción floja no es un detalle de estilo: es lo único que se mira para decidir si tu proceso entra o no (documentación).
Viven en dos sitios, y hay precedencia. Las tuyas de siempre van en ~/.claude/skills/; las de un proyecto concreto, en .claude/skills/ dentro de la carpeta. Si dos se llaman igual, gana la personal sobre la del proyecto (documentación). La regla práctica: si la vas a usar en todos tus trabajos, personal; si habla de este cliente, del proyecto.
Hay límites, y son generosos pero existen. El nombre, hasta 64 caracteres, en minúsculas, números y guiones. La descripción, hasta 1.024 caracteres — que dan de sobra para decir qué hace y con qué frases se pide, que es justo lo que hay que poner.
Se puede mirar si está. Dentro de una sesión, /skills lista las que Claude tiene disponibles con su descripción. Si la tuya no sale ahí, no es que no se dispare: es que no la ve, y entonces el problema es la ruta o el frontmatter, no la redacción.
04 las genéricas
Aquí está lo que casi nadie te cuenta cuando te enseña a instalar skills de otros. Una skill de redacción bajada de un repositorio escribe correcto y escribe de nadie.
No sabe a quién le vendes. No sabe qué tres cosas no dices jamás porque te quemaron una vez. No sabe que tu cliente medio no entiende la palabra «integración» y hay que decir «que hablen entre ellos». No sabe que tú cierras los correos sin despedida porque te parece que alarga.
Una skill descargada te da la estructura. Lo que la hace útil es el criterio, y
el criterio es justo lo que el que la escribió no tenía sobre tu trabajo. Sirve
para arrancar, y poco más.
Eso no significa que no valgan. Significa que valen para lo que es igual en todo el mundo —convertir un fichero, formatear una tabla, revisar ortografía— y no valen para lo que te distingue, que es exactamente lo que quieres delegar.
Ábrela y busca el apartado donde diga qué no hay que hacer. Si no lo tiene, o si lo que dice vale para cualquiera, esa skill no conoce tu trabajo: te va a dar la estructura y vas a seguir corrigiendo el fondo cada vez.
05 las tres capas
Cuando escribes la tuya hay tres bloques que la separan de una descargada, y van en este orden porque cada uno depende del anterior.
El proceso del punto A al punto B. Qué hace primero, qué después, y qué preguntar si falta un dato. Aquí es donde casi todo el mundo se queda.
## Los pasosLo que NO debe hacer. Es el bloque que más ahorra y el que casi nadie escribe: las palabras prohibidas, lo que no se inventa nunca, dónde tiene que parar.
## Lo que NO se haceTus colores, tu logotipo, tu tipografía, el enlace a tu web, tus tres ejemplos buenos. Sin esto la skill sabe hacer el trabajo pero no sabe vestirlo.
## El materialEl tercero es el que convierte la skill en algo que un competidor no puede copiar, y es también el más fácil de rellenar, porque ya lo tienes. Está en tu web, en tu última propuesta y en el logotipo que llevas usando dos años.
06 antes de nada
Poca cosa, y conviene mirarlo antes de escribir nada: la mitad de los atascos del primer día están aquí y no en el fichero.
07 manos a la obra
La primera skill que escribas debería ser de algo aburrido y frecuente. No la de tu trabajo más creativo: la del correo que mandas cada viernes, o el resumen que preparas antes de cada reunión.
# la carpeta y el fichero: una skill no es más que esto
mkdir -p .claude/skills/mi-proceso
touch .claude/skills/mi-proceso/SKILL.md
# la comprobación de que está donde crees que está
ls -1 .claude/skills/Así se ve esa comprobación en el repositorio donde se escribió esta guía, el 5 de septiembre de 2026. Cinco carpetas, una por skill, y ninguna es más que eso:
audita-guia
escribe-entrada
investiga
rastrea
replicaDentro de cada una, lo mínimo es un fichero. escribe-entrada, por ejemplo, tiene tres: el SKILL.md, un examen en Python que la propia skill ejecuta y un ejemplo. La skill son las instrucciones; lo que va al lado es lo que no se debe improvisar.
Ahora se rellena, y el orden importa: primero se escribe cuándo se dispara, porque si eso está mal no se activará nunca y darás por hecho que las skills no funcionan.
08 el bucle
La forma más rápida de escribir el cuerpo no es escribirlo. Es hacer el proceso a mano una vez más, en voz alta, y que Claude lo transcriba en pasos mientras lo haces. Después lo corriges, que es mucho más rápido que redactarlo de cero.
Voy a hacer un proceso delante de ti y quiero que lo conviertas en una skill. Mientras te lo cuento, apunta: 1. Los pasos, en el orden en que los hago. 2. Cada vez que digo "esto nunca" o "aquí cuidado", eso va a un bloque separado que se llama "Lo que NO se hace". 3. Cada vez que menciono un fichero, una plantilla o un ejemplo, apúntalo en un bloque que se llama "El material". Cuando termine, escríbeme el SKILL.md completo, con su name y su description. En la description pon las frases EXACTAS con las que yo pediría esto, no sinónimos. Si algún paso te ha quedado ambiguo, pregúntamelo antes de escribir. Empiezo: [aquí cuentas tu proceso]
Fíjate en la última línea del prompt. Que pregunte antes de escribir es lo que evita la skill bonita e inservible: la que parece completa y falla el primer día porque dio por supuesto algo que tú no dijiste.
Una skill recién escrita casi nunca se dispara a la primera. El motivo suele ser siempre el mismo: la descripción no tiene las palabras que tú usas. Se prueba pidiéndolo como lo pedirías un martes cualquiera, sin nombrarla, y se mira si entra sola.
09 el material
Este es el bloque que convierte una skill correcta en una skill tuya, y se pega igual en todas las que escribas. Cámbiale los valores y ya está.
## El material **La marca** - Color principal: #E08968 · sobre fondo #1C1B19 - Tipografía de titulares: grotesca de peso alto, tracking -0.02em - Logotipo: `marca/logo.svg` — nunca se deforma ni se recolorea - Enlace que va al pie de todo: tu-dominio.com **Cómo se escribe aquí** - Frases cortas. Si una frase pasa de treinta palabras, se parte. - Nada de "sinergia", "disruptivo", "ecosistema", "solución integral". - Al cliente no se le dice "integración", se le dice "que hablen entre ellos". - Los correos cierran sin despedida. **Tres ejemplos buenos, para copiar el tono** - `ejemplos/propuesta-buena.md` - `ejemplos/informe-que-le-gusto-al-cliente.md` - `ejemplos/correo-de-seguimiento.md`
A partir de que ese bloque existe, cada informe y cada propuesta que salga viene ya vestida de lo tuyo sin que lo menciones. No porque Claude se acuerde: porque lo lee cada vez que abre la skill.
10 las mías
Enseño dos de las mías, no como plantilla sino para que se vea la diferencia entre una skill y un prompt guardado.
La primera se llama rastrea. Le paso un perfil de la competencia y ella sola baja los vídeos, los transcribe enteros, mide el montaje y me devuelve cuáles funcionan y por qué. No es un fichero: son veintiséis, porque el proceso tiene partes que un modelo no debe improvisar —descargar, transcribir, medir cortes— y ésas van en scripts al lado del SKILL.md.
La segunda se llama audita-guia. Coge lo que he escrito, lo revisa línea a línea buscando comandos que no existen, rutas mal puestas e imports que no resuelven, y me para antes de publicar. Su regla dura es que mide sobre la página renderizada y no sobre el texto fuente, porque una auditoría anterior falló cuatro hallazgos de veintidós por leer el markdown donde había que mirar la página.
Las dos llevan escrito por qué existen, con la fecha del fallo que las provocó. Eso no es documentación: es lo que impide que dentro de dos meses alguien —tú mismo— quite una comprobación porque le parece que sobra.
Cuando una skill falla y la arreglas, escribe dentro qué falló y qué día. Sin
eso, la próxima persona que la toque deshará el arreglo por parecerle innecesario.
Y esa persona suele ser uno mismo tres meses después.
11 el atajo
Hay una salida más corta y conviene decirla: existe una skill cuyo trabajo es escribir skills. Le cuentas en dos líneas lo que haces, te pregunta lo que le falta y te devuelve la estructura montada con las bases puestas. Tú rellenas lo tuyo.
Es oficial de Anthropic y se instala como complemento desde su propio catálogo:
# dentro de una sesión de Claude Code
/plugin install skill-creator@claude-plugins-official
# y para ver qué tienes instalado, desde el terminal
claude plugin listAsí estaba esa comprobación en la máquina donde se escribió la guía. Enseña dos cosas: que el catálogo oficial ya está enganchado —de ahí el sufijo @claude-plugins-official— y que el creador no estaba instalado cuando escribí esto. O sea que lo que cuento de él sale de su documentación y de su código abierto, no de haberlo ejecutado:
Installed plugins:
❯ claude-code-setup@claude-plugins-official
Version: 1.0.0
Scope: user
Status: ✔ enabledTardas veinte minutos más y sales con el proceso pensado. Los límites salen solos porque los dices en voz alta mientras lo haces.
Sales en cinco minutos con una estructura correcta y vacía de criterio. Sirve si el proceso ya lo tienes clarísimo y solo quieres el envase.
Sirve para arrancar, con la misma limitación de siempre: te da los pasos y los límites, y el material lo tienes que poner tú. Ninguna herramienta sabe de qué color es tu marca ni qué palabra no usas nunca.
Quiero una skill para [el proceso]. Contexto que necesitas antes de escribirla: - La hago [N] veces al mes. - Lo que más me cuesta explicar cada vez es: [eso]. - Lo que sale mal cuando no lo superviso: [eso otro]. - Ficheros o plantillas que ya uso: [rutas]. Escríbeme el SKILL.md con tres bloques: Los pasos, Lo que NO se hace y El material. Deja "El material" con los huecos marcados para que los rellene yo, y NO te inventes ningún valor de marca ni ningún ejemplo.
12 el calendario
no significa que esté mal escrita: significa que la descripción no lleva tus palabras. Se arregla en dos minutos y es la lección más útil de todas.
formato. Sigues revisando el fondo —eso no se delega— pero el envase ya viene puesto, y ahí es donde se recuperan las horas de la cuenta del principio.
cambia y no lo tocas, seguirá haciendo lo de antes con toda la seguridad del mundo. Lo que sí puedes esperar es que, cuando falle, sepas exactamente qué línea corregir — y eso es justo lo que no tenías cuando lo explicabas de viva voz.
13 el diagnóstico
Casi todos los problemas del principio son de activación, no de contenido. Se diagnostican en este orden, que va de lo más tonto a lo más sutil.
/skillsdescribe el cuándo, con tus frases/skillsacorta el SKILL.md14 la letra pequeña
Una skill no mejora un proceso malo: lo repite igual de mal, pero más deprisa y sin que se note. Si el informe que haces a mano no sirve, escribirlo en un fichero solo consigue que salga peor más rápido.
Tampoco sustituye la revisión. Lo que se delega es el envase —el formato, el tono, el orden, lo que no se dice— y no el juicio sobre si lo que pone es cierto. El día que dejes de leer lo que sale, la skill se convierte en el problema.
Y no se mantiene sola. Cuando cambie tu marca, tu precio o tu forma de trabajar, hay un fichero más que actualizar. Es poco trabajo, pero no es cero, y por eso el umbral de más arriba importa: por debajo de cuatro o cinco usos al mes, no compensa tener una cosa más que mantener.
15 las dudas
Las skills existen en varias superficies —Code, la aplicación y la API— pero no se sincronizan entre ellas: lo que subes a una no aparece en las otras. Esta guía va de las que viven en tu ordenador, en la carpeta del proyecto.
No hay un número, pero sí un síntoma: cuando se te disparan las que no tocan. Cada skill compite por activarse con su descripción, así que el problema no llega por cantidad sino por solapamiento. Diez bien delimitadas conviven mejor que tres que dicen casi lo mismo.
/skills te enseña las que están disponibles. Y hay una comprobación más honesta: pide el trabajo sin nombrar la skill y mira si el resultado trae lo que solo está escrito ahí dentro —tu palabra prohibida, tu apartado obligatorio—. Si no lo trae, no entró.
Si el proceso es tuyo y lo usas en todos los trabajos, en la personal (~/.claude/skills/). Si habla de este cliente, de este repositorio o de esta marca, en la del proyecto (.claude/skills/), que además se comparte con quien trabaje ahí. Si coinciden en nombre, manda la personal.
Sí, y es un buen atajo para la estructura. Pero ábrela y busca el bloque de «lo que NO se hace»: si no lo tiene, o si vale para cualquiera, esa skill no conoce tu trabajo. La estructura se copia; el criterio se escribe.
16 el cierre
Lo que se lleva alguien que hace esto bien no es una skill. Es haber convertido una cosa que explicaba cada semana en una cosa que está escrita, y por tanto se puede corregir, comparar y mejorar. La skill es el envase.
Y el orden que importa, resumido: se estabiliza el proceso a mano, se escribe cuándo se dispara, se dictan los pasos, se añaden los límites, y el material va el último porque es el que hay que actualizar cuando cambie la marca.
Y para que no tengas que recomponerla a trozos, la skill del ejemplo entera:
--- name: informe-mensual description: Escribe el informe mensual con el formato de la casa — resumen arriba, cifras en tabla, cierre con siguientes pasos. Úsalo cuando se pida "el informe del mes", "el informe de septiembre" o "prepara el mensual". --- # Informe mensual ## Cuándo se dispara Cuando se pida el informe de un mes concreto. Si no se dice el mes, se pregunta antes de escribir nada. ## Los pasos 1. Resumen de cuatro líneas arriba del todo. Sin adjetivos. 2. Las cifras del mes en una tabla, con la variación contra el mes anterior. 3. Lo que ha salido mal, con su motivo. Este apartado nunca se omite. 4. Siguientes pasos, en forma de lista con responsable. ## Lo que NO se hace - No se inventa una cifra que no esté en los datos de entrada. - No se usan las palabras "sinergia", "disruptivo" ni "ecosistema". - No se cierra sin el apartado de lo que ha salido mal, aunque esté vacío. - No se envía nada: se deja el borrador y se avisa. ## El material - Color principal: #E08968 · sobre fondo #1C1B19 - Enlace que va al pie de todo: tu-dominio.com - El tono se copia de: `ejemplos/informe-que-le-gusto-al-cliente.md` ## Por qué existe Escrita el 05/09/2026, después de mandar tres informes del mismo mes con tres formatos distintos y no poder compararlos entre sí.
No es para quien todavía está decidiendo cómo hace el proceso: escribir la skill antes congela una decisión que aún no está tomada, y luego cuesta más deshacerla que haberla escrito bien. Ahí lo que toca es el escalón de antes, analizar: mirar cómo se hace hoy y contar cuánto cuesta, y solo entonces automatizar.
Tampoco es para quien busca instalar y olvidarse. Una skill descargada se instala; una skill tuya se mantiene, y si nadie la mantiene se queda vieja y empieza a estorbar.
Y si lo que tienes delante es un proceso que hacen tres personas distintas de formas distintas, la skill no es el primer paso. Primero hay que ponerse de acuerdo en cuál de las tres formas es la buena, que es una conversación y no un fichero.
Las fuentes, para que lo compruebes tú
Nada de esta guía se cita de memoria. Cada enlace se abrió y se comprobó el día que se escribió: qué es, qué licencia tiene y si sigue mantenido. Si algo de aquí ya no cuadra, gana la fuente.
El arnés que suspende a Claude — cuando ya tienes varias skills y quieres que trabajen solas sin que se te rompa nada, el siguiente paso es ponerles raíles y un revisor que no las apruebe él mismo. Es la continuación natural de ésta.
La misma pregunta en tres Claude — si al leer esto te has dado cuenta de que lo que usas es el navegador y no la terminal, empieza por ahí: decide primero cuál de las tres puertas te toca y vuelve luego a las skills.
Claude no se olvida: Obsidian como su memoria — la otra mitad del mismo problema. Las skills guardan cómo se hace; la bóveda guarda qué se decidió y por qué.
Esto que acabas de leer es formación y herramientas, y en tu empresa tendrá otra forma. Si quieres, lo miramos sobre tu proceso: media hora basta para saber si hay algo que automatizar o si se arregla ordenando lo que ya tienes.
Ver las sesionesRevisada el 2026-09-05. Publicada el 2026-09-05.
De esto hablo en mi Instagram, donde lo cuento en un minuto.