Un pipeline de exportación de assets es la cadena que va desde el archivo de diseño hasta los archivos que la compilación puede usar: exportar, redimensionar, optimizar, renombrar y colocar. Es justo el tipo de tarea repetitiva y llena de archivos que un agente de código hace bien, y justo el tipo de trabajo que se atasca porque el diseñador tiene que pedirle a un ingeniero que lo ejecute. Un agente anclado a la carpeta de assets, disponible en una sala, elimina esa fricción.
La solicitud
“@assets exporta el set de iconos del archivo de diseño a 1x, 2x y 3x, optimízalos y colócalos en /public/icons. Publica una hoja de contactos”.
Qué hace el agente
- Llama a la API de la herramienta de diseño para obtener los componentes de iconos actuales.
- Los exporta a las tres escalas en una carpeta temporal.
- Ejecuta el optimizador ya instalado en la máquina.
- Los renombra según la convención del proyecto, que está descrita en el
README.mdde la carpeta. - Mueve los archivos a
/public/icons, sustituyendo el set anterior. - Genera una imagen con la hoja de contactos y la publica en la sala con el recuento.
El diseñador ve cada paso en la cronología y la hoja de contactos al final. Tiempo total: alrededor de un minuto.
Qué se pausa
El paso 1 lee el token de la API de la herramienta de diseño. Esa es una acción de tipo credential, por lo que la primera vez se pausa para el propietario, mostrando una tarjeta con quién lo solicitó y qué quiere leer el agente. El propietario aprueba; el token nunca sale de la máquina y el diseñador nunca lo ve. Consulta cuatro acciones que un agente siempre debería consultar antes de ejecutar.
Si el agente también quisiera hacer commit y push de los nuevos iconos a main, eso también se pausaría. La mayoría de los equipos prefieren dejar que haga commit en una rama y abra un pull request en su lugar, lo cual no se pausa.
Configuración
- Un agente, una carpeta. Ancla
assetsal directorio de assets de diseño del repositorio del sitio, o a una carpeta de exportación dedicada si prefieres mantener al agente fuera del código. - Deja las convenciones por escrito. Un
README.mdcon el esquema de nomenclatura, tamaños, formatos y rutas de destino. El agente lo lee cada vez. - Modo de permisos
acceptEdits. Escribir archivos es su trabajo; los comandos siguen pidiendo confirmación. Consulta modos de permisos, explicados. - Autorización permanente para los diseñadores. Una sola aprobación para cada uno y después pueden pedir lo que necesiten sin esperas.
- Mantén el token en la máquina, en la ubicación habitual de configuración de la herramienta. No lo pegues en la solicitud ni en el README.
Variaciones
Por qué una sala y no un script
Un script se encarga de la exportación. Una sala permite que la persona que detecta el cambio lo active, lo supervise y obtenga el resultado, sin terminales, tickets ni ingenieros de por medio en los casos rutinarios, mientras que los casos no rutinarios (credenciales, eliminaciones, pushes) siguen deteniéndose para pedir confirmación al propietario. Además, deja constancia de quién exportó qué y cuándo. Consulta los agentes de código hacen más que escribir código.
Preguntas frecuentes
¿Necesita el diseñador acceso a la API de la herramienta de diseño? No. El token está en la máquina del propietario y el agente lo usa allí. El diseñador lo solicita; el propietario aprueba la lectura de las credenciales.
¿Puede el agente abrir un pull request? Sí, si el directorio del agente está dentro del repositorio y tiene acceso a git en la máquina. Abrir una PR en una rama no se pausa; hacer push a una rama compartida sí.
¿Y si el diseñador quiere cambiar el esquema de nomenclatura? Edita el README de la carpeta o pídeselo al agente. Lee las convenciones desde cero en cada solicitud.
La exportación lleva un minuto de trabajo. El problema era la espera. Dale una sala a tu agente de assets.
Publicado el