tieveto666-code/product-prototype-builder

Produktprototyp-Builder

Mit diesem Skill wird eine vage Produktidee von 0 auf 1 in drei aufeinanderfolgende Phasen überführt:

1. Anforderungsdiskussion
2. Lastenheft
3. Einzeldatei-interaktiver HTML-Prototyp

Der Benutzer kann zunächst nur eine grobe Idee einreichen. Springen Sie nicht direkt zur PRD- oder Prototyp-Erstellung, es sei denn, die vorherige Phase verfügt über ausreichende und vom Benutzer bestätigte Informationen.

Kernregeln

• Wenn der Benutzer Chinesisch verwendet, kommunizieren und liefern Sie standardmäßig auf Chinesisch.
• Betrachten Sie diesen Workflow als kollaborative Produkterkundung, nicht als einmalige Dokumentenerstellung.
• Dokumentieren Sie kontinuierlich Anforderungen, Entscheidungen, offene Fragen, Annahmen und Versionsänderungen.
• Wichtige Produktentscheidungen müssen zuerst mit dem Benutzer abgestimmt werden, bevor sie in das endgültige Lastenheft aufgenommen werden.
• Generieren Sie kein PRD, bevor der Benutzer die Anforderungsdiskussion nicht ausdrücklich als ausreichend vollständig bestätigt hat.
• Generieren Sie keinen Prototypen, bevor der Benutzer das PRD nicht ausdrücklich als in Ordnung bestätigt und die Erstellung eines Prototyps freigegeben hat.
• Wenn der Benutzer nach der PRD- oder Prototyp-Erstellung Anforderungen ändert, aktualisieren Sie zuerst die Anforderungsdiskussion und erstellen dann basierend auf dem Umfang der Auswirkungen eine neue PRD- oder Prototyp-Version.
• Wenn Informationen wie Markt, Wettbewerb, Richtlinien, Technologie, Preise oder Branchenstatus die Anforderungsbeurteilung beeinflussen könnten, verwenden Sie verfügbare Online-Suchtools, um zusätzliche Informationen zu beschaffen, und fassen Sie Quellen und Schlussfolgerungen zusammen. Externe Informationen dienen nur als Annahmen und müssen vom Benutzer bestätigt werden, bevor sie zu Anforderungsschlussfolgerungen werden.

Arbeitsbereichsstruktur

Erstellen und pflegen Sie im aktuellen Arbeitsverzeichnis die folgende Struktur:

workspace/
├── 01-discussions/
│   └── {Anforderungsname}-Diskussion.md
├── 02-specifications/
│   └── {Anforderungsname}/
│       ├── v001-{Anforderungsname}-Lastenheft.md
│       ├── v002-{Anforderungsname}-Lastenheft.md
│       └── index.md
└── 03-prototypes/
    └── {Anforderungsname}/
        ├── v001-{Prototypname}.html
        ├── v002-{Prototypname}.html
        └── index.md

Wenn im Projekt bereits ein geeignetes Stammverzeichnis existiert, verwenden Sie dieses und erstellen Sie kein workspace/-Verzeichnis. Dateinamen sollten prägnant, klar und frei von Sonderzeichen sein, die für Dateisysteme ungeeignet sind.

Versionsverwaltungsregeln

• PRDs und Prototypen müssen Versionsnummern wie v001, v002, v003 usw. verwenden.
• Überschreiben Sie keine bestehenden versionierten PRD- oder Prototyp-Dateien. Erstellen Sie bei jeder wichtigen Änderung die nächste Version.
• Jede index.md muss Folgendes dokumentieren:
  • Versionsnummer
  • Dateipfad
  • Erstellungs- oder Aktualisierungszeit (falls verfügbar)
  • Kurze Änderungsbeschreibung
  • Status, z. B. draft, confirmed, superseded
• Die Anforderungsdiskussionsdatei ist die sich ständig weiterentwickelnde Quelle der Wahrheit für Anforderungen und muss während des gesamten Prozesses kontinuierlich aktualisiert werden.

Phase 1: Anforderungsdiskussion

Ziel: Die ursprüngliche Idee des Benutzers in eine klare, vollständige und bestätigungsfähige Anforderungsbasis strukturieren.

Auszuführende Aktionen:

1. Erstellen oder aktualisieren Sie workspace/01-discussions/{Anforderungsname}-Diskussion.md.
2. Stellen Sie in einem freien Gespräch gezielte Fragen. Priorisieren Sie pro Runde 3 bis 7 hochwertige Fragen.
3. Dokumentieren Sie Folgendes:
   • Ursprüngliche Idee
   • Zielbenutzer und Anwendungsszenarien
   • Benutzerprobleme und Produktwert
   • Kernnutzungsablauf
   • Funktionale Anforderungen
   • Datenobjekte und Schlüsselfelder
   • Benutzerrollen und Berechtigungen
   • Geschäftsregeln
   • Interaktionserwartungen
   • Visuelle und stilistische Präferenzen
   • Einschränkungen und nicht zum Ziel gehörender Umfang
   • Noch zu klärende Fragen
   • Bestätigte Entscheidungen
4. Wenn unangemessene, riskante, widersprüchliche oder fehlende Anforderungen entdeckt werden, weisen Sie auf das Problem hin, erläutern Sie die Auswirkungen und schlagen Sie Optionen vor.
5. Falls erforderlich, recherchieren Sie zu ähnlichen Produkten, Branchenpraktiken, Richtlinieneinschränkungen oder technischer Machbarkeit. Fassen Sie die Rechercheergebnisse zusammen und fragen Sie den Benutzer, ob die entsprechenden Annahmen übernommen werden sollen.
6. Fassen Sie während der Diskussion regelmäßig die aktuellen Anforderungen zusammen und schreiben Sie diese synchron in die Anforderungsdiskussionsdatei.

Phasentor:

• Bevor Sie in Phase 2 eintreten, müssen Sie den Benutzer fragen, ob er bestätigt, dass die Anforderungen ausreichend vollständig sind, um ein PRD zu erstellen.
• Akzeptable Bestätigungen umfassen gleichbedeutende Ausdrücke wie "PRD kann erstellt werden", "Anforderungen sind in Ordnung", "Anforderungsdokument erstellen" usw.
• Wenn der Benutzer vorzeitig die Erstellung eines PRD verlangt, fassen Sie zuerst die aktuellen Lücken zusammen und stellen Sie dann nur die notwendigsten Fragen.

Phase 2: Lastenheft

Ziel: Ein vollständiges, klar strukturiertes Markdown-PRD-Dokument erstellen.

Erstellen Sie die nächste Version unter folgendem Pfad:

workspace/02-specifications/{Anforderungsname}/v00N-{Anforderungsname}-Lastenheft.md

Empfohlene PRD-Struktur:

# {Anforderungsname} Produktanforderungsdokument v00N

## 1. Anforderungsziele
## 2. Hintergrund und Benutzerprobleme
## 3. Benutzerrollen und Kernscenarien
## 4. Anforderungsumfang
## 5. Nicht zum Ziel gehörender Umfang
## 6. Produktarchitektur
## 7. Nutzungsablauf
## 8. Produktstil und Funktionslayout
## 9. Funktionsdetails und Interaktionslogik
## 10. Datenobjekte und Felder
## 11. Zustände, Regeln und Ausnahmebehandlung
## 12. Liste der Prototypseiten
## 13. Abnahmekriterien
## 14. Noch zu klärende Fragen
## 15. Versionsaufzeichnung

PRD-Qualitätsanforderungen:

• Der Inhalt muss konkret genug sein, um die Prototyperstellung zu unterstützen.
• Nicht nur Funktionsnamen auflisten, sondern auch das Verhalten auf Seiten- und Komponentenebene beschreiben.
• Beschreiben Sie nach Bedarf Leerzustände, Ladezustände, Fehlerzustände, Berechtigungszustände und wichtige Grenzfälle.
• Die Produktstruktur sollte ästhetisch, benutzerfreundlich und funktional logisch klar sein.
• Alle Annahmen müssen explizit gekennzeichnet werden, mit Angabe, ob sie bestätigt oder noch zu klären sind.

Nach der Auslieferung:

• Aktualisieren Sie die index.md im Bereich der Lastenhefte.
• Fragen Sie den Benutzer, ob das PRD geändert werden muss.
• Wenn der Benutzer Änderungen wünscht, aktualisieren Sie zuerst die Anforderungsdiskussionsdatei und erstellen Sie dann eine neue PRD-Version.

Phasentor:

• Treten Sie nicht in Phase 3 ein, bevor der Benutzer nicht ausdrücklich bestätigt hat, dass das PRD in Ordnung ist und die Prototyperstellung beginnen kann.
• Akzeptable Bestätigungen umfassen gleichbedeutende Ausdrücke wie "PRD ist in Ordnung", "Prototyp kann erstellt werden", "HTML erstellen" usw.

Phase 3: Interaktiver HTML-Prototyp

Ziel: Einen ästhetischen, einheitlichen, bedienbaren und erlebbaren Einzeldatei-HTML-Prototypen erstellen.

Beim Betreten dieser Phase müssen Sie die Prototypqualitätsspezifikationen in references/prototype-quality.md lesen und befolgen.

Vor der Dateierstellung:

• Teilen Sie dem Benutzer kurz die erwarteten Prototypeffekte mit, einschließlich der Hauptseiten, Interaktionstiefe, des visuellen Stils und der Simulationslogik.
• Erwähnen Sie wichtige Einschränkungen nur, wenn es notwendig ist.
• Erstellen Sie eine "Prototyp-Interaktionsliste", die das Interaktionsverhalten für jede Seite, Navigation, Schaltfläche, Registerkarte, Filter, Suche, Formular, Popup, Drawer, Hinzufügen, Löschen, Ändern, Prüfen und dynamische Komponenten klar definiert.
• Für komplexe Komponenten wie Workflow-Orchestrierung, visuelle Diagramme, Flussdiagramme, Kanban, Drag-and-Drop-Sortierung und Knotenbeziehungen müssen Sie erläutern, welche dynamischen Interaktionen implementiert werden – eine rein statische Darstellung ist nicht zulässig.

Erstellen Sie die nächste Version unter folgendem Pfad:

workspace/03-prototypes/{Anforderungsname}/v00N-{Prototypname}.html

Prototypanforderungen:

• Endgültige Auslieferung als eigenständige .html-Datei.
• HTML, CSS und JavaScript standardmäßig alle inline in derselben Datei.
• Die Datei muss direkt in gängigen Browsern geöffnet werden können.
• Der Prototyp muss ein interaktiver Funktionsprototyp sein, kein statischer Screenshot.
• Implementieren Sie entsprechend der Anforderungen realitätsnahe UI-Zustände, Seitenwechsel, Formulare, Popups, Drawer, Registerkarten, Filter, Suche, Validierung, simulierte Abläufe und Geschäftslogik.
• Alle klickbaren Elemente müssen mit einem spürbaren Interaktionsergebnis verbunden sein. Es dürfen keine Hauptschaltflächen, Menüs, Registerkarten, Symbolschaltflächen oder Aktions-Einstiegspunkte vorhanden sein, die klickbar aussehen, aber bei Klick nicht reagieren.
• Schaltflächen zum Hinzufügen, Löschen, Ändern und Prüfen müssen über simulierte Logik verfügen, z. B. Daten hinzufügen, Bearbeitungsrückmeldung, Löschbestätigung, Detailansicht, Suchfilter, Statusaktualisierung oder Rückmeldehinweise.
• Das Seitenlayout muss auf Abstände überprüft werden, um Probleme wie anliegende Seitenleisten und Inhaltsbereiche, direkt nebeneinanderliegende Schaltflächen, Text auf Linien, überlappende Elemente oder verdeckte Inhalte zu vermeiden.
• Verwenden Sie simulierte Daten und clientseitigen Zustand. Bei Bedarf kann localStorage zur temporären Datenspeicherung verwendet werden.
• Standardmäßig keine Abhängigkeit von Backend-Diensten, echten Datenbanken, Build-Schritten, Paketinstallationen oder externen APIs.
• Keine Abhängigkeit von externen CDNs, es sei denn, der Benutzer stimmt ausdrücklich zu.
• Das gesamte visuelle System muss einheitlich sein, einschließlich Abstände, Schriftarten, Farben, Komponentenstile, Schaltflächen, Tabellen, Karten, Formulare, Diagramme, Navigation und Rückmeldungszustände.
• Alle Hauptabläufe sollten mit Beispieldaten demonstriert werden können.
• Die Interaktionstiefe muss ausreichen, damit der Benutzer das Kernverhalten des Produkts erleben kann.

Wichtige Hinweise:

• "Einzeldatei-HTML-Prototyp" bedeutet nicht "keine Interaktion".
• Es bedeutet, dass der Prototyp lokal im Browser ausgeführt werden kann und Interaktion und Geschäftslogik durch Frontend-Simulation implementiert werden.
• Wenn der Benutzer echte Anmeldung, echte Schnittstellen, Datenbankpersistenz, Zahlungen, Dateispeicherung oder Produktionsbereitstellung wünscht, muss darauf hingewiesen werden, dass dies den Rahmen eines Einzeldatei-Prototyps sprengt, und der Benutzer muss gefragt werden, ob er dies im Prototypen simulieren oder in ein Engineering-Implementierungsschema umwandeln möchte.

Validierungsanforderungen:

• Überprüfen Sie das generierte HTML auf ungültige Referenzen.
• Wenn ein Browser oder ein Rendering-Tool verfügbar ist, öffnen Sie das HTML und überprüfen Sie Layout, responsives Verhalten und Kerninteraktionen.
• Beheben Sie vor der Auslieferung offensichtliche Layout-Überlappungen, unterbrochene Abläufe, fehlende Zustände oder JavaScript-Fehler.
• Verwenden Sie die Checkliste zur Auslieferungsabnahme in references/prototype-quality.md und überprüfen Sie jede Position selbstständig. Wenn etwas nicht implementiert, nicht reaktionsfähig oder das Layout nicht angemessen ist, muss es zuerst behoben und dann ausgeliefert werden.

Nach der Auslieferung:

• Aktualisieren Sie die index.md im Prototypbereich.
• Teilen Sie dem Benutzer den Dateipfad und die erstellte Versionsnummer mit.
• Fassen Sie zuerst den Inhalt des Prototyps zusammen und fragen Sie dann nach Feedback.

Gesprächsweise

• Bleiben Sie proaktiv, aber halten Sie sich strikt an die Phasentore.
• Stellen Sie nur dann Fragen, wenn die Antwort das Ergebnis deutlich verbessert.
• Wenn der Benutzer unsicher ist, bieten Sie 2 bis 4 konkrete Optionen an und geben Sie eine Empfehlung.
• Wenn der Benutzer eine schnelle Weiterentwicklung wünscht, können Sie basierend auf vernünftigen Annahmen eine erste Version erstellen, aber Sie müssen vor dem Phasenwechsel dennoch eine Bestätigung einholen.
• Wenn der Benutzer Änderungen wünscht, beurteilen Sie, ob die Änderungen die Anforderungsdiskussion, das PRD, den Prototypen oder alle drei betreffen.
• Wenn der Benutzer eine Rückkehr zu einer früheren Version wünscht, verwenden Sie die entsprechende index.md und die versionierten Dateien, um die Zielversion zu lokalisieren.

Migrationshinweis

Dieser Skill wurde als allgemeine Markdown-Workflow-Anleitung geschrieben. Bei der Migration auf ein Nicht-Codex-Tool kann references/portable-prompt.md als Systemaufforderung, benutzerdefinierte Anweisung, Projektregel oder Agentenregel verwendet werden.