Cómo convertí una tarea visual repetitiva en una skill de ChatGPT que puedo volver a usar
Una imagen aislada la genera cualquiera. Lo difícil es hacer la número veinte sin volver a explicar el cliente, el proceso y las reglas desde cero. Este es el caso real, paso a paso, con la skill pública al final.
La quinta imagen ya es un patrón
La primera era una tarea. Cuando se repite y las decisiones se mantienen, deja de tener sentido reconstruirlo todo en cada encargo.
La skill fue el último paso
Primero hicimos las piezas a mano. Después detectamos qué se repetía. Solo entonces la escribimos.
Fidelidad, no solo estética
Una imagen puede ser preciosa y estar mal. La otra mitad del trabajo es no inventar datos ni interfaces.
La skill pública, entera
Al final te dejo la versión base, anonimizada, salida de un caso real. Ni plantilla vacía ni prompt milagroso.
Este artículo no empezó porque quisiera crear una skill.
Empezó con un trabajo bastante menos glamuroso: preparar imágenes horizontales para varios artículos de un Centro de Ayuda. Imágenes que explicaran pasos, requisitos y comprobaciones sin inventar una sola condición, sin parecer anuncios y sin obligarme a rediseñar la familia visual en cada pieza.
La primera imagen era una tarea.
La quinta ya era un patrón.
Y cuando una tarea se repite, las decisiones importantes se mantienen y el coste está en volver a recordar y explicar lo mismo, ahí sí tiene sentido convertir el trabajo en un sistema.
Primero construimos las piezas. Después detectamos qué decisiones se repetían. Más tarde escribimos la skill. La primera versión se nos fue de madre, la recortamos, la revisamos en ChatGPT Work y terminamos instalándola en Complementos > Habilidades.
Aquí voy a abrir todo ese proceso: qué información utilizamos, cómo separamos contenido y diseño, qué errores nos obligaron a poner límites, qué congelamos, qué dejamos variable, cómo convertimos el método en una skill compacta y qué debe seguir revisando una persona.
Al final incluyo la skill pública y anonimizada completa. No una plantilla vacía ni un «prompt milagroso»: la versión base que salió de un caso real, sin la capa de marca ni los datos privados del cliente.
El proyecto es real. En las capturas que acompañan al artículo se ocultan de forma irreversible nombres, usuarios, correos, códigos, rutas privadas y cualquier elemento que identifique al cliente o a sus usuarios. No voy a reconstruir pantallas ni a fabricar pruebas para que el tutorial quede más bonito.
El problema real no era hacer una imagen bonita
Contenido operativo, no creatividades para redes. Aquí una imagen puede ser impecable y seguir estando mal.
El cliente tenía contenidos operativos. No eran portadas de blog ni creatividades para redes sociales. Eran artículos que ayudaban a una persona a completar un proceso dentro de una plataforma.
En uno de los trabajos, el recorrido contenía cinco bloques:
- Crear una cuenta de empresa.
- Introducir un código de asesor o distribuidor.
- Revisar los datos de facturación.
- Completar la verificación de empresa.
- Aportar la documentación necesaria para verificar una numeración geográfica.
En otro artículo del mismo Centro de Ayuda trabajamos el cambio y la revisión de datos de facturación. Ahí apareció una corrección que parece pequeña, pero era fundamental: los datos de facturación no son lo mismo que la titularidad. También había recorridos distintos cuando el cambio afectaba al país y casos particulares que no se podían convertir en una regla general.
Ese tipo de contenido no admite que el modelo rellene huecos porque «suena lógico». Una imagen podía ser visualmente impecable y seguir siendo incorrecta si:
- Confundía facturación con titularidad.
- Generalizaba a todos los países una condición concreta.
- Añadía un documento no confirmado.
- Convertía una excepción en un paso obligatorio.
- Mostraba una interfaz inventada como si fuera una pantalla real.
- Incluía un logotipo reinterpretado o incorrecto.
- Reproducía una URL, un código o un dato privado que no debía aparecer.
Ahí entendí que la coherencia estética era solo la mitad del trabajo. La otra mitad era fidelidad operativa.
Una imagen puede ser preciosa y estar mal
Cuándo una tarea empieza a pedir una skill
No por una imagen que me haya gustado. Ni porque algo vaya a repetirse dos veces.
No crearía una skill después de una única imagen que me haya gustado. Tampoco la crearía solo porque una tarea vaya a repetirse dos veces.
En este caso aparecieron cuatro señales claras:
| Señal | Lo que estaba ocurriendo |
|---|---|
| Repetición | Cada artículo podía necesitar varias piezas de apoyo |
| Decisiones estables | Formato, jerarquía, paleta, densidad y tratamiento de avisos se repetían |
| Riesgo | Un error podía hacer que el usuario siguiera mal un proceso |
| Coste de contexto | Había que volver a explicar las mismas reglas en cada encargo |
La skill no nació para conseguir una imagen más espectacular. Nació para evitar que la calidad dependiera de mi memoria y de la longitud del siguiente mensaje.
La documentación oficial de OpenAI resume las skills como una forma de guardar instrucciones, referencias y ejemplos para repetir una tarea con la misma estructura. También propone un ciclo sencillo: ejecutar primero, guardar el método, reutilizarlo y refinarlo. Es exactamente lo que hicimos aquí, aunque llegamos a esa conclusión trabajando desde las trincheras. Guía oficial de ChatGPT Work sobre plugins y skills.
Antes del sistema: hacer el trabajo a mano
Poco vendible y completamente necesario. Si escribes la skill antes de las piezas, documentas una idea, no un método.
Este paso es poco vendible y completamente necesario.
Antes de escribir la skill hicimos imágenes concretas. Trabajamos con el contenido real, vimos qué información cabía, qué necesitaba una pieza independiente, dónde se rompía la lectura y qué decisiones visuales funcionaban juntas.
Si hubiera escrito la skill antes de hacer las piezas, habría documentado una idea. No un método probado.
La secuencia real fue esta:
Paso 1 · Congelar la fuente antes de diseñar
Cuando el contenido afecta a un proceso real, el generador no es la fuente de verdad.
Cuando el contenido afecta a un proceso real, el generador no es la fuente de verdad. La fuente puede ser un artículo ya aprobado, una documentación interna validada, una captura real de la plataforma o las instrucciones confirmadas por las personas responsables del proceso. O una combinación, siempre que se sepa qué fuente manda si hay contradicciones.
En este proyecto utilizamos contenidos operativos y correcciones confirmadas por el equipo que conocía el procedimiento. No utilizamos una búsqueda genérica ni dejamos que ChatGPT dedujera cómo «debería» funcionar la plataforma.
Antes de crear cada pieza, convertimos el bloque correspondiente en una unidad cerrada de trabajo:
| Campo | Pregunta que debe responder |
|---|---|
| Título | ¿Qué paso o comprobación estamos explicando? |
| Objetivo | ¿Qué debe entender o hacer la persona al verla? |
| Fuente | ¿De dónde sale cada afirmación? |
| Alcance | ¿A qué país, cuenta, producto o situación se aplica? |
| Puntos confirmados | ¿Qué tres a seis ideas deben aparecer? |
| Aviso | ¿Qué condición no se puede perder al resumir? |
| Exclusiones | ¿Qué no debe mostrar, afirmar o deducir? |
Esta ficha no tiene que ser un documento formal. Puede ser un bloque breve dentro del mensaje. Su función es impedir que una conversación larga y abierta se convierta en una fuente ambigua.
Ejemplo de ficha de contenido anonimizada
TIPO: Checklist TÍTULO: Revisa los datos antes de continuar OBJETIVO: Que la persona confirme que la información corresponde al titular correcto ALCANCE: Empresas registradas en España PUNTOS CONFIRMADOS: - Comprobar los datos fiscales - Comprobar los datos de contacto - Guardar los cambios antes de seguir AVISO: Cambiar los datos de facturación no cambia automáticamente la titularidad NO MOSTRAR: datos reales, URL completa, interfaz reconstruida ni logotipo
Ese bloque contiene mucho menos contexto que toda la conversación. Y, sin embargo, contiene más contexto útil para esa imagen.
En mi guía de optimización de tokens en ChatGPT desarrollo justo esta idea: no se trata de darle al modelo todo lo que sabes, sino lo que decide el resultado. Una skill bien delimitada evita repetir las reglas estables; la petición concreta aporta los datos variables.
Paso 2 · Decidir qué merece una imagen
Que un artículo tenga cinco apartados no significa que necesite cinco imágenes.
Una imagen aporta valor cuando ayuda a ejecutar una acción, verificar varios requisitos de un vistazo, entender una secuencia, detectar una condición que suele pasar desapercibida o reducir un error recurrente.
No aporta valor cuando se limita a repetir un párrafo con iconos alrededor.
En el flujo de cinco pasos sí tenía sentido crear una familia visual porque el usuario avanzaba por una secuencia y cada bloque resolvía una acción distinta. En cambio, otros fragmentos quedaban mejor como texto, enlace o captura real de interfaz.
Esta decisión terminó dentro de la skill con una regla explícita: no generar una imagen solo porque exista un bloque de texto.
Paso 3 · Separar capturas reales e infografías
Dos tipos de visuales que no deberían confundirse en un Centro de Ayuda.
| Visual | Para qué sirve | Riesgo principal |
|---|---|---|
| Captura real | Enseñar dónde pulsar o qué campo revisar | Exponer datos o quedarse obsoleta |
| Infografía didáctica | Resumir pasos, requisitos, decisiones o avisos | Inventar una interfaz o simplificar de más |
Si la persona necesita reconocer una pantalla, usamos una captura real. Si necesita comprender un flujo o recordar requisitos, una infografía puede funcionar mejor.
La skill se diseñó para el segundo caso. No debía fabricar pantallas ficticias ni sustituir capturas reales por una versión «parecida». Esa prohibición no salió de una manía estética. Salió del riesgo de que el lector confundiera una ilustración con el producto.
Cuando sí utilizamos capturas reales, fijamos otra regla operativa: ocultar de forma irreversible usuario, avatar, correo, datos fiscales, códigos y cualquier dato personal o interno. No basta con poner un rectángulo editable encima y guardar el archivo de trabajo.
Un recuadro puesto encima en el editor no anonimiza nada: quien abra el archivo de trabajo puede quitarlo. La ocultación tiene que ser irreversible sobre la imagen que se publica.
Paso 4 · Convertir decisiones visuales en una gramática
No congelamos una plantilla. Congelamos una gramática visual. La diferencia importa.
Después de varias piezas empezaron a repetirse decisiones claras: formato horizontal para insertar en un artículo, fondo blanco o muy claro, azules como familia principal, azul oscuro para titulares y gris oscuro para texto secundario, bloques redondeados, iconografía limpia, espacio en blanco suficiente, titulares del tipo PASO X · TÍTULO, entre tres y seis bloques de información y un aviso inferior cuando existe una condición crítica. Sin fotos de stock, sin 3D, sin ilustraciones genéricas, sin estética publicitaria y sin decoración que no ayude a entender.
No congelamos una única plantilla. Congelamos una gramática visual.
Una plantilla rígida obliga a que todas las piezas tengan la misma forma aunque cumplan funciones distintas. Una gramática define las decisiones que mantienen la familia —jerarquía, densidad, paleta, márgenes, iconos y tratamiento de avisos— y después deja que la composición se adapte al contenido.
En la práctica quedaron dos patrones especialmente útiles: tarjetas, para bloques cortos o comprobaciones independientes, y guía visual numerada, para recorridos más largos o secuenciales. Y dentro de la skill agrupamos las piezas por función:
| Tipo | Cuándo se usa | Qué debe priorizar |
|---|---|---|
| Paso | Una acción concreta dentro del proceso | Acción y orden |
| Requisitos | Documentos o condiciones previas | Agrupación y precisión |
| Checklist | Comprobaciones antes de continuar | Lectura rápida |
| Resumen | Vista completa de un flujo | Secuencia y relaciones |
Paso 5 · Separar lo fijo de lo variable
La arquitectura que terminó haciendo útil la skill. Y la parte que sigue siendo humana.
Lo fijo
- La función: crear apoyos didácticos para un Centro de Ayuda.
- La prohibición de inventar.
- Los cuatro tipos de pieza.
- La jerarquía general y el rango de tres a seis bloques.
- La familia visual y la regla de no fabricar interfaces.
- La revisión final.
Lo variable
- El artículo fuente y el título.
- El objetivo de la pieza y los puntos confirmados.
- El país o alcance.
- El aviso crítico.
- Las capturas o recursos oficiales disponibles.
Lo que sigue siendo humano
- Confirmar que la fuente es correcta y vigente.
- Resolver contradicciones entre documentos.
- Decidir si una excepción debe aparecer.
- Revisar cifras, nombres y requisitos.
- Aprobar la pieza antes de publicarla.
Si no puedes separar lo fijo de lo variable, todavía no tienes una skill: tienes una conversación larga.
Paso 6 · Las correcciones que terminaron convertidas en reglas
Las mejores restricciones no salieron de una lluvia de ideas. Salieron de fallos reales.
«No inventes» era demasiado abstracto
Decirle al modelo «no inventes» no especifica qué debe comprobar ni qué hacer cuando falta información. La regla terminó convertida en comportamiento: extraer solo entre tres y seis puntos confirmados, mantener su orden, pedir la información que falte o prescindir del punto, y comprobar textos, cifras, nombres y requisitos antes de entregar.
Facturación no era titularidad
Una formulación visual podía inducir a pensar que cambiar los datos de facturación modificaba el titular de la cuenta. No era correcto. De ahí salió una regla más amplia: no fusionar conceptos operativos diferentes aunque en lenguaje cotidiano parezcan cercanos.
Un caso local no podía convertirse en regla global
Había condiciones específicas por país y recorridos particulares. La skill debía obligar a indicar el alcance y prohibir extrapolar un caso español a otros mercados.
El logotipo no se podía improvisar
Si el recurso oficial no estaba disponible, la salida correcta era trabajar sin logotipo. No redibujarlo, reinterpretarlo ni generar algo «parecido».
Una interfaz inventada podía parecer real
Por eso la skill no genera pantallas de producto. Si hace falta mostrar el producto, se aporta una captura real y se anonimiza.
El texto necesitaba aire
En las iteraciones reales revisamos titulares, cajas y separación. También tuvimos que vigilar que iconos y texto no chocaran y que la composición no quedara cortada al insertarla en la web. De ahí salieron el límite de contenido, el espacio en blanco y la revisión visual de la pieza completa.
Paso 7 · La primera skill se nos fue de madre
Rol, objetivo, fuente de verdad, tipos, estilo, proceso completo, checklist, plantilla… todo dentro.
Cuando vimos que el sistema funcionaba, pedimos una skill muy detallada. La primera propuesta incluía rol, objetivo, fuente de verdad, tipos de imagen, estilo, consistencia, proceso completo, checklist, plantilla de entrada y más explicaciones sobre el proyecto.
Sobre el papel parecía completa. En la práctica tenía un problema: estaba intentando guardar dentro de la skill todo lo que habíamos aprendido. Y puedes aprender mucho durante un proyecto sin que todo tenga que convertirse en una instrucción permanente.
Mi reacción fue bastante menos académica:
Tenía razón. La recortamos hasta conservar solamente lo que cambiaba el comportamiento del modelo:
- Preparar el contenido antes de generar.
- Elegir entre cuatro tipos de pieza.
- Mantener la familia visual.
- No inventar ni extrapolar.
- No crear logotipos o interfaces falsos.
- Revisar la fidelidad antes de entregar.
La poda no debilitó la skill. Le quitó ruido.
Una skill no es el archivo histórico del proyecto: es el procedimiento que se repite
Y buena parte del caos aparece cuando intentamos meterlo todo en el mismo lugar. Cada capa guarda una cosa:
| Capa | Qué guarda en este proyecto |
|---|---|
| Personalización | Mi forma general de trabajar: precisión, no inventar y señalar problemas |
| Proyecto o conversación | El cliente, el artículo, las fuentes y las decisiones del caso actual |
| Skill | El procedimiento repetible para crear las imágenes |
| Petición concreta | El objetivo, los puntos confirmados, el alcance y el aviso de esa pieza |
| Revisión humana | La aprobación del contenido y del resultado final |
Qué hice en Chat y qué hice después en Work
El trabajo se repartió en dos entornos porque no necesitaba lo mismo en cada fase.
En Chat construimos el método
Chat fue útil para trabajar las primeras piezas, corregir textos y conceptos, detectar qué decisiones se repetían, comparar una versión extensa y otra compacta, decidir el alcance exacto de la skill y preparar el texto final que queríamos convertir en habilidad. En esta fase todavía estábamos pensando y decidiendo.
En Work revisamos el artefacto
Cuando la skill ya tenía un alcance claro, la llevamos a Work para revisar su estructura completa, afinar la descripción que permite activarla con peticiones reales, convertir la prohibición de inventar en comprobaciones operativas, validar que solo tenía las instrucciones necesarias e instalarla en Complementos > Habilidades.
La skill instalada conservó cuatro núcleos: extracción previa, tipos de imagen, límites estrictos de fidelidad y revisión final.
La versión instalada para el cliente vive en una URL propia de la cuenta. Ese enlace no se publica sin confirmar antes sus permisos y sin decidir si compartimos una versión pública separada. La interfaz de ChatGPT también cambia: por eso el tutorial va con capturas fechadas y enlaza la documentación oficial.
Instalarla, una vez claro el alcance, fueron tres pasos. Estas capturas son reales y están anonimizadas: la interfaz puede cambiar, así que van fechadas al 21 de septiembre de 2026.
Complementos > Habilidades
SKILL.md
SKILL.md.
Cómo saber si la skill funciona de verdad
Instalar una skill no demuestra que funcione. Hay que cambiar el contenido sin cambiar el tipo de trabajo.
La prueba buena no consiste en repetir el mismo ejemplo con palabras parecidas. La batería mínima es un paso concreto, una checklist con un aviso crítico, un bloque de requisitos y un resumen de flujo (solo si realmente aporta claridad). Y la evaluación debe separar contenido y diseño.
Control de fidelidad
- ¿Todos los textos salen de la fuente?
- ¿Se ha añadido algún requisito? ¿Se mantiene el orden?
- ¿El alcance geográfico o funcional es correcto?
- ¿Se ha convertido una excepción en regla?
- ¿Aparece algún dato privado, URL o elemento no solicitado?
Control visual
- ¿Las piezas parecen de la misma familia?
- ¿Cada composición se adapta a su función? ¿Hay suficiente aire?
- ¿El texto se lee al tamaño real de publicación?
- ¿Hay colisiones entre iconos, titulares o cajas? ¿La web recorta algún elemento?
Control de utilidad
- ¿La imagen ayuda a ejecutar, comprobar o entender, o solo repite el artículo con dibujos?
- ¿El aviso importante se ve?
- ¿Podría eliminarse un bloque sin perder información necesaria?
No voy a afirmar que la versión pública es reutilizable solo porque el paquete se instaló correctamente. Una skill se valida cuando mantiene el método al cambiar la fuente.
Cómo usarla después sin volver a contarle la vida al modelo
Una vez instalada, la petición puede ser corta porque las reglas repetitivas ya viven en la skill:
Usa la skill de imágenes operativas para Centros de Ayuda. TIPO: Checklist TÍTULO: Revisa los datos de facturación OBJETIVO: Que la persona compruebe la información antes de continuar ALCANCE: Empresas registradas en España PUNTOS CONFIRMADOS: - [Punto 1] - [Punto 2] - [Punto 3] AVISO: [Condición importante, si existe]
Qué automatiza la skill y qué no le delego
Reduce trabajo repetitivo. No convierte una fuente dudosa en válida ni asume la responsabilidad editorial.
| La skill puede repetir | Sigue necesitando control humano |
|---|---|
| Formato y jerarquía | Vigencia de la fuente |
| Tipo de composición | Contradicciones entre documentos |
| Cantidad de información | Cifras, nombres y requisitos |
| Tratamiento de pasos y avisos | Alcance por país o producto |
| Familia visual | Excepciones operativas |
| Comprobación previa a la entrega | Aprobación para publicar |
También merece documentarse lo que dejamos fuera: la historia completa del cliente, todos los artículos del Centro de Ayuda, datos operativos de un caso concreto, códigos, usuarios, URLs privadas o nombres, normativa que puede cambiar, una plantilla rígida para cada posible imagen, funciones publicitarias y la maquetación del artículo donde se insertarán las imágenes.
Cada añadido permanente tiene un coste. Puede aumentar la ambigüedad, crear conflictos con otras reglas o hacer que la habilidad se active para tareas que no le corresponden.
Cómo adaptaría el método a otro cliente
No copiaría la skill, cambiaría el azul por otro color y daría el trabajo por terminado.
Haría esto:
- Elegir una tarea repetitiva concreta. Por ejemplo, imágenes de requisitos para un Centro de Ayuda. No «todo el diseño de la empresa».
- Reunir varios casos reales. Necesitas variedad para distinguir una regla de una coincidencia.
- Ejecutar el trabajo antes de documentarlo. Las primeras piezas sirven para descubrir el sistema.
- Registrar correcciones y clasificarlas: ¿fallo puntual del contenido, regla del cliente, regla general del proceso? ¿Pertenece a la skill o a la petición?
- Separar contenido y estilo. Una afirmación incorrecta y una jerarquía visual mala son problemas distintos y se revisan por separado.
- Definir lo fijo y lo variable. Si no puedes distinguirlos, todavía no tienes una skill.
- Escribir la versión mínima útil. Solo las reglas que evitan fallos reales o ahorran decisiones repetidas.
- Probar con fuentes diferentes. Cambiar el texto es la única forma de comprobar si el método se sostiene.
- Instalar, usar y volver a podar. Si una instrucción no cambia el resultado, sobra. Si un fallo se repite y no está cubierto, falta una regla.
Cuándo no crearía una skill
No la crearía si la tarea no se va a repetir, si cada entrega necesita una dirección creativa completamente distinta, si las fuentes todavía se contradicen, si el proceso del cliente cambia cada semana, si no hay ejemplos reales suficientes, si la única instrucción estable es «que quede bonito» o si todavía no sabemos cómo evaluar una buena salida. En esos casos seguiría trabajando en el proyecto hasta que aparezca un patrón real.
La skill pública y anonimizada
Conserva el núcleo operativo de la skill instalada, pero elimina nombre, paleta, recursos privados y cualquier referencia al cliente.
No pretende resolver todas las imágenes de una empresa. Está diseñada para una tarea concreta: crear apoyos visuales horizontales para artículos de un Centro de Ayuda a partir de información confirmada. Puedes adaptarla a un cliente añadiendo únicamente la capa visual aprobada y, si existen, ejemplos de referencia. No metas la empresa entera dentro.
--- name: help-center-images description: Crea imágenes horizontales didácticas para artículos de un Centro de Ayuda. Úsala para explicar pasos, requisitos, comprobaciones, checklists o flujos con información confirmada en el artículo o material aportado, manteniendo una familia visual coherente y sin inventar datos ni interfaces. --- # Help Center Images Crear apoyos visuales que aclaren un proceso y reduzcan errores de usuario. No crear piezas publicitarias ni imágenes que dupliquen texto sin aportar comprensión. ## Preparar el contenido Antes de generar, extraer únicamente: - Título - Objetivo de la imagen - Entre tres y seis puntos confirmados - Aviso importante, si existe Eliminar el resto. Mantener el orden del artículo. Si falta información necesaria, pedirla o prescindir del punto: no completar huecos mediante inferencias. Si el proceso depende de un país, indicar el alcance con precisión. No extrapolar un caso local a otros países. ## Elegir el formato - Paso: una acción concreta - Requisitos: documentación o condiciones previas - Checklist: comprobación antes de continuar - Resumen: flujo completo No generar una imagen solo porque exista un bloque de texto. Hacerlo cuando el formato visual facilite una decisión, una acción o una comprobación. ## Diseño Mantener una familia visual homogénea: - Formato horizontal y fondo blanco o muy claro - Color principal de la marca para jerarquía y titulares; gris oscuro para texto secundario - Bloques redondeados, iconografía limpia y espacio en blanco generoso - Diseño corporativo, actual y didáctico - Sin fotografías de stock, estética infantil ni decoración irrelevante - Poco texto: resumir, no duplicar el artículo En piezas de un mismo artículo, conservar estructura, jerarquía, tipografías, iconos, márgenes y tratamiento visual. Para una guía paso a paso, usar el patrón PASO X · TÍTULO. Después, presentar de tres a seis bloques: icono, titular y explicación breve. Añadir un aviso inferior solo si existe una condición relevante. ## Límites de fidelidad - Usar exclusivamente información confirmada en el artículo, documentación o material proporcionado. - No inventar pasos, requisitos, documentos, funcionalidades, precios, normativa, interfaces, URLs ni condiciones. - No generar ni reinterpretar el logotipo de la marca salvo que se proporcione el recurso oficial. - No crear interfaces falsas que puedan confundirse con pantallas reales. - No mostrar URLs largas dentro de la imagen salvo solicitud expresa. ## Revisión antes de entregar - Comprobar cada texto, cifra, nombre y requisito contra el material fuente. - Confirmar que no se ha añadido información ni un logotipo inventado. - Verificar la coherencia con la serie y la comprensión rápida de la pieza. La imagen debe simplificar la comprensión del proceso sin simplificar ni modificar la información.
@ en una nueva tarea.- La tarea está definida en una frase.
- Has creado varias piezas reales antes de escribir la skill.
- Sabes qué decisiones son fijas y cuáles cambian.
- La fuente de verdad está identificada.
- La skill explica qué hacer cuando falta información.
- No contiene datos privados del primer caso.
- No intenta resolver publicidad, interfaces y documentación a la vez.
- La descripción permite saber cuándo debe activarse.
- Existe una revisión final comprobable.
- La has probado con al menos tres tipos de contenido.
- Has eliminado las instrucciones que no cambian el resultado.
La skill fue el último paso, no el primero
Antes hubo contenido aprobado, piezas manuales, errores, correcciones, decisiones visuales, límites y una poda bastante seria. Lo valioso no fue escribir un archivo con instrucciones. Fue descubrir qué parte del trabajo podía repetirse sin perder precisión.
Ahora no tengo que volver a explicar la familia visual, la densidad, los tipos de pieza, la prohibición de inventar o la revisión final cada vez que aparece un artículo nuevo. Sigo aportando la fuente. Sigo revisando el resultado. Sigo decidiendo qué merece una imagen. Pero ya no reconstruyo el sistema desde cero.
Eso es lo que una skill bien hecha me resuelve.
Mili Pérez
Te aviso cuando publique lo siguiente
Cuento cómo trabajo con IA desde las trincheras: skills, proyectos, sistemas de imágenes y las reglas que uso para que no invente. Sin humo y con casos reales.