Uma pipeline de exportação de recursos é a cadeia desde um ficheiro de design até aos ficheiros que um build pode utilizar: exportar, redimensionar, otimizar, renomear, colocar. É exatamente o tipo de trabalho repetível e focado em ficheiros que um agente de programação faz bem, e exatamente o tipo de trabalho que empaca porque o designer tem de pedir a um engenheiro que o execute. Um agente fixado na pasta de recursos, acessível numa sala, elimina esse pedido intermediário.
O pedido
“@assets exporta o conjunto de ícones do ficheiro de design a 1x, 2x e 3x, otimiza e coloca-os em /public/icons. Publica uma folha de contacto.”
O que o agente faz
- Chama a API da ferramenta de design para obter os componentes de ícones atuais.
- Exporta nas três escalas para uma pasta temporária.
- Executa o otimizador já instalado na máquina.
- Renomeia segundo a convenção do projeto, que está descrita no
README.mdda pasta. - Move os ficheiros para
/public/icons, substituindo o conjunto anterior. - Gera uma imagem de folha de contacto e publica-a na sala com uma contagem.
O designer vê cada passo na timeline e a folha de contacto no final. Tempo total: cerca de um minuto.
O que pausa
O passo 1 lê o token de API da ferramenta de design. Trata-se de uma ação de credenciais, pelo que pausa à espera do proprietário da primeira vez, com um cartão a mostrar quem pediu e o que o agente quer ler. O proprietário aprova; o token nunca sai da máquina e o designer nunca o vê. Consulte quatro ações que um agente deve sempre pedir antes de executar.
Se o agente também quisesse fazer commit e push dos novos ícones para a main, isso também pausaria. A maioria das equipas prefere que ele faça commit para um branch e abra um pull request, o que não pausa.
Como configurar
- Um agente, uma pasta. Fixe
assetsno diretório de recursos de design do repositório do site, ou numa pasta de exportações dedicada se preferir manter o agente fora do código. - Registe as convenções por escrito. Um
README.mdcom o esquema de nomenclatura, tamanhos, formatos e caminhos de destino. O agente lê-o sempre. - Modo de permissão
acceptEdits. Escrever ficheiros é a tarefa principal; os comandos continuam a pedir autorização. Consulte modos de permissão explicados. - Autorização permanente para os designers. Uma aprovação para cada um, e depois pedem livremente.
- Mantenha o token na máquina, na localização de configuração habitual da ferramenta. Não o cole no pedido nem no README.
Variações
Porquê uma sala e não um script
Um script faz a exportação. Uma sala permite que a pessoa que repara na alteração a desencadeie, acompanhe e obtenha o resultado, sem um terminal, um ticket ou um engenheiro envolvido no caso rotineiro, enquanto os casos não rotineiros (credenciais, eliminações, pushes) continuam a parar para o proprietário. Também deixa um registo de quem exportou o quê e quando. Consulte os agentes de programação fazem mais do que código.
Perguntas frequentes
O designer precisa de acesso à API da ferramenta de design? Não. O token está na máquina do proprietário e o agente utiliza-o lá. O designer faz o pedido; o proprietário aprova a leitura de credenciais.
O agente pode abrir um pull request? Sim, se o diretório do agente estiver dentro do repositório e este tiver acesso ao git na máquina. Abrir um PR num branch não pausa; fazer push para um branch partilhado pausa.
E se o designer quiser alterar o esquema de nomenclatura? Edite o README na pasta ou peça ao agente para o fazer. Ele relê as convenções a cada pedido.
A exportação é um minuto de trabalho. A espera é que era o problema. Dê uma sala ao seu agente de recursos.
Publicado a