Der Design Skill Atlas

„Make it look good“ ist kein brauchbarer Auftrag für einen Agenten. Die Aufforderung bündelt Recherche, visuelle Richtung, Umsetzung und Qualitätsurteil in einem Satz. Das Ergebnis ist oft ordentlich, aber austauschbar: ein bekanntes Layout, ein paar Karten, eine Dekoration, die nirgends im Produkt verankert ist.

Der bessere Auftrag beginnt eine Ebene früher: In welcher Arbeitssituation stehe ich gerade, und welche öffentliche Fähigkeit hilft genau dort? Der Design Skill Atlas ordnet öffentlich auffindbare Skills nach Prozessphase, Aufgabe, Quelle und Installierbarkeit. Er ist kein Werkzeugkasten, der alles gleichzeitig aktiviert. Er soll die nächste Entscheidung kleiner und überprüfbar machen.

Öffne den Design Skill Atlas →

Warum „make it look good“ scheitert

Ein einzelner Prompt kann nicht zuverlässig entscheiden, ob zuerst die visuelle Richtung fehlt, der bestehende Screen unverständlich ist oder die Umsetzung gegen das Designsystem verstößt. Diese Fragen verlangen verschiedene Inputs und andere Qualitätskriterien.

Das ist der Mechanismus hinter generischem Output: Wenn ein Agent gleichzeitig eine Richtung erfinden, Komponenten bauen und das Resultat bewerten soll, greift er auf häufige Muster zurück. Ohne Brief, vorhandene Tokens oder Screenshot-Evidenz gewinnt die wahrscheinlichste Oberfläche, nicht die passendste.

Der Atlas trennt diese Jobs. So wird aus „schöner machen“ zum Beispiel „prüfe die Hierarchie dieses Checkout-Screens bei 390 px“ oder „lege vor dem Build zwei visuelle Richtungen mit ihren Trade-offs vor“. Das ist weniger poetisch, aber testbar.

Der Prozess ist eine Landkarte

Die Phasen Discover, Define, Build, Refine, Review und Ship sind Einstiegskontexte, keine verpflichtende lineare Pipeline. Wer einen bestehenden Screen vor sich hat, kann bei Review anfangen. Wer nur ein Produktbriefing hat, startet bei Discover. Nach einem Review kann die nächste sinnvolle Arbeit wieder Define sein, wenn die Markenentscheidung fehlt.

Die Landkarte grenzt damit die Kandidaten ein, statt einen Ablauf vorzutäuschen. Ein Skill für eine visuelle Richtung ist nützlich, wenn die Richtung offen ist. Ein Audit ist nützlich, wenn es bereits eine sichtbare Oberfläche gibt. Dazwischen liegt kein Ritual, sondern ein Kontextwechsel.

Im Atlas stehen deshalb nicht nur Phasen, sondern auch Aufgabe, öffentliche Quelle, Lizenzlage, Installierbarkeit und Runtime. Diese Felder machen aus einer Sammlung einen prüfbaren Entscheidungsraum: Vor der Installation ist sichtbar, ob die Quelle öffentlich ist, ob die Nutzung geklärt wurde und für welche Umgebung die Hinweise verifiziert sind.

Drei Arten, Skills zu wählen

Nicht jede Ähnlichkeit bedeutet Austauschbarkeit. Im Atlas gibt es drei Beziehungsarten:

• Zusammen einsetzen: Zwei Fähigkeiten decken unterschiedliche Teile derselben Arbeit ab. Ein visueller Review kann zum Beispiel mit einer Browser-Prüfung kombiniert werden, weil der eine Befunde priorisiert und die andere reale Zustände, Viewports und Interaktionen überprüft.
• Nach Kontext wählen: Mehrere Skills lösen ein ähnliches Problem, aber mit unterschiedlichem Ausgangspunkt. Entscheidend sind vorhandene Artefakte, Plattform und die Frage, ob eine Richtung noch offen ist oder schon ein Interface bewertet werden soll.
• Genau einen wählen: Starke, konkurrierende Stilrichtungen oder alternative Implementierungswege sollten nicht gleichzeitig dominieren. Sonst entsteht ein Interface ohne klare Entscheidung.

Diese Unterscheidung spart mehr Zeit als eine längere Liste. Sie verhindert, dass ein Agent fünf Reviews übereinanderlegt oder eine Richtungsentscheidung mit einer nachträglichen Politur verwechselt.

Was Agent OS dabei macht

Ein Agent OS muss dafür keine Designentscheidung automatisieren. Seine Aufgabe ist kleiner: Es hält den Katalog auffindbar, prüft die öffentliche Quelle und zeigt, welche Fähigkeiten zusammenpassen, Alternativen sind oder sich widersprechen.

Der wichtige Teil ist die Aktualisierung. Ein Katalog ist nur so gut wie sein letzter Abgleich. Für einen Review öffne ich die öffentliche Originalquelle jedes betroffenen Eintrags erneut, prüfe Phase, Aufgabe, Lizenz, Installation und Runtime und markiere nicht mehr erreichbare Quellen als verborgen statt sie still zu ersetzen. Erst danach laufen Katalog-, Filter- und Build-Checks; dann wird das Änderungsdatum aktualisiert.

Der aktuelle Abgleich zeigt, warum das wichtig ist. In meiner Agent-OS-Designkarte standen 47 Einträge. Vier davon sind eigene, nicht öffentliche Skills und bleiben draußen. Elf ältere Impeccable-Einträge sind heute keine eigenständigen Skills mehr, sondern Unterkommandos eines öffentlichen Skills. Ein weiterer gstack-Eintrag existiert in der aktuellen öffentlichen Quelle nicht mehr. So werden aus 47 lokalen Darstellungen 32 aktuelle öffentliche Agent-OS-Skills. Zusammen mit elf zusätzlichen öffentlichen Funden enthält der Atlas jetzt 43 kanonische Skills.

Das schützt vor einem stillen Fehler: Ein Name bleibt im Katalog, aber die Quelle, Installationsanleitung oder Runtime hat sich geändert. Ohne Refresh bekommt man einen plausiblen Vorschlag für ein Werkzeug, das im aktuellen Setup nicht mehr existiert.

Was der Audit im echten Projekt verändert hat

Der Atlas ist aus einem realen Audit der marosch studio Website entstanden. Dort wurden sechs Dimensionen parallel geprüft: visuelle Qualität, Motion, Accessibility, Code-Qualität, UX und Web-Compliance. Die erste Serie umfasste 36 Punkte über drei Tiers. Ein anschließender Tier-4-Pass prüfte Fokus, Motion, Layout und Typografie.

Das Resultat waren 60 von 60 erledigten Empfehlungen. Zehn weitere wurden bewusst verworfen. Das ist kein Makel im Audit, sondern die Kontrollstelle: Eine Empfehlung ist ein Vorschlag mit Kosten und Nebenwirkungen, keine Anweisung. Eine bewusst verworfene Empfehlung zeigt, dass jemand den Kontext, den Nutzen und den Trade-off geprüft hat.

Die drei Commit-Nachrichten im Bild sind die verifizierbare Spur dieses Runs. Sie belegen den Umfang, den zusätzlichen Fokus-Pass und den Abschluss. Sie belegen nicht, dass dieselbe Reihenfolge für jedes Produkt richtig wäre.

Wo der Atlas bricht

Der Atlas kann die Auswahl eingrenzen, aber er hat keinen Geschmack und keinen Zugang zu unausgesprochenen Produktentscheidungen. Ein bewusst reduziertes Interface kann in einem Audit wie zu wenig Hierarchie aussehen. Eine zusätzliche Ebene oder stärkere Farbe wäre dann kein Fortschritt, sondern ein Fehlurteil mit sauberer Begründung.

Er bricht auch bei veralteten Daten. Öffentlich verfügbare Skills werden umbenannt, verschoben oder anders installiert. Deshalb ist die Refresh-Methode Teil des Produkts, nicht eine Wartungsnotiz. Ein Eintrag ohne aktuelle Quelle muss sichtbar eingeschränkt bleiben, bis die Quelle erneut geprüft ist.

Die Grenze ist absichtlich: Der Atlas empfiehlt Kandidaten und macht ihre Herkunft sichtbar. Die Verantwortung für Brief, Priorität und Abnahme bleibt beim Menschen, der das Produkt und seine Nutzer kennt.

Starte bei deinem aktuellen Job

Öffne nicht mit einer langen Liste. Nimm einen Screen oder eine anstehende Designentscheidung und beantworte drei Fragen:

1. Wo stehe ich? Richtung offen, System definieren, Interface bauen, bestehende Oberfläche verfeinern, prüfen oder ausliefern?
2. Welche Evidenz habe ich? Brief, Design-Tokens, funktionierender Screen, Screenshot oder echte Nutzerrückmeldung?
3. Welche Wahlbeziehung gilt? Brauche ich ein Paar, eine kontextabhängige Alternative oder genau eine klare Richtung?

Wähle danach im Atlas einen öffentlichen Kandidaten, prüfe die Quelle und definiere vor dem Start einen kleinen Abnahmetest: etwa einen Screenshot bei zwei Viewports, eine Tastaturprüfung oder eine Entscheidung zwischen zwei klar benannten Richtungen. So wird aus einer Skill-Sammlung ein Arbeitsmittel für den Job, der gerade vor dir liegt.

Starte bei deinem aktuellen Designjob im Atlas →