charliesbot/android-design-explore

Visuelle Design-Erkundung

Befolge für jede Design-Entscheidung den android-design-Skill: dessen Abschnitt 0 beantwortet, Komponenten, Theming, Layout und die Überprüfungsfragen. Dieser Skill besitzt den Workflow. Jeder Durchlauf ist einmalig: Kurzbeschreibung rein, ein Vorschlag geschrieben, überprüft, angezeigt, dann Stopp. Telefon, Faltgeräte, Tablet, Desktop und Wear OS-Bildschirme sind im Umfang enthalten; Wear Tiles, Watch Faces und Widgets nicht. Wo Wear abweicht, sagt der folgende Abschnitt Wear OS, wie es geht.

Ein Vorschlag ist eine Datendatei, die die Vorschau-App, ein natives macOS-Fenster, mit echten Compose Material 3 Komponenten zeichnet und bei jedem Speichern neu zeichnet. Du überprüfst ihn über den Layout-Baum der App; der Benutzer beurteilt den Stil im Fenster.

Anforderungen

macOS, mit installierter und registrierter Vorschau-App als MCP-Server namens android_design_preview. Rufe zuerst dessen status-Tool auf. Wenn die Tools nicht verfügbar sind, stoppe und sage dem Benutzer die zwei Schritte, dann warte:

1. Erstelle und installiere die App aus einem Checkout des android-design-Repositorys: cd app && ./gradlew :app:installApp, was ~/Applications/AndroidDesignPreview.app installiert.
2. Registriere sie für die Umgebung und starte dann die Sitzung neu (<binary> ist ~/Applications/AndroidDesignPreview.app/Contents/MacOS/AndroidDesignPreview, geschrieben als absoluter Pfad, wo die Umgebung ~ nicht expandiert):
   • Claude Code: claude mcp add --scope user android_design_preview -- <binary>
   • Codex: eine [mcp_servers.android_design_preview]-Tabelle in ~/.codex/config.toml mit command = "<binary>" und default_tools_approval_mode = "approve"
   • Antigravity: agy mcp add android_design_preview <binary>

Kurzbeschreibung

Wenn es eine App gibt, lies zuerst deren relevante Bildschirme, Theme, Assets und alle vorhandenen DESIGN.md und design/-Vorschläge. Beantworte Abschnitt 0 von android-design in der Antwort.

• Wähle eine Saat: die Markenfarbe oder eine Inhaltsfarbe vom Motiv (ein Gericht, ein Album, eine Reise), niemals die Standardfarbe der App #6750A4.
• Wenn der Bildschirm ein Hero-Moment ist (Frage 3 von Abschnitt 0), schichte drei oder mehr Taktiken (Abschnitt 3) und benenne sie.
• Behalte App-Code und Abhängigkeiten unverändert.
• Verwende repräsentative, nicht sensible Daten und Assets. Verwende Bildgenerierung nur für Assets innerhalb eines Vorschlags, niemals als Ersatz dafür.

Erstelle mehrere Vorschläge nur, wenn der Benutzer darum bittet. Jeder ist eine eigene Datei, eine eigenständige Komposition (keine Umfärbung) mit eigener Saat in ihrem theme, und mindestens einer davon ist ein Hero.

Dateien

Arbeite im Wurzelverzeichnis des App-Repositorys oder im vom Benutzer genannten Ordner. Schreibe niemals in das eigene Repository dieses Skills.

• DESIGN.md im Wurzelverzeichnis enthält das gemeinsame Designsystem. Erstelle sie, wenn sie fehlt, mit der gewählten Saat, Schriftarten und benannten Stilen. Ändere sie nur, wenn die Richtung ändert, was alle Vorschläge gemeinsam haben; das eigene Aussehen einer Richtung kommt in das theme ihres Vorschlags.
• design/<slug>.proposal.json enthält einen Vorschlag.

Beides sind normale getrackte Dateien; das Committen folgt dem eigenen Arbeitsablauf des Projekts. Teile dem Benutzer den absoluten Pfad des Vorschlags mit.

Schreiben

1. Rufe get_catalog auf (seine Toolbeschreibung sagt, was es zurückgibt). Es ist das einzige Komponentenvokabular: eine Komponente, die es nicht hat, ist unerreichbar, also baue die Idee aus Box, Row, Column, Text und Shape oder lasse sie weg.
2. Lese references/proposal-format.md, schreibe dann DESIGN.md und den Vorschlag, kompakt wie im Abschnitt "Kompakt schreiben" beschrieben.

Der Vorschlag trägt diese Designregeln; proposal-format.md gibt die Syntax für jede an, und der Abschnitt Komponentenregeln enthält die Regeln für Tabs, Karussells, Overlays, Auswahlen, Toolbars, Menüs, App-Leisten und Badges:

• Der Bildschirm hat eine primäre Aktion, als primär markiert, und sie führt die anderen an, wie in android-design Abschnitt 2 beschrieben.
• Er passt sich bei 600 und 840 dp an: eine Navigationsleiste wird in kompakter Ansicht zu einer Rail ab mittlerer Größe, und ein Detailbildschirm einer Liste öffnet sich neben der Liste bei erweiterten Breiten.
• Text wird absichtlich abgeschnitten, mit Auslassungspunkten. Labels von Schaltflächen, Chips und Navigation passen auf eine Zeile.

Überprüfen

Für einen Vorschlag ersetzt dieser Schritt das Rendern in der Bildschirmüberprüfung von android-design. Beantworte deren Fragen aus den Layout-Zusammenfassungen und Fehlern von check_proposal (und get_tree, wenn sie nicht ausreichen), niemals aus einem Rendering oder Pixeln. Screenshots bleiben außen vor: mache niemals einen oder bitte danach.

1. Rufe open_proposal mit dem absoluten Pfad des Vorschlags auf. Es lädt die Datei, überwacht sie, zeigt das Fenster und gibt Validierungsfehler zurück. Behebe sie und rufe status auf, bis es keine mehr meldet.
2. Rufe check_proposal auf. Ein Aufruf überprüft jeden Bildschirm in jeder Ansicht und gibt die Fehler jeder Ansicht sowie die layout-Zusammenfassung zurück; die Toolbeschreibung gibt das Format an.
3. Behebe jeden Fehler einmal, dann rufe erneut check_proposal auf. Ein overflow-Fehler benennt einen Knoten, der breiter als sein Elternteil oder die Ansicht ausgelegt ist (eine Zeile, die mehr Breite als ihre Zelle benötigt); verkleinere ihn, umbreche ihn oder lasse ihn scrollen. Melde alles, was noch fehlschlägt, anstatt zu wiederholen.
4. Bestätige die Anpassung aus den layout-Zusammenfassungen: jede größere Ansicht zeigt, was deine Antwort zur Anpassung in Abschnitt 0 versprochen hat, wie ein zweites Panel, eine Rail oder mehr Bereiche. Google: "Zusätzlicher Platz bedeutet nicht nur, dasselbe größer zu machen." Eine größere Ansicht mit nur den Telefonbereichen, die breiter verteilt sind, schlägt fehl.
5. Rufe get_tree nur auf, wenn eine Zusammenfassung oder ein Fehler nicht ausreicht; die Toolbeschreibung sagt, was es zurückgibt.

Der Schritt ist abgeschlossen, wenn check_proposal bestanden wird oder jeder verbleibende Fehler auf der Liste steht, die du meldest, und die Anpassung bestätigt ist.

Anzeigen

Rufe show_preview auf. Sage in einem Satz, was der Vorschlag ist, nenne die Taktiken, die ein Hero schichtet, liste alle ungelösten Ergebnisse auf und berichte "visuelle Qualität nur aus dem Layout-Baum bewertet". Stoppe dann und warte auf die Antwort des Benutzers.

Überarbeiten

Bearbeite denselben Vorschlag mit dem Feedback des Benutzers; das Fenster zeichnet beim Speichern neu. Wiederhole die Überprüfung auf den geänderten Bildschirmen. Die Überarbeitung ersetzt die alte Version; behalte keine Kopien.

Genehmigen und Portieren

Die Genehmigung erfolgt durch den Benutzer im Chat. Melde den Pfad des genehmigten Vorschlags und dass references/compose-mapping.md die Portierungstabelle ist. Eine Nur-Erkundungs-Anfrage endet hier: nicht implementieren. Eine Bauanfrage (der android-design-Skill sendet designorientierte Builds neuer Apps, Bildschirme und Umgestaltungen zuerst hierher) fährt mit dem Portieren fort. Die Genehmigung autorisiert niemals Bibliotheksversionsänderungen.

Der Port folgt den Planungs-, Branch-, Verifikations- und Überprüfungsregeln des anfragenden Projekts:

1. Rufe export_kotlin für die zu portierenden Bildschirme auf. Das Kotlin ist der erste Entwurf, kein fertiger Code.
2. Passe es an die Konventionen und Bibliotheksversionen der App mit references/compose-mapping.md an.
3. Rendere das Ergebnis mit dem compose-preview-Skill und vergleiche es mit den Bäumen des Vorschlags bei denselben Ansichten.

Melde Komponenten, die die Zuordnung als nicht verifiziert markiert, und alles, was ihr fehlt, anstatt ein Compose-Äquivalent zu erfinden. Wenn das Design mit den App-Abhängigkeiten nicht erhalten werden kann, frage nach.

Wear OS

Ein Wear-Vorschlag folgt demselben Workflow. android-design references/wear-os.md besitzt die Designregeln, und proposal-format.md besitzt das Dateiformat (Katalog-ID, Ansichten, Screen, primary, large).

• Eigene Datei. Eine Oberfläche pro Vorschlag: schreibe design/<slug>-wear.proposal.json neben der Telefon-Version.
• Anpassungsprüfung: Die Wear-Größenüberschreibung gilt ab 225 dp, also ist die Prüfung "passt und ist lesbar bei beiden Uhrengrößen, und die große zeigt mehr Wert, niemals weniger".
• Gemeinsames DESIGN.md: Seine Saat und Farbrollen gelten für Wear; seine Typographie wird durch Roboto Flex ersetzt.
• Ergebnisse: Behebe round-edge-clipped (Kontrolle oder Text, der durch die abgerundete Kante auf einem festen Bildschirm abgeschnitten wird) mit prozentualen Rändern oder einem kleineren Layout.
• Portieren: Die gleichen drei Schritte. export_kotlin schreibt Wear Compose: ein WearAppTheme mit den exakten Farben der Vorschau-App, AppScaffold und ScreenScaffold und Navigation 3 mit Wischen zum Schließen. Rendere den Port bei beiden runden Größen (204 und 227 dp).

Löschen

Wenn der Benutzer darum bittet, entferne design/<slug>.proposal.json. Behalte DESIGN.md, es sei denn, der Benutzer bittet auch darum, sie zu entfernen.