Design-Assets exportieren mit einem Agenten, den Designer anschreiben können

Eine Asset-Export-Pipeline ist die Kette von einer Designdatei hin zu Dateien, die ein Build verwenden kann: Exportieren, Größe anpassen, optimieren, umbenennen, platzieren. Es ist genau die Art von wiederholbarer, dateilastiger Arbeit, die ein Coding-Agent hervorragend erledigt – und genau die Art von Arbeit, die liegen bleibt, weil Designer erst Entwickler bitten müssen, sie auszuführen. Ein Agent, der auf den Assets-Ordner gepinnt und in einem Raum erreichbar ist, macht diese Bitte überflüssig.

Die Anfrage

„@assets exportiere das Icon-Set aus der Designdatei in 1x, 2x und 3x, optimiere es und lege es in /public/icons ab. Poste eine Kontaktabzug-Übersicht.“

Was der Agent tut

1. Ruft die API des Design-Tools auf, um die aktuellen Icon-Komponenten abzurufen.
2. Exportiert die drei Skalierungen in einen temporären Ordner.
3. Führt den Optimierer aus, der bereits auf dem Rechner installiert ist.
4. Benennt die Dateien nach der Konvention des Projekts um, die in der README.md des Ordners dokumentiert ist.
5. Verschiebt die Dateien nach /public/icons und ersetzt das vorherige Set.
6. Erstellt ein Kontaktabzug-Bild und postet es zusammen mit der Anzahl in den Raum.

Der Designer sieht jeden Schritt in der Timeline und am Ende das Übersichtsbild. Gesamtdauer: etwa eine Minute.

Was pausiert

Schritt 1 liest das API-Token des Design-Tools aus. Das ist eine Credential-Aktion, daher pausiert sie beim ersten Mal für den Besitzer mit einer Karte, die zeigt, wer gefragt hat und was der Agent lesen möchte. Der Besitzer genehmigt es; das Token verlässt den Rechner nie und der Designer bekommt es nicht zu Gesicht. Siehe vier Aktionen, bei denen ein Agent immer vorher fragen sollte.

Würde der Agent die neuen Icons auch committen und nach main pushen wollen, würde das ebenfalls pausieren. Die meisten Teams lassen ihn stattdessen auf einen Branch committen und einen Pull Request erstellen, was nicht pausiert.

Die Einrichtung

• Ein Agent, ein Ordner. Pinne assets auf das Design-Assets-Verzeichnis des Repositorys oder auf einen dedizierten Export-Ordner, falls der Agent außerhalb des Codes bleiben soll.
• Halte die Konventionen schriftlich fest. Eine README.md mit dem Benennungsschema, Größen, Formaten und Zielpfaden. Der Agent liest sie jedes Mal.
• Berechtigungsmodus acceptEdits. Dateien zu schreiben ist seine Aufgabe; Befehle fragen weiterhin nach. Siehe Berechtigungsmodi erklärt.
• Dauerhafte Freigabe für Designer. Einmalige Bestätigung pro Person, danach können sie frei anfragen.
• Behalte das Token auf dem Rechner, am üblichen Konfigurationsort des Tools. Füge es nicht in die Anfrage oder die README ein.

Variationen

Warum ein Raum und kein Skript

Ein Skript erledigt den Export. Ein Raum ermöglicht es der Person, die die Änderung bemerkt, sie anzustoßen, zu beobachten und das Ergebnis zu erhalten – ohne Terminal, Ticket oder Entwickler im Routinefall, während Nicht-Routine-Fälle (Credentials, Löschvorgänge, Pushes) weiterhin beim Besitzer stoppen. Außerdem bleibt dokumentiert, wer was wann exportiert hat. Siehe Coding-Agenten können mehr als nur Code.

Häufig gestellte Fragen

Benötigt der Designer API-Zugriff auf das Design-Tool? Nein. Das Token liegt auf dem Rechner des Besitzers und der Agent nutzt es dort. Der Designer fragt an; der Besitzer bestätigt das Auslesen der Credentials.

Kann der Agent einen Pull Request öffnen? Ja, sofern sich das Verzeichnis des Agenten innerhalb des Repositorys befindet und er git-Zugriff auf dem Rechner hat. Einen PR auf einem Branch zu eröffnen pausiert nicht; das Pushen auf einen geteilten Branch hingegen schon.

Was, wenn der Designer das Benennungsschema ändern möchte? Einfach die README im Ordner bearbeiten oder den Agenten darum bitten. Er liest die Konventionen bei jeder Anfrage neu ein.

Der Export dauert eine Minute. Das Warten war das Problem. Gib deinem Assets-Agenten einen Raum.