Zur Nutzungsanleitung springen
plan-design-reviewvon Garry Tan

Plan Design Review Skill.

Ein Skill für Claude Code und Codex für Design-Reviews: prüft einen Designplan auf Vollständigkeit und Erfahrungsrisiken vor der Umsetzung.

  • Design Review & Accessibility
  • Review-Bericht
garrytan/gstack · plan-design-review/SKILL.mdSKILL.md
--- name: plan-design-review description: Designer's eye plan review — interactive, like CEO and Eng review. (gstack) --- ## When to invoke this skill ## Confusion Protocol ## Claimed Limitations Need Evidence ## Continuous Checkpoint Mode ## Context Health (soft directive) ## Question Tuning (skip entirely if QUESTION_TUNING: false)
Metadaten und Abschnittsüberschriften aus der Ursprungsdatei vom 14.09.2026 · 72.139 Zeichen insgesamt

01 Was es tut

Was der plan-design-review Skill in Claude Code und Codex tut

Zusammenfassung, Workflow und Ergebnisse — alles aus der SKILL.md des Skills ausgelesen.

Aus der SKILL.mdGelesen am 14.09.2026 · kein aufgezeichneter Durchlauf

In den eigenen Worten des Skills

Überprüft einen Design-Plan auf Vollständigkeit und Erfahrungsrisiken vor der Umsetzung. Führt sieben Design-Durchgänge (Informationsarchitektur, Interaktionszustände, Nutzerreise, Leerzustände, visuelle Hierarchie, AI-Slop-Risiko, Barrierefreiheit) durch, bewertet jeden mit 0-10, erklärt, was einen 10er ausmachen würde, und passt den Plan entsprechend an. Erstellt standardmäßig visuelle Mockups mit dem gstack designer, wenn UI im Umfang liegt.

Enthält einen optionalen Schritt mit externen Stimmen: Codex bewertet anhand der harten Design-Regeln von OpenAI sowie Litmus-Prüfungen; ein Claude-Subagent führt eine unabhängige Vollständigkeitsprüfung durch. Arbeitet im Planmodus. Für visuelle Audits einer Live-Website verwenden Sie stattdessen /design-review. Das Ergebnis ist ein verbesserter Plan mit einem strukturierten Prüfbericht, nicht ein Dokument über den Plan.

Was er erzeugt

  • Eine verbesserte Plandatei mit geschlossenen Design-Lücken, bewerteten Dimensionen und einem angehängten strukturierten Abschnitt GSTACK REVIEW REPORT
  • Eine Vergleichstafel als HTML-Datei sowie approved.json mit der vom Nutzer gewählten Variante, Bewertungen, Kommentaren und Feedback
  • Ein Litmus-Scorecard, das die Ergebnisse von Codex und dem Claude-Subagenten zusammenfasst, falls externe Stimmen ausgeführt wurden
Siehe Beispiel-Prompt ↗

So funktioniert es

  1. 01
    Scope Gate bestätigt Prüfziel

    Fragt zunächst den Nutzer, was überprüft werden soll (Branch-Diff, Plandokument oder bestimmte Seite), sofern der Planmodus nicht automatisch den aktiven Plan auswählt oder der Nutzer ein Ziel explizit genannt hat.

  2. 02
    Erstellt standardmäßig visuelle Mockups

    Wenn der gstack designer verfügbar ist und der Plan UI-Umfang hat, werden Mockups sofort erstellt, ohne um Erlaubnis zu fragen.

  3. 03
    Optionale externe Design-Stimmen laufen parallel

    Wenn der Nutzer zustimmt, werden Codex (harte Design-Regeln + Litmus-Prüfungen) und der Claude-Subagent (unabhängige Vollständigkeitsprüfung) gleichzeitig gestartet.

  4. 04
    Sieben Design-Durchgänge bewerten 0-10 und schließen Lücken

    Für jede Dimension (Informationsarchitektur, Interaktionszustände, Nutzerreise, Leerzustände, visuelle Hierarchie, AI-Slop-Risiko, Barrierefreiheit) wird der Plan bewertet, erklärt, wie 10/10 aussieht, der Plan bearbeitet, um Lücken zu schließen, erneut bewertet und wiederholt, bis 10 erreicht ist oder der Nutzer sagt, dass weitergemacht werden soll.

  5. 05
    Schreibt strukturierten Prüfbericht in die Plandatei

    Fügt einen Abschnitt GSTACK REVIEW REPORT mit einer Tabelle zu Durchläufen/Status/Befunden, einer VERDICT-Zeile und einem Status zu ungelösten Entscheidungen als letzte Nicht-Leerzeichen-Zeile der Datei an.

02 Finden Sie Ihren Favoriten

Wann Sie den plan-design-review Skill verwenden

Verwenden Sie den plan-design-review Skill in Claude Code oder Codex, wenn die Aufgabe ein Design-Review dieser Art ist. Eignung und Grenzen sind der eigenen Datei des Skills entnommen.

Gut geeignet

  • Der Nutzer hat einen Plan mit UI/UX-Komponenten entworfen, der vor Beginn der Umsetzung überprüft werden sollte
  • Ein Design-Plan benötigt visuelle Mockups, um abstrakte Beschreibungen vor dem Programmieren konkret zu machen
  • Ein Plan beschreibt, was das Backend tut, legt aber nie fest, was der Nutzer sieht, wie Leerzustände, Fehlerzustände oder responsives Verhalten aussehen

Grenzen kennen

  • Reine Backend-, API-only- oder Infrastrukturänderungen ohne UI-Umfang
  • Visuelle Audits von Live-Websites (verwenden Sie stattdessen /design-review)

Was Sie bereitstellen sollten

  • Ein Design-Plan oder Branch-Diff mit UI-UmfangDie Plan-Datei, ein Dokument, das der Nutzer einfügt, eine bestimmte Seite/Pfad oder der aktuelle Branch-Diff.
  • Mockup-Feedback über ein VergleichsboardDer gstack-Designer stellt ein Vergleichsboard über HTTP bereit, auf dem der Nutzer Varianten bewertet, Kommentare hinterlässt, auf Regenerate/Remix klickt oder eine endgültige Auswahl übermittelt.

03 Innerhalb des Skills

Regeln, die der plan-design-review Skill Claude Code und Codex vorgibt

5 konkrete Anweisungen, Standardwerte und Grenzen, die SKILL.md für den Agenten festlegt — der Teil der Datei, der das Ergebnis verändert.

  1. Alle Design-Artefakte werden unter ~/.gstack/projects/$SLUG/designs/ gespeichert

    Mockups, Vergleichsboards und approved.json müssen im gstack-Projektverzeichnis „designs“ des Nutzers gespeichert werden, niemals unter .context/, docs/designs/, /tmp/ oder einem projektlokalen Verzeichnis.

  2. Prioritätshierarchie: Schritt 0 > Mockups > Interaktionszustände > AI Slop > IA > User Journey

    Überspringen Sie niemals die Scope-Bewertung von Schritt 0 oder die Mockup-Erstellung, wenn der Designer verfügbar ist. Mockups vor bestandenen Reviews sind nicht verhandelbar.

  3. Design-Reviews werden, wenn vorhanden, an DESIGN.md kalibriert

    Wenn DESIGN.md existiert, müssen sich alle Designentscheidungen am festgelegten Designsystem ausrichten.

  4. Outside Voices laden Issues vorab in die Durchgänge

    Harte Ablehnungen von Codex werden als erste Einträge in Pass 1 mit [HARD REJECTION] markiert. Litmus-DISAGREE-Einträge zeigen beide Perspektiven im jeweiligen Durchgang.

  5. Vollständigkeitsprinzip: KI macht Vollständigkeit günstig

    Volle Abdeckung empfehlen (Tests, Randfälle, Fehlerpfade) — den Ozean einen See nach dem anderen auskochen.

04 In Betrieb nehmen

plan-design-review in Claude Code oder Codex installieren

Ein npx skills add-Befehl, dann eine erste Aufgabe in Ihrem Agent und eine Checkliste für das Ergebnis.

plan-design-review zu Claude Code, Codex oder Ihrem Agent hinzufügen

Im eigenen Projekt ausführen; der Installer fragt, welchem Agent er hinzugefügt werden soll.

Terminal
npx skills add https://github.com/garrytan/gstack --skill plan-design-review

Generische skills-CLI-Form für plan-design-review/SKILL.md; das Repository kann seinen eigenen Pfad dokumentieren.

Dem Skill eine erste Design-Review-Aufgabe geben

In den eigenen Begriffen des Skills verfasst; ersetzen Sie die Teile in Klammern durch Ihr Material.

Starter prompt
Review the design plan in [plan-file-path] before we start building. The plan describes a new onboarding flow with three screens, email capture, and a welcome modal. I want to make sure we're not missing interaction states, empty states, or accessibility requirements. Generate mockups if you can.

Quelle: verfasst aus der SKILL.md in den eigenen Begriffen des Skills.

Das erste Ergebnis prüfen

Was die SKILL.md selbst als korrektes Ergebnis beschreibt:

  • Bestätigen Sie, dass die letzte Überschrift der Plan-Datei ## GSTACK REVIEW REPORT lautet, bevor Sie den Planmodus verlassen
  • Bestätigen Sie, dass der Review-Report eine Runs/Status/Findings-Tabelle, eine VERDICT-Zeile und einen Status zu ungelösten Entscheidungen als letzte Nicht-Leerzeichen-Zeile der Datei enthält
  • Prüfen Sie, ob gstack-review-log aufgerufen und gstack-review-read mindestens einmal ausgeführt wurde, falls eine Plan-Datei im Kontext vorliegt

In OpenDesign ist plan-design-review vorinstalliert: Plugins → Skills, in der oberen Leiste auswählen.

05 Open Source, nachvollziehbar

Quelle, Lizenz und Verifizierung

Woher die Fakten auf dieser Seite stammen und wann sie zuletzt geprüft wurden.

Author
Garry Tan
Repository
github.com/garrytan/gstack Branch main
Skill-Datei
plan-design-review/SKILL.md Inhalts-Prüfsumme bei Verifizierung erfasst; Commit 71f6048
License
MIT Aus LICENSE.
Repository-Sterne
132.921 GitHub-Snapshot vom 14.09.2026 für das gesamte Repository garrytan/gstack, das 7 Skills in diesem Katalog enthält. Keine Bewertung oder Nutzungszahl für plan-design-review.
Verifiziert von OpenDesign
14.09.2026 Quelldatei, Pfad, Lizenztext und Sternanzahl wurden geprüft. In OpenDesign main gebündelt (geprüft am 28.08.2026); ein Live-Lauf wurde auf dieser Seite nicht erfasst.

In der SKILL.md

  1. Wann dieser Skill aufgerufen werden sollteFür Design-Plan-Reviews verwenden; proaktiv vorschlagen, wenn ein UI/UX-Plan vor der Umsetzung geprüft werden muss
  2. Präambel (zuerst ausführen)Führt gstack-skill-start aus, behandelt den eingeschränkten Modus, liest Anweisungsblöcke, setzt SESSION_KIND und Telemetrie-Markierungen
  3. Design-PhilosophieStellt sicher, dass Design bewusst wirkt und nicht generiert; jede Lücke finden, erklären, warum sie wichtig ist, offensichtliche beheben
  4. Der gstack-Designer — IHR WICHTIGSTES WERKZEUGKI-Mockup-Generator, der reale Visuals aus Design-Briefings erstellt; standardmäßig verwenden, wenn UI existiert
  5. Design-PrinzipienNeun Prinzipien: Leerzustände sind Features, Hierarchie zählt, Spezifität statt Bauchgefühl, Randfälle sind UX, AI Slop ist der Feind, responsives Design ist bewusst, Barrierefreiheit ist Pflicht, Subtraktion als Standard, Vertrauen wird auf Pixelebene erworben
  6. Kognitive Muster — Wie großartige Designer sehenZwölf Wahrnehmungsinstinkte: Systeme statt Bildschirme sehen, Empathie als Simulation, Hierarchie als Dienst, Constraint-Verehrung, Frage-Reflex, Randfall-Paranoia, der „Würde-ich-es-merken“-Test, prinzipientreuer Geschmack, Subtraktion als Standard, Zeithorizont-Design, Design für Vertrauen, Storyboard-Journeys
  7. UX-Prinzipien: Wie sich Nutzer tatsächlich verhaltenDrei Gesetze (bringen Sie mich nicht zum Nachdenken, Klicks sind egal, Denken zählt, weglassen und dann noch mehr weglassen), Nutzerverhalten (scannen statt lesen, satisficing, sich durchwursteln), Billboard-Design, Navigation als Wayfinding, Wohlwollens-Reserve, Mobile mit höherem Risiko
  8. Prioritätshierarchie unter KontextdruckStep 0 > Mockups > Interaction States > AI Slop > IA > User Journey; Step 0 oder Mockups niemals überspringen
  9. PRE-REVIEW SYSTEM AUDIT (vor Step 0)Sammelt Kontext aus git log, diff stat, Plan, CLAUDE.md, DESIGN.md, TODOS.md, kartiert den UI-Umfang und bestehende Patterns
  10. DESIGN SETUP (diese Prüfung VOR jedem Design-Mockup-Befehl ausführen)Prüft, ob die gstack-designer-Binary verfügbar ist; gibt DESIGN_READY oder DESIGN_NOT_AVAILABLE aus
  11. Brain Context (Preflight)Lädt strukturierten Projektkontext (Produkt, Marke, Ziele, jüngste Entscheidungen) aus gstack-brain-cache, bevor Klärungsfragen gestellt werden
  12. Step 0: Bewertung des Design-UmfangsErste Design-Einstufung 0–10, Status-Check von DESIGN.md, Nutzung bestehenden Designs, Frage nach Schwerpunkten (STOP, bis der Nutzer antwortet)
Die eigene Beschreibung des Skills
„Designer's eye plan review — interaktiv, wie CEO und Eng review. (gstack)"

Front-Matter-Beschreibung aus SKILL.md. Die vollständige Datei umfasst etwa 72.139 Zeichen. Vollständige Datei auf GitHub lesen.

Plan Design Review

Führen Sie plan-design-review für eine echte Design-Review-Aufgabe aus.

Der Skill plan-design-review ist in OpenDesign enthalten. Laden Sie die App herunter, wählen Sie den Skill unter Plugins → Skills, fügen Sie den obigen Prompt ein und lesen Sie den Plan vor dem Ergebnis.

Terminal
npx skills add https://github.com/garrytan/gstack --skill plan-design-review