Mobile Design OS

Was macht Mobile Design OS?

Führe die kleinste vollständige Mobile-Design-Kette aus, die das angeforderte Ergebnis erreicht. Leite die Arbeit an die spezialisierten Skills weiter, bewahre stabile IDs und Belege zwischen den Phasen und lasse niemals zu, dass polierte visuelle Darstellungen ungelöste Produkt-, Plattform-, Zustands- oder Validierungslücken verdecken.

Run einrichten

Ermittle:

• Angefordertes Ergebnis: Analyse, Produkt-Framing, UX, visuelles Konzept, vollständiges Design-Paket, Prototyp, Review oder Implementierungs-Übergabe.
• Zielplattform und Formfaktoren.
• Verfügbare Eingaben: Produktidee, Screenshots, URLs, Markenmaterial, bestehende Verträge, Code oder Laufzeitnachweise.
• Autorisierter Umfang: Nur Design, Prototyp oder Code-Änderungen.
• Entscheidungen, die tatsächlich den Benutzer erfordern, insbesondere Sicherheitsmodell, Hauptakteur, MVP-Grenze, visuelle Richtung, Framework-Override und öffentliche Lizenz.

Erstelle design-run.json aus assets/design-run-template.json, wenn die Arbeit zwei oder mehr Phasen umfasst oder fortsetzbar sein muss. Lies references/pipeline-contract.md, bevor du das Manifest erstellst oder aktualisierst.

Zu den erforderlichen Skills routen

Lies das SKILL.md des ausgewählten Skills vollständig, bevor du seine Phase ausführst. Lade nicht alle Skill-Bodies, wenn die Anfrage nur ein oder zwei Phasen benötigt.

Bedarf	Skill	Abschlussnachweis
Referenzen entdecken oder vergleichen	mobile-reference-research	Gültiges reference-research.json
Mechaniken und Design-DNA extrahieren	analyze-mobile-ui	Gültiges design-dna.json
Produkt und MVP rahmen	mobile-product-brief	Gültiges product-brief.json
Abläufe, Objekte, Bildschirme und Zustände definieren	mobile-ux-architect	Gültiges ux-architecture.json
Low-Fidelity-Hierarchie aufbauen	mobile-wireframe	Gültiges wireframe.json
Visuelle UI erkunden und rendern	mobile-ui-design	Benutzerauswahl, gesperrt, gültiges ui-design.json bei strukturierter Übergabe
Wiederverwendbare Tokens/Komponenten extrahieren	mobile-design-system	Gültiges design-system.json
Interaktionsverhalten modellieren oder rendern	mobile-prototype	Gültiges prototype.json und UI-Abgleichsbericht, wenn UI existiert
Natürliches Verhalten entscheiden und testen	mobile-platform-guidelines	Gültiges platform-guidelines.json
Die Kette prüfen	mobile-design-review	Gültiges review.json mit einer ehrlichen Entscheidung
Implementierung planen oder Gerüst bauen	mobile-design-to-code	Gültige Übergabe plus tatsächliche Build/Test-Nachweise, wenn Code generiert wird

Die vollständige Kette ausführen

Bei einer End-to-End-Anfrage verwende diese Reihenfolge und überspringe nur Phasen, die explizit als not-required markiert sind:

1. Führe mobile-product-brief aus, um Problem, Zielgruppe, Aktivierung, Kernschleife, MVP, Vertrauensgrenzen und ungelöste Entscheidungen festzulegen.
2. Führe mobile-reference-research aus, wenn Referenzen fehlen oder verglichen werden müssen.
3. Führe analyze-mobile-ui aus, wenn Screenshots oder Referenzprodukte zu nachvollziehbarer Design-DNA werden müssen.
4. Führe mobile-ux-architect aus dem validierten Brief und den Referenzentscheidungen aus.
5. Führe mobile-wireframe vor der visuellen Gestaltung aus, wenn Hierarchie oder Zustandsdruck nicht trivial sind.
6. Führe mobile-ui-design aus. Erzwinge genau drei vergleichbare Vorschauen und stoppe an dessen Benutzerauswahl-Gate. Wähle keine visuelle Richtung, es sei denn, der Benutzer delegiert die Wahl explizit.
7. Nach der Auswahl sperre die visuelle Richtung und vervollständige die gerenderten Bildschirme und das strukturierte UI-Artefakt.
8. Führe mobile-design-system aus, wenn nachgelagerte Wiederverwendung oder Implementierungstokens benötigt werden.
9. Führe mobile-prototype aus, validiere dann UI-zu-Prototyp-Zustand und Interaktionsausrichtung.
10. Führe mobile-platform-guidelines für natives Verhalten und Gerätetestfälle aus.
11. Führe mobile-design-review gegen die vollständige verfügbare Kette aus.
12. Führe mobile-design-to-code nur aus, wenn Implementierung oder Übergabe angefordert ist und die Review-Entscheidung es erlaubt.

Aktualisiere design-run.json nach jeder Phase. Bewahre vorgelagerte Anforderungs-, Ablauf-, Bildschirm-, Zustands-, Token-, Komponenten- und Beleg-IDs; generiere niemals stillschweigend Identifikatoren in einer nachgelagerten Phase neu.

Gates durchsetzen

• Führe jeden vom ausgewählten Skill benannten Phasen-Validator aus und behebe strukturelle Fehler, bevor du fortfährst.
• Fordere einen validierten Produktbrief, bevor du UX-Vollständigkeit behauptest.
• Fordere explizite Zustandsverantwortung und -wiederherstellung, bevor du UI-Vollständigkeit behauptest.
• Fordere visualLock.status: locked und eine Benutzer- oder benutzerdelegierte Auswahlquelle, bevor du am Design System oder gerenderten Prototypen arbeitest.
• Fordere UI-zu-Prototyp-Ausrichtung, wenn beide Artefakte existieren.
• Halte Screenshots und Browser-Runner davon ab, Laufzeitzugänglichkeit, Lebenszyklus, Berechtigungen, Sensoren, Persistenz, Auslieferung oder Geräteverhalten nachzuweisen.
• Halte eine Code-Übergabe davon ab, nachzuweisen, dass generierter Code baut oder Tests besteht. Zeichne die genauen Befehle und Ergebnisse auf, wenn Code generiert wird.
• Fordere keine offenen P0 oder P1 und keine fehlenden hochriskanten Nachweise, bevor du ein pass gibst; verwende andernfalls conditional-pass, revise oder fail, wie vom Review-Skill definiert.

Führe python3 scripts/validate_design_run.py <path-to-design-run.json> --root <run-directory> aus, bevor du einen mehrstufigen Run auslieferst.

Nur bei wesentlichen Entscheidungen anhalten

Pausiere, wenn:

• Der Benutzer zwischen den drei visuellen Richtungen wählen muss.
• Eine Entscheidung Sicherheit, Privatsphäre, Hauptakteur, Kernwertschleife, destruktives Verhalten oder MVP-Umfang ändert.
• Eine erforderliche Eingabe oder Autorisierung nicht verfügbar ist.
• Der nächste Schritt externe Bewertung, physische Geräte-Nachweise, Produktionsverhalten oder eine öffentliche Lizenz behaupten würde, die nicht tatsächlich bereitgestellt wurden.

Andernfalls fahre mit einer gekennzeichneten Annahme fort und halte sie im Manifest fest.

Den Run ausliefern

Gib zurück:

1. Ergebnis und aktuelle Phasenentscheidung.
2. Abgeschlossene Phasen und validierte Artefaktpfade.
3. Benutzerentscheidungen und gekennzeichnete Annahmen.
4. Offene P0/P1-Probleme und nicht getestetes hochriskantes Verhalten.
5. Die nächste ausführbare Phase oder das exakte externe/Geräte-/Benutzer-Gate, das noch besteht.

Beschreibe die Kette nicht als vollständig, wenn eine erforderliche Phase aussteht, auf Benutzerauswahl wartet, blockiert oder strukturell gültig aber nicht getestet ist.