mingdui/AI-Product-Skills

Produktmanager High-Fidelity-Prototyp Skill (Frontend)

1. Ziel

Auf Basis des Quellcodes eines bestehenden Frontend-Projekts einen High-Fidelity-, klickbaren Prototyp erstellen, der vom offiziellen Business-Einstieg isoliert ist. So können Produktmanager Produktideen schnell ansehen, demonstrieren und diskutieren.

Priorität hat:

• Konsistenz mit dem bestehenden Projektstil.
• Die Seite wirkt wie ein echtes Produkt, nicht wie eine temporäre Demo.
• Verwendung geschäftsrelevanter Mock-Daten.
• Kernabläufe sind klickbar.
• Interaktionen eignen sich für Anforderungs-Reviews.
• Die Seite ist einfach weiter zu bearbeiten.
• Sie kann sofort lokal ausgeführt und in der Vorschau betrachtet werden.
• Standardmäßig werden keine bestehenden Geschäftsseiten und Routen beeinträchtigt.

Sofern der Benutzer es nicht ausdrücklich verlangt, wird die Aufgabe nicht als komplette Neuentwicklung des Systems von Grund auf betrachtet.

Wenn das Ziel ein High-Fidelity-Prototyp ist, werden Backend-Schnittstellen, Produktionsdatenpfade oder komplexe Architekturen nicht priorisiert.

Standardmäßige Isolationskonvention: Zuerst den Quellcode, das Layout, die Komponenten und visuellen Regeln des bestehenden Projekts wiederverwenden. Dann den Prototyp in einer unabhängigen Prototyp-Seite, -Route oder einem Funktionsverzeichnis implementieren. Standardmäßig werden keine bestehenden Geschäftsseiten, Produktions-Einstiegspunkte oder vorhandenen API-Aufrufe geändert. Nur wenn der Benutzer explizit „Direkt auf der Originalseite demonstrieren“ oder „Prototyp auf bestehende Seite übertragen“ verlangt, darf dies erfolgen.

---

2. Anwendungsfälle

Diese Skill wird verwendet, wenn der Benutzer Folgendes anfordert:

• Erstellung einer unabhängigen Prototyp-Seite oder -Route basierend auf dem Quellcode eines bestehenden React-, Vue-, HTML- oder anderen Frontend-Projekts.
• Wenn der Benutzer es explizit verlangt, Demonstrieren von Prototyp-Interaktionen auf einer bestehenden Produktseite.
• Hinzufügen einer Admin-Seite, CRM-Seite, SaaS-Seite, eines Betriebs-Backends oder eines Business-Workbenchs.
• Umwandeln einer statischen Seite in einen klickbaren Prototyp.
• Hinzufügen realistischer Mock-Daten und Interaktionszustände.
• Hinzufügen oder Optimieren von Tabellen, Formularen, Filtern, Tabs, Drawern, Modalen, Diagrammen, Detailseiten oder Geschäftsabläufen.
• Erweitern neuer Funktionen gemäß dem Stil des bestehenden Projekts.
• Ohne Backend-Entwicklung eine High-Fidelity-Demo für die Review erstellen.
• Optimieren der visuellen Hierarchie, Informationsdichte, des responsiven Designs oder von Interaktions-Feedbacks.

Häufige Formulierungen des Benutzers:

• „Füge eine Kundenliste-Seite im bestehenden Admin-Bereich hinzu.“
• „Erstelle ein Geschäftsdaten-Dashboard basierend auf dem aktuellen Projektstil.“
• „Füge ein Follow-Up-Aufzeichnungsmodul auf der bestehenden Detailseite hinzu.“
• „Ergänze diese Seite zu einem klickbaren Prototyp.“
• „Füge Suche, Filter, Statuswechsel, Drawer und Modal-Interaktionen hinzu.“
• „Optimiere diese bestehende Seite, aber ändere nicht den gesamten Systemstil.“

---

3. Nicht-Anwendungsfälle

Diese Skill wird standardmäßig nicht verwendet in folgenden Fällen:

• Der Benutzer möchte ein völlig neues Produkt von einem leeren Verzeichnis aus erstellen.
• Der Benutzer benötigt nur eine Marketing-Website oder Landing Page.
• Der Benutzer fordert die Entwicklung von Backend-Schnittstellen, Datenbanken oder Produktionsdiensten an.
• Der Benutzer benötigt technische Architekturdokumentation und keinen Prototyp.
• Der Benutzer möchte nur visuelle Bilder oder statische Screenshots generieren.
• Die aktuelle Aufgabe besteht hauptsächlich in der Anforderungsanalyse oder dem Schreiben eines PRDs.

Wenn das aktuelle Verzeichnis leer ist, sollte erklärt werden, dass diese Skill hauptsächlich für bestehende Projekte gedacht ist. Verwende stattdessen vorrangig die Skill „High-Fidelity-Prototyp von Grund auf (HTML) erstellen“.

---

4. Kernprinzipien

1. Erste das Projekt prüfen, dann mit dem Design beginnen

Nicht sofort Code schreiben, nachdem eine Anfrage eingegangen ist.

Zuerst in docs/product/ nach einer Product-Experience-Baseline suchen, die zum aktuellen Projekt und dem entsprechenden Frontend (c-end/ oder admin/) passt. Wenn eine Baseline existiert, lies die darin enthaltenen Produktbegriffe, Navigationen, Seitenmuster, visuellen und Interaktionsregeln. Sie ergänzt die technischen Konventionen des Projektquellcodes, ersetzt aber nicht die Komponentenbibliothek, das Routing und die Datenarchitektur.

Wenn der Benutzer gerade die erste Version von Anforderungen startet oder die aktuelle Funktionalität seitenübergreifend wiederholt auftretende, aber noch nicht definierte Produktregeln aufzeigt, wird empfohlen, zuerst product-experience-foundation zu verwenden. Normale Einzelfunktions-Prototypen dürfen keine globalen Produkt-Baselines erstellen oder überschreiben.

Überprüfe im bestehenden Projekt:

• Benachbarte Seiten
• Seitenlayout-Rahmen
• Routenstruktur
• Komponentenverzeichnis
• Öffentliche Hooks und Utility-Funktionen
• CSS-Variablen
• Themen-Dateien
• Design-Tokens
• Icon-Verwendung
• Tabellenstil
• Formularstil
• Modal- und Drawer-Stil
• Nachrichten- und Benachrichtigungsstil
• Aktuelle State-Management-Methode

Es ist wichtig, Folgendes vom bestehenden Projekt zu verstehen:

• Informationsdichte
• Seitenabstände
• Schriftarten-Hierarchie
• Eckengrößen
• Farbverwendung
• Navigationsstruktur
• Komponenten-Aufrufmuster
• Responsive-Strategien

Neue Inhalte sollten wie eine natürliche Erweiterung des bestehenden Systems wirken, nicht wie ein separates System.

2. Priorisiere Wiederverwendung, bastle nicht das Rad neu

Priorität hat die Wiederverwendung von bereits im Projekt vorhandenen:

• Buttons
• Tabellen
• Formularen
• Dropdown-Auswahlen
• Datumswählern
• Tabs
• Modalen
• Drawern
• Paginierung
• Status-Tags
• Nachrichten-Hinweisen
• Seitenlayout-Komponenten
• Icons
• Utility-Funktionen
• Hooks
• Design-Tokens

Wenn das bestehende Projekt bereits über entsprechende Fähigkeiten verfügt, wird kein zweites Komponentensystem erstellt.

3. Standardmäßige Isolierung des Prototyp-Einstiegs

Der Prototyp muss auf Basis des bestehenden Quellcodes implementiert werden, nicht als eine separate statische Website, die vom Projekt losgelöst ist. Gleichzeitig wird er standardmäßig vom offiziellen Business-Einstieg isoliert.

Bevorzuge eine der folgenden Methoden, die durch bestehende Projektkonventionen unterstützt wird:

• Unabhängige Prototyp-Route, z.B. /__prototype/<feature> oder eine bereits im Projekt vorhandene Demo-Route-Konvention.
• Unabhängige Prototyp-Seite oder Funktionsverzeichnis, die/der nur in der Entwicklungs-/Vorschau-Umgebung zugänglich ist.
• Expliziter Prototyp-Einstieg, der das Standardverhalten der Originalseite nicht ändert, z.B. Query-Parameter, Entwicklungs-Menü oder temporärer Navigationspunkt.

Der Prototyp-Einstieg sollte in der Lage sein, die reale Seitenhülle und Komponenten wiederzuverwenden, darf aber standardmäßig keine Online-Einstiegspunkte ersetzen, bestehende Geschäftsdaten ändern oder andere Funktionen beeinträchtigen. Wenn das Projekt bereits Prototyp-Konventionen hat, müssen diese zuerst befolgt werden. Wenn es keine Konventionen gibt, wähle die Methode mit den geringsten Auswirkungen auf den Produktionscode und der einfachsten Entfernbarkeit. Gib den Ort des Einstiegs in der endgültigen Antwort an.

4. Behandle die Aufgabe als Produktprototyp, nicht als offizielles Refactoring

Diene vorrangig:

• Produkt-Reviews
• Geschäftsdemostrationen
• Anforderungsdiskussionen
• Alignment zwischen Design und Entwicklung
• Schnelle Iterationen

Verwende bevorzugt direkte, einfach zu bearbeitende Implementierungsmethoden.

Führe Folgendes nicht ein, es sei denn, das bestehende Projekt verwendet selbst bereits entsprechende Muster:

• Große globale Refactorings
• Neue Architekturschichten
• Schwere Abhängigkeiten
• Übermäßige Abstraktion
• Komplexe Zustandsautomaten

5. Verwende Mock-Daten, beeile dich nicht mit dem Backend

Sofern der Benutzer es nicht explizit verlangt, tue Folgendes nicht:

• Echte Schnittstellen einbinden
• Backend-APIs entwerfen
• Serviceschicht erstellen
• Produktionsdatenpfade verarbeiten

Mock-Daten sollten möglichst nahe an der Seite oder der aktuellen Funktion platziert werden, damit der Produktmanager sie leicht anpassen kann.

Verwende lokalen State zum Simulieren von:

• Hinzufügen
• Bearbeiten
• Löschen
• Suchen
• Filtern
• Sortieren
• Tab-Wechsel
• Auswählen
• Statusänderungen
• Drawer öffnen
• Modal öffnen
• Formular absenden
• Bestätigung mit zweiter Rückfrage
• Erfolgsmeldung
• Fehlermeldung

6. Der Prototyp muss klickbar sein

Zusätzlich zum Kern-Hauptablauf sollten je nach Bedarf auch Zustände ergänzt werden, die der Produktmanager während der Review prüfen muss:

• Suchen
• Filtern
• Tabs
• Auswählen
• Detailansicht
• Leerzustand
• Ladezustand
• Formularvalidierung
• Deaktivierter Zustand
• Bestätigung mit zweiter Rückfrage
• Erfolgs-Feedback
• Fehler-Feedback
• Rückweg
• Mehrschritt-Navigation

Wenn die Anforderung mehrere Schritte umfasst, sollte der Ablauf vollständig durchklickbar sein, anstatt mehrere unzusammenhängende statische Seiten zu hinterlassen.

7. Mache aus einem Geschäftssystem keine Marketing-Website

Wenn der Benutzer eine App, ein Tool, ein Admin-System, ein CRM, ein Betriebssystem oder einen Business-Workbench benötigt:

• Erstelle keinen übergroßen Hero-Header.
• Verwende nicht vorrangig marketingorientierte visuelle Kompositionen.
• Verwende keine dekorativen Verläufe und Hintergründe als Hauptvisuell.
• Reduziere nicht drastisch die Informationsdichte zugunsten der Optik.
• Ersetze keine echten Business-Controls durch Marketing-Karten.

---

5. Analyse vor dem Codieren

Bevor mit dem Schreiben von Code begonnen wird, extrahiere aus der Anforderung und dem Projekt:

• Produktziel
• Zielbenutzer oder -rollen
• Kernaufgaben, die der Benutzer erledigen muss
• Seiten, die neu erstellt oder geändert werden müssen
• Vorhandene ähnliche Seiten
• Seiteneinstieg
• Hauptbenutzerablauf
• Erforderliche Felder
• Erforderliche Zustände
• Berechtigungsunterschiede verschiedener Rollen
• Müssen implementierte Interaktionen
• Mock-Daten-Anforderungen
• Produktannahmen
• Noch nicht geklärte Geschäftsregeln

Frage nicht erneut nach Informationen, die der Benutzer bereits bereitgestellt hat.

Wenn nur Details auf der Präsentationsebene fehlen, können vernünftige Annahmen getroffen werden.

Es dürfen keine Kern-Geschäftsregeln ergänzt werden, die den Produktumfang ändern würden.

---

6. Projekt-Prüfablauf

Schritt 1: Technologie-Stack identifizieren

Bestätigen:

• Frontend-Framework
• Build-Tool
• Routing-Methode
• UI-Komponentenbibliothek
• Icon-Bibliothek
• Style-Lösung
• State-Management-Methode
• Datenabfrage-Konventionen
• Test- oder Vorschaumethode

Schritt 2: Nach ähnlichen Seiten suchen

Priorität bei der Suche:

• Gleichartige Listenseiten
• Gleichartige Detailseiten
• Gleichartige Formulare
• Gleichartige Daten-Dashboards
• Gleichartige Modale oder Drawer
• Gleichartige Geschäftsabläufe
• Gleichartige Leer-, Lade- und Fehlerzustände

Diese Seiten dienen als Implementierungsreferenz für die neuen Seiten.

Schritt 3: Wiederverwendbare Elemente identifizieren

Liste der diesmal wiederzuverwendenden Elemente:

• Komponenten
• Hooks
• Design-Tokens
• Utility-Funktionen
• Seitenlayouts
• Interaktionsmuster

Vermeide die doppelte Implementierung bereits vorhandener Fähigkeiten.

Schritt 4: Vorhandenes visuelles System verstehen

Überprüfen:

• Seitenbreite
• Innenabstand des Content-Bereichs
• Modulabstände
• Schriftarten-Hierarchie
• Button-Stil
• Formulardichte
• Tabellendichte
• Statusfarben
• Rahmenstil
• Schattenverwendung
• Responsive Breakpoints

Schritt 5: Prototyp-Umfang festlegen

Klarstellen:

• Wo der Prototyp-Einstieg platziert wird und wie er vom offiziellen Einstieg isoliert wird.
• Welche Prototyp-Seiten oder -Module neu hinzugefügt werden müssen.
• Ob der Benutzer explizit die Änderung bestehender Geschäftsseiten verlangt hat.
• Welche Interaktionen klickbar sein müssen.
• Welche Daten Mock-Daten verwenden.
• Welche Zustände dargestellt werden müssen.
• Welche Produktannahmen notwendig sind.
• Welche produktweiten Seitenmuster von der aktuellen Funktion wiederverwendet werden.
• Welche neuen Muster nur auf die aktuelle Funktion beschränkt sind und welche als Kandidaten für eine spätere Übernahme in die Baseline dienen könnten.

---

7. Mock-Daten-Standards

Mock-Daten sollten eine echte Geschäftssprache verwenden.

Vermeide:

• Test User
• Lorem ipsum
• Company A
• Sample Data
• User 001

Mock-Daten sollten möglichst Folgendes abdecken:

• Unterschiedliche Zustände
• Lange Texte
• Fehlende Werte
• Warnmeldungen
• Grenzfälle
• Unterschiedliche Benutzerentscheidungen
• Unterschiedliche Geschäftsphasen
• Leere Ergebnisse
• Deaktivierte Aktionen

Der Zweck von Mock-Daten ist nicht, die Seite zu füllen, sondern dem Produktmanager zu helfen, Probleme auf der Seite und bei der Interaktion zu entdecken.

---

8. Produktannahmen-Regeln

Die KI kann vernünftige Details auf der Präsentationsebene ergänzen, z.B.:

• Beispielnamen
• Beispieldaten
• Beispiel-Listendaten
• Leerzustand-Texte
• Erfolgs- und Fehlermeldungen
• Häufige Filterbedingungen
• Interaktionsmuster, die zu den Gewohnheiten des bestehenden Projekts passen

Die KI darf nicht stillschweigend folgende Kern-Geschäftslogik ergänzen:

• Neue Geschäftsstatus
• Neue Rollenberechtigungen
• Neue Genehmigungsregeln
• Neue Geschäftsberechnungsmethoden
• Neue Verwaltungsmodule
• Neuer Produktumfang
• Neue externe Systemabhängigkeiten

Wenn zur Demonstration Annahmen getroffen werden müssen, sollten diese in der endgültigen Antwort zusammenfassend erläutert werden.

Wenn eine neue Interaktion mit der Product-Experience-Baseline kollidiert, darf sie nicht stillschweigend überschrieben werden. Folge entweder der bestätigten Baseline oder liste den Grund für die Abweichung und die Frage „Soll die Baseline zurückgeschrieben werden?“ als zu klärende Punkte auf.

---

9. UI- und Interaktionsstandards

1. Informationsarchitektur

Priorität hat:

• Klare Hierarchie
• Sinnvolle Gruppierung
• Effektive Feldauswahl
• Hervorgehobene Hauptaktionen
• Stabile Informationsdichte
• Die Seite ist leicht scanbar

2. Steuerelementauswahl

Bevorzuge dem Benutzer vertraute Steuerelemente:

• Tool-Aktionen mit Icon-Buttons
• Moduswechsel mit Segmented Controls
• Binäre Einstellungen mit Schaltern oder Checkboxen
• Nummerische Einstellungen mit Eingabefeldern, Schiebereglern oder Steppern
• Mehrfachauswahl mit Menüs oder Dropdowns
• Gleichrangige Ansichten mit Tabs
• Sekundäre Aufgaben mit Drawern oder Modalen

3. Kartenverwendung

Vermeide Kartenverschachtelung (Karten in Karten).

Karten eignen sich für:

• Wiederholte Listenelemente
• Modale
• Drawer
• Eigenständige Tools
• Datengruppen, die eine klare Begrenzung benötigen

Verpacke nicht jeden Block einer Seite als Karte.

4. Dekorative Elemente kontrollieren

Vermeiden:

• Dekorative Farbverläufe/-leuchten
• Schwebende Kreise
• Bokeh-Effekte
• Sinnlose SVG-Dekorationen
• Reine Atmosphären-Hintergründe
• Marketing-Hero-Bereiche
• Eine einzelne Farbtönung, die die gesamte Seite ausfüllt

Überprüfe nach der Implementierung das CSS. Wenn die Seite fast nur noch aus einer Farbskala besteht, sollte entsprechend angepasst werden.

Besonders zu vermeiden:

• Große Flächen mit Lila oder Blau-Lila-Verläufen
• Große Flächen in Beige oder Sandfarbe
• Große Flächen in Dunkelblau oder Graublau
• Große Flächen in Braun oder Orange

5. Text- und Layoutstabilität

Stelle sicher, dass Text in folgende Elemente passt:

• Buttons
• Tabellenzellen
• Karten
• Seitenleisten
• Drawer
• Modale
• Mobile Container

Verwende nach Bedarf:

• Automatischen Zeilenumbruch
• Textabschneidung (Truncation)
• Minimale und maximale Breiten
• Stabile Grids
• aspect-ratio
• Container-relative Maße

Skaliere Schriftarten nicht dynamisch basierend auf der Viewport-Breite.

Sofern das bestehende Designsystem nichts anderes erfordert, bleibt der Buchstabenabstand bei 0.

6. Erkläre den Prototyp nicht innerhalb der Produktoberfläche

Zeige in der Seite keine Erklärungen wie:

• Wie dieser Prototyp erstellt wurde.
• Welche temporären Lösungen verwendet wurden.
• Wie Überprüfer die Seite verstehen sollten.
• Welche Interaktionen simuliert sind.

Füge nur dann Anleitungen in der Oberfläche hinzu, wenn das Produkt selbst tatsächlich Hilfetexte benötigt.

---

10. Responsive-Umfang

Desktop-Admin-Systeme

Wenn das Projekt eindeutig ein Desktop-Admin-System ist:

• Priorisiere zuerst den Desktop.
• Halte eine stabile Informationsdichte.
• Stelle sicher, dass es auf kleinen Bildschirmen nicht völlig auseinanderfällt.
• Vermeide, dass wichtige Aktionen nicht erreichbar sind.
• Vermeide unnötiges horizontales Scrollen so weit wie möglich.

Mobile oder Consumer-Produkte

Wenn das Produkt für Endverbraucher gedacht ist, einen Mobile-First-Ansatz hat oder der Benutzer explizit Mobile anfordert:

• Gestalte das mobile Layout und die Interaktionen ebenfalls sorgfältig.
• Überprüfe die Größe der Touch-Bereiche.
• Überprüfe das Abschneiden von Steuerelementen.
• Überprüfe fixierte Positionselemente.
• Überprüfe Sicherheitsabstände.
• Überprüfe bei Bedarf das Verhalten der Tastatur und von Formularen.

Alle Seiten müssen überprüft werden auf

• Textüberlappungen
• Abschneiden von Steuerelementen
• Versteckte Aktions-Einstiegspunkte
• Bruchstellen in der Seitennavigation
• Horizontales Überlaufen
• Tabellen, die unlesbar sind
• Drawer oder Modale, die nicht verwendet werden können

---

11. Implementierungsablauf

Schritt 1: Bestehendes Projekt lesen

Überprüfe die relevanten Projektstrukturen und ähnlichen Seiten.

Schritt 2: Prototyp-Einstieg und -Umfang klären

Zusammenstellen:

• Position der Prototyp-Seite, -Route oder des Funktionsverzeichnisses
• Methode der Isolierung vom offiziellen Business-Einstieg
• Vorhandene Seiten oder Module, die nur auf expliziten Wunsch des Benutzers geändert werden
• Kernbenutzerablauf
• Müssen implementierte Interaktionen
• Mock-Daten-Zustände
• Wiederverwendbare Komponenten

Schritt 3: Vorhandene Projektmethode für den unabhängigen Prototyp übernehmen

Beibehalten der bestehenden:

• Technologie-Frameworks
• Komponentensysteme
• Style-Methoden
• Routing-Methoden
• Icons
• Utility-Funktionen
• State-Management-Gewohnheiten

Schritt 4: Mock-Daten und Interaktionen hinzufügen

Verwende lokalen State, um den für diese Review erforderlichen vollständigen Ablauf zu implementieren.

Schritt 5: Notwendige Zustände ergänzen

Füge nur Zustände hinzu, die für die aktuelle Funktion relevant sind:

• Leerzustand
• Ladezustand
• Validierungszustand
• Deaktivierter Zustand
• Erfolgszustand
• Fehlerzustand
• Bestätigung mit zweiter Rückfrage
• Nicht berechtigter Zustand
• Daten nicht verfügbar Zustand

Schritt 6: Projekt tatsächlich ausführen

Starte bei Bedarf den bestehenden lokalen Entwicklungsserver.

Bevor das Projekt nicht in der Vorschau betrachtet werden kann, sollte nicht behauptet werden, die Aufgabe sei abgeschlossen.

Schritt 7: Visuelle und Interaktionsprüfung durchführen

Überprüfen:

• Die Seite ist nicht leer.
• Styles werden korrekt geladen.
• Icons und Ressourcen werden normal angezeigt.
• Text läuft nicht offensichtlich über.
• Das Layout macht keine ungewöhnlichen Sprünge.
• Kerninteraktionen können verwendet werden.
• Die Navigation hat keine Sackgassen.
• Das responsive Verhalten ist akzeptabel.

Wenn möglich, Überprüfung mit Browser-Inspektion oder Screenshots.

---

12. Endgültige Liefergegenstände

Je nach Aufgabenstellung sollten die endgültigen Ergebnisse Folgendes umfassen:

• Neu erstellter oder geänderter Frontend-Quellcode.
• Unabhängige Prototyp-Seite, -Verzeichnis oder -Route mit Einstiegshinweis.
• Nur auf explizite Anforderung des Benutzers geänderte bestehende Geschäftsseiten.
• Wiederverwendete gemeinsame Komponenten.
• Lokale Mock-Daten.
• Klickbare Kerninteraktionen.
• Relevante Leer-, Lade-, Validierungs-, Deaktivierungs-, Erfolgs- und Fehlerzustände.
• Normal nutzbare Seitennavigation.
• Hinweise zum Ausführen oder Anzeigen des Projekts.
• Erläuterung der Produktannahmen.
• Liste der noch unklaren Geschäftsregeln.
• Falls eine demo.md erstellt wurde, notiere darin die Review-Ergebnisse und zu klärende Punkte. Sie dient nur als Übergabe-Marker und ersetzt nicht die eigenen Engineering-Artefakte des Projekts.

Erstelle keine übermäßige Anzahl zusätzlicher Dokumentationen oder Architekturdateien, es sei denn, sie helfen beim Ausführen oder bei der Überprüfung.

---

13. Abschlusskriterien

Der Prototyp gilt erst dann als abgeschlossen, wenn folgende Bedingungen erfüllt sind:

• Die Prototyp-Seite oder das -Modul existiert im aktuellen Projekt und ist vom offiziellen Business-Einstieg isoliert (es sei denn, der Benutzer hat explizit die Überschreibung des ursprünglichen Einstiegs verlangt).
• Der visuelle Stil ist konsistent mit dem bestehenden Projekt.
• Vorhandene Komponenten und Design-Tokens wurden sinnvoll wiederverwendet.
• Der Kernbenutzerablauf kann von Anfang bis Ende durchlaufen werden.
• Jede Hauptaktion hat ein klares Feedback.
• Die Seitennavigation hat keine Sackgassen.
• Mock-Daten aktualisieren sich nach wichtigen Aktionen.
• Relevante Seitenzustände werden dargestellt.
• Text läuft nicht offensichtlich über.
• Das Projekt kann lokal normal ausgeführt werden, ohne blockierende Fehler.
• Der bereits bestätigte Produktumfang wurde nicht eigenmächtig erweitert.
• Die endgültige Antwort enthält eine klare Erläuterung der Produktannahmen und der noch zu klärenden Regeln.

---

14. Anforderungen an die endgültige Antwort

Nach Abschluss, erkläre auf eine für den Produktmanager leicht verständliche Weise:

• Welche Seiten, Module und Abläufe neu erstellt oder geändert wurden.
• Wo sich der Prototyp-Einstieg befindet und wie er vom offiziellen Business-Einstieg isoliert ist.
• Welche Interaktionen derzeit klickbar sind.
• Welche Mock-Daten und Seitenzustände hinzugefügt wurden.
• Welche vorhandenen Komponenten und Projektstandards wiederverwendet wurden.
• Welche Produktannahmen getroffen wurden.
• Welche Geschäftsregeln noch zu klären sind.
• Wie der Prototyp ausgeführt oder in der Vorschau betrachtet werden kann.
• Welche visuellen und Interaktionsprüfungen durchgeführt wurden.
• Welche Product-Experience-Baselines wiederverwendet wurden; falls sich ein neues Muster wiederholt, erkläre, ob es nur ein Kandidat ist, der nicht als globale Regel extrahiert wird, bevor er bestätigt ist.
• Nach der Review-Bestätigung wird die Entwicklung gemäß dem Prototyp umgesetzt; in der Prototyp-Phase werden keine Engineering-Artefakte vorgetäuscht und kein Produktionscode eigenmächtig implementiert.

Die endgültige Antwort sollte prägnant sein und den Schwerpunkt auf die Inhalte legen, die der Produktmanager überprüfen muss.