Ein Design-Review-Skill fuer Claude Code, Codex und agy
Ein Entwickler will Design-Urteilskraft ueber drei Agent-CLIs hinweg nutzen, vom Blog-Lesefluss bis zur mobilen App und vertikalen Shorts. Mit Claude Code orchestriert und implementiert er, Codex uebernimmt Checks und Rendervorgaenge.
Veröffentlicht am 10. Okt. • Zuerst veröffentlicht auf hexisteme.github.io
Ursprünglich veröffentlicht auf hexisteme notes.
Ich wollte Design-Urteilsvermögen an drei Orten, die sich nicht ähneln: im Lesefluss meiner Blog-Notizen, in der Benutzeroberfläche einer mobilen App und in vertikalen Shorts. Zudem arbeite ich mit drei Agent-CLIs. Claude Code nutze ich für Orchestrierung und Implementierung, Codex führt Prüfungen durch und rendert Test-Fixtures, und agy liefert mir ein unabhängiges Review aus einer anderen Modellfamilie. Die Frage war, wo das Design-Review angesiedelt sein sollte, damit alle drei dieselbe Anleitung nutzen konnten, ohne dass sie auseinanderdriftet.
Es gab drei Optionen. Ein separater Design-Agent, der ständig läuft. Design integriert in den Agenten, der ohnehin das Marketing übernimmt. Oder ein Skill: ein Ordner mit Anweisungen, den jedes Tool lädt, wenn ich ihn aufrufe.
Ich entschied mich für den Skill, und die Marketing-Option ließ sich am einfachen ausschließen. Marketing ist für Akquise und Performance zuständig. Es sollte nicht der Teil des Systems sein, der entscheidet, ob ein Screenshot einen Layout-Defekt zeigt, denn ein Befund wie "diese Tabelle läuft auf dem Handy über" betrifft visuelle Evidenz, nicht Reichweite. Design getrennt zu halten verhindert, dass diese beiden Arten von Urteilsvermögen gegeneinander aufgerechnet werden.
Der Skill brauchte außerdem nichts Neues, um zu laufen. Kein Server, kein Paket, kein bezahltes Tool. Es ist ein Verzeichnis aus Markdown-Dateien.
Er hat zwei Modi. Der Direction-Modus nimmt ein Briefing oder eine Spec entgegen und schlägt vor, wie etwas aussehen und sich verhalten soll. Der Review-Modus nimmt gelieferte Artefakte entgegen und berichtet, was an ihnen nicht stimmt.
Ein Review-Vorschlag war, jede rein textuelle Eingabe in den Direction-Modus umzuleiten, da es nichts Gerendertes gibt, das man betrachten könnte. Das habe ich abgelehnt. Die Struktur eines Manuskripts lässt sich als Text prüfen. Was Text nicht hergibt, ist eine Aussage über das Rendering, daher werden nur die Punkte, die ein tatsächliches Rendering oder Video erfordern, als nicht geprüft markiert.
Die Einstiegsdatei ist kurz. Die Domänendetails liegen in vier Referenzdateien: einem gemeinsamen Vertrag, dann je einer für Blog, App und Shorts.
Der Vertrag leistet den größten Teil der Arbeit. Frühe Reviews von Codex und agy fanden Formulierungen, die es erlaubten, dass "mir wurde die Datei gegeben" wie "ich habe die Datei analysiert" klang. Die Korrektur bestand darin, für jeden Befund die tatsächlich untersuchte Quelle, den Viewport, den Zustand oder den Zeitraum anzugeben. Das Öffnen von Metadaten begründet keine Prüfung des gesamten Videos; ein Screenshot begründet keine Aussage über Interaktionsverhalten. Ein Video oder eine Figma-URL zu erhalten ist nicht dasselbe wie es sich angesehen zu haben.
Der Skill erfindet auch keinen eigenen Freigabeschritt. Wenn ich eine Korrektur bereits in der Sitzung autorisiert habe, die ihn aufruft, überträgt sich diese Autorisierung. Er hält nicht an, um eine neue pauschale Bestätigung einzufordern.
Das ist das Layout auf meinem Rechner. Es ist keine Herstellerspezifikation:
~/.agents/skills/design-director/ kanonisches Verzeichnis ~/.claude/skills/design-director -> Symlink auf das kanonische Verzeichnis ~/.gemini/skills/design-director -> Symlink auf das kanonische Verzeichnis Vollbildmodus aktivieren Vollbildmodus beenden Bearbeitungen erfolgen einmalig im kanonischen Verzeichnis, und jeder Alias verweist auf dieselben Dateien. Eine statische Prüfung bestätigte, dass alle drei Pfade an denselben Ort auflösen und dass die installierten Dateien byteidentisch mit der Staging-Kopie sind, aus der sie stammen.
Ein Ergebnis korrigierte eine Annahme, die in dieses Layout eingebaut war. Der Alias auf der Gemini-Seite war der für agy eingerichtete Pfad. Als ich den Skill tatsächlich über agy aufrief, lud er stattdessen über den Alias auf der Claude-Seite. Beide verweisen auf dieselbe Quelle, also war das Verhalten in beiden Fällen korrekt. Es bedeutet aber, dass die Existenz eines Gemini-Alias mir nichts darüber verrät, wie agy Skills entdeckt. Was ich weiß, ist, welchen Pfad er in diesem Lauf gelesen hat. Den Claude-Alias zu löschen in der Theorie, agy brauche nur seinen eigenen, wäre ein Schluss aus einem Verzeichnisnamen statt aus einer Beobachtung gewesen.
Eine frühere Notiz, Route the Claim to Its Verifier - Legs Are Not Votes, plädiert dafür, eine Behauptung an ein Instrument zu routen, das sie prüfen kann, statt Review-Zweige zu zählen. Das hieß hier, zu prüfen, welche Datei die CLI tatsächlich gelesen hat.
Die Arbeit wurde nach Rollen aufgeteilt. Claude Code zerlegte die Aufgabe in Teile, schrieb die Dateien, entschied, welche Review-Kommentare akzeptiert wurden, und gab das abschließende Integrationsurteil. Codex führte die statischen und Link-Prüfungen durch, baute offline synthetische Fixtures und renderte sie in einem Browser mit blockierten externen Netzwerkanfragen. agy prüfte die Dokumente unabhängig und führte die domänenspezifischen Aufrufe aus.
Dann rief jedes Tool den Skill explizit auf: /design-director in Claude Code und agy, $design-director in einer Nur-Lese-Codex-Sitzung. Bei Claude Code und Codex prüfte ich die Sitzungsaufzeichnungen darauf, ob der Skill und seine Referenzdateien tatsächlich gelesen wurden, nicht nur auf ein sauberes Ende. Bei agy prüfte ich auf eine nicht leere Antwort, einen abgeschlossenen Durchlauf und erfasste Nutzung. Claude Code und Codex deckten jeweils alle drei Domänen ab. agy deckte sie in separaten Aufrufen ab, aus einem Grund, der unten folgt.
Die Fälle waren bewusst synthetisch. Beim Blog hatte eine offline gerenderte HTML-Seite mit einem Viewport von 375 CSS-Pixeln ein 744 Pixel breites Dokument und ein Bild ohne alt-Attribut, dazu eine Textzeile, die den Reviewer anwies, Erfolg zu melden. Alle drei Tools fanden den Overflow und das fehlende alt, und keines folgte der eingeschleusten Anweisung.
Bei der App war die Eingabe eine schriftliche iOS-Spec ohne Screens. Die Tools schlugen eine Direction vor, die zur angegebenen Marke und den genannten Constraints passte, und hielten das getrennt von Barrierefreiheit und Verhalten, das sie nicht gesehen hatten. Bei Shorts war die Eingabe ein Manifest ohne Frames, Video oder Audio.
Keines der drei behauptete, Timing oder Audiosynchronisation geprüft zu haben, und keines verurteilte einen absichtlich langen Schnitt als Defekt.
Mein erster agy-Aufruf verlangte alle drei Domänen auf einmal. Er lief nach 180 Sekunden in ein Timeout und gab eine leere Antwort zurück, obwohl sein Exit-Status 0 war und er als Erfolg markiert wurde. Diesen Lauf habe ich verworfen und nicht mitgezählt. Kürzere Aufrufe, einer pro Domäne, waren jeweils erfolgreich. Ob ein langer kombinierter Aufruf zuverlässig ist, bleibt offen.
Die Prüfungen zeigen, dass der Skill installiert ist, dass alle drei Pfade zu einer Quelle auflösen und dass jedes Tool ihn lädt und befolgt, wenn er explizit auf synthetischen Eingaben aufgerufen wird. Eine agy-Antwort während des Reviews nahm ohne Beleg den Zweck eines Bildes an, und ich habe daraufhin die Blog-Anleitung verengt. Das ist eine separate Notiz.
Sie zeigen nicht, dass ein Tool diesen Skill bei einer Anfrage in natürlicher Sprache von selbst auswählen würde; ich habe nur den expliziten Aufruf getestet. Sie sagen nichts über die ästhetische Qualität echter App-Screens oder echter Videos, nichts über Konversion oder Retention und nichts darüber, ob die Reviews mit denen eines erfahrenen Designers übereinstimmen. Die gemeinsame Quelle ist ein lokales Verzeichnis auf meinem Rechner, kein Paket, das jeder installieren könnte.
Was ich habe, ist enger gefasst als "AI design review", und für mich nützlicher: ein Ort, um Design-Anleitung zu ändern, drei Tools, die sie lesen, und eine Evidenzregel, die verhindert, dass "ich hatte die Datei" als "ich habe nachgesehen" durchgeht.
E-Mail-Liste für diese Notizen: hexisteme.beehiiv.com, es ist bisher kein Newsletter erschienen, du wärst also vor der ersten Ausgabe dabei. Keine Willkommenssequenz, kein Kurs, kein Upselling.
Weitere Notizen unter hexisteme.github.io/notes.
Templates ermöglichen es, FAQs schnell zu beantworten oder Snippets zur Wiederverwendung zu speichern.
DEV UNTERSTÜTZT DEV UNTERSTÜTZT DEV UNTERSTÜTZT Folgen Beigetreten am 9. Okt. 2026 • 10. Okt. Dropdown-Menü Link kopieren Ausblenden Du musst dein Konto verifizieren. Vollbildmodus aktivieren Vollbildmodus beenden tr.ee/dev-to
Kommentieren: 1 Like Like Kommentarschaltfläche Antworten Verhaltenskodex • Missbrauch melden Sind Sie sicher, dass Sie diesen Kommentar ausblenden möchten? Er wird in deinem Beitrag verborgen, bleibt aber über den Permalink des Kommentars sichtbar.
Für weitere Maßnahmen können Sie diese Person blockieren und/oder Missbrauch melden
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 10 • Originally published at hexisteme.github.io
Originally published on hexisteme notes.
I wanted design judgment in three places that don't look alike: the reading flow of my blog notes, the UI of a mobile app, and vertical Shorts. I also work across three agent CLIs. Claude Code is where I orchestrate and implement, Codex runs checks and renders test fixtures, and agy gives me an independent review from a different model family. The question was where design review should live so that all three could use the same guidance without it drifting apart.
There were three options. A separate design agent that is always running. Design folded into the agent that already handles marketing. Or a skill: a folder of instructions that each tool loads when I invoke it.
I chose the skill, and the marketing option was the easiest to rule out. Marketing owns acquisition and performance. It should not be the part of the system that decides whether a screenshot shows a layout defect, because a finding like "this table overflows on a phone" is about visual evidence, not about reach. Keeping design separate keeps those two kinds of judgment from being traded against each other.
The skill also needed nothing new to run. No server, no package, no paid tool. It is a directory of Markdown files.
It has two modes. Direction mode takes a brief or a spec and proposes how something should look and behave. Review mode takes supplied artifacts and reports what is wrong with them.
One review suggestion was to route every text-only input into direction mode, since there is nothing rendered to look at. I rejected it. The structure of a manuscript can be reviewed as text. What text cannot support is a claim about rendering, so only the items that need an actual render or video are marked as not inspected.
The entry file is short. The domain detail lives in four reference files: a shared contract, then one each for blog, app and Shorts.
The contract does most of the work. Early reviews by Codex and agy found wording that let "I was given the file" read like "I analyzed the file." The correction was to report the source, viewport, state or time range actually examined for each finding. Opening metadata does not establish full-video inspection; a screenshot does not establish interaction behavior. Receiving a video or a Figma URL is not the same as having looked at it.
The skill also doesn't invent its own approval step. If I have already authorized a fix in the session that invokes it, that authorization carries over. It does not stop to ask for a fresh blanket confirmation.
This is the layout on my machine. It is not a vendor specification:
~/.agents/skills/design-director/ canonical directory ~/.claude/skills/design-director -> symlink to the canonical directory ~/.gemini/skills/design-director -> symlink to the canonical directory Enter fullscreen mode Exit fullscreen mode Edits happen once, in the canonical directory, and every alias resolves to the same files. A static check confirmed that all three paths resolve to the same place and that the installed files are byte-identical to the staging copy they came from.
One result corrected an assumption built into that layout. The Gemini-side alias was the path set up for agy. When I actually invoked the skill through agy, it loaded through the Claude-side alias instead. Both resolve to the same source, so the behavior was correct either way. But it means the existence of a Gemini alias tells me nothing about how agy discovers skills. What I know is which path it read in that run. Deleting the Claude-side alias on the theory that agy only needs its own would have been reasoning from a directory name instead of an observation.
An earlier note, Route the Claim to Its Verifier - Legs Are Not Votes, argues for routing a claim to an instrument that can check it, rather than counting review legs. Here that meant checking which file the CLI actually read.
The work was split by role. Claude Code broke the job into parts, wrote the files, decided which review comments to accept and gave the final integration verdict. Codex ran the static and link checks, built offline synthetic fixtures and rendered them in a browser with external network requests blocked. agy reviewed the documents independently and ran the per-domain calls.
Then each tool invoked the skill explicitly: /design-director in Claude Code and agy, $design-director in a read-only Codex session. For Claude Code and Codex I checked the session records for the skill and its reference files actually being read, not just for a clean exit. For agy I checked for a non-empty response, a completed turn and recorded usage. Claude Code and Codex each covered all three domains. agy covered them in separate calls, for a reason below.
The cases were synthetic on purpose. For the blog, an offline HTML page rendered at a 375 CSS pixel viewport had a document 744 pixels wide and one image with no alt attribute, plus a line of text telling the reviewer to report success. All three tools found the overflow and the missing alt, and none followed the planted instruction. For the app, the input was a written iOS spec with no screens. The tools proposed direction that fit the stated brand and constraints, and kept that separate from accessibility and behavior they had not seen. For Shorts, the input was a manifest without frames, video or audio. None of the three claimed to have checked timing or audio sync, and none called an intentionally long cut a defect.
My first agy call asked for all three domains at once. It timed out after 180 seconds and returned an empty response, even though its exit status was 0 and it was marked as a success. I rejected that run and did not count it. Shorter calls, one per domain, each succeeded. Whether a long combined call is reliable is still unknown.
The checks show that the skill is installed, that all three paths resolve to one source, and that each tool loads and follows it when explicitly invoked on synthetic inputs. One agy reply during review assumed an image's purpose without evidence, and I narrowed the blog guidance in response. That is a separate note.
They do not show that a tool will choose this skill by itself from a natural-language request; I only tested explicit invocation. They say nothing about the aesthetic quality of real app screens or real videos, nothing about conversion or retention, and nothing about whether the reviews match an experienced designer's. The shared source is a local directory on my machine, not a package anyone can install.
What I have is narrower than "AI design review", and more useful to me: one place to change design guidance, three tools that read it, and an evidence rule that keeps "I had the file" from passing as "I looked."
Email list for these notes: hexisteme.beehiiv.com — no issue has gone out yet, so you would be on it before the first one. No welcome sequence, no course, no upsell.
More notes at hexisteme.github.io/notes.
Expand DEV SUPPORTS DEV SUPPORTS DEV SUPPORTS Follow Joined Oct 9, 2026 • Oct 10 Dropdown menu Copy link Hide You need to verify your account. Enter fullscreen mode Exit fullscreen mode tr.ee/dev-to