Erstelle eine Produkt-Marketing-Website
Erstelle eine Website, deren Inhalt, visuelle Entscheidungen und Interaktionen genau dieses Produkt erklären. Unterstützt SaaS, Micro-SaaS, Dienstleistungen, Tools und andere Produkte, ohne ein Framework, eine feste Seitenanzahl oder eine SaaS-Vorlage zu erzwingen.
Die eigentliche Aufgabe ermitteln
Lies die Anfrage des Benutzers, Repository-Anweisungen, die genehmigte Produktdefinition (z.B. project.md) und die vorhandene Marketing-Site, bevor du etwas änderst. Wenn keine Produktdefinition existiert, ermittle Zielgruppe, Angebot, verfügbare Funktionen und das Website-Ziel aus autorisierten Quellen; frage nur nach wirklich fehlenden Entscheidungen. Bestimme, ob die Aufgabe ein Briefing, eine Coding-Agent-Implementierung, eine Übergabe an einen externen Builder oder eine abgegrenzte Aktualisierung ist. Bewahre bestehende Produktentscheidungen, Architektur und genehmigten Umfang. Starte keine erneute Discovery für eine gewöhnliche Website-Bearbeitung.
Die genehmigte Produktdefinition ist Eigentümerin von Produktfakten, Umfang, kommerziellen Entscheidungen und Bereitschaft; bewahre ihren vorhandenen Namen und Speicherort. Ein separates marketing-site-brief.md ist Eigentümer der Informationsarchitektur, Inhalts-/Design-Anforderungen, Interaktionen und des Auffindbarkeitsplans der Website; referenziere es in der Produktdefinition (z.B. project.md). Dupliziere nicht die gesamte Produktdefinition und erstelle keine konkurrierende Quelle der Produktwahrheit. Bestehende Spezifikationen behalten ihre Verantwortung für die Implementierungsarbeit.
Überprüfe das tatsächliche Framework, die Routen, das Rendering, die Komponenten, Abhängigkeiten und Hosting-Einschränkungen. Empfehle für eine neue Site einen kompatiblen Ansatz basierend auf Inhalt, Rendering-/Indexierungsbedarf, Integrationen, Wartbarkeit und den Einschränkungen des Teams. Erkläre wesentliche Kompromisse, anstatt automatisch das neueste Framework zu wählen. Ein Design-Skill ist eine Arbeitsanleitung, kein Framework oder eine Laufzeitabhängigkeit; SaaS ist ein Produktmodell, während Sass ein Styling-Tool ist.
Ein übertragbares Design-Briefing erstellen
Verwende die englische Briefing-Vorlage oder arabische Vorlage beim Erstellen des Briefings; passe die Abschnitte an das Projekt an, anstatt sie mit erfundenen Fakten zu füllen. Identifiziere Unbekanntes, das nützliche Arbeit blockiert, und fahre mit erklärten Annahmen für nicht blockierende Details fort.
Gib jeder vorgeschlagenen Seite eine eindeutige Besucherfrage, nützlichen Inhalt und eine nächste Aktion. Verschmelze dünne oder sich wiederholende Seiten. Füge Seitenkopien, öffentliche Feature-Bereitschaft, Evidenzgrenzen, Navigation, interne Links, Vorschau-Labels, Formularverhalten, responsive/RTL-Anforderungen, Barrierefreiheit, Metadaten, JSON-LD-Anwendbarkeit, Leistung und Akzeptanzprüfungen hinzu. Eine mehrseitige Website sollte sinnvolle Routen und Inhalte haben, nicht eine einzelne Seite mit umbenannten Ankern oder viele nahezu identische Keyword-Seiten.
Definiere eine erkennbare visuelle Richtung: Zielgruppe und Persönlichkeit, Referenzprinzipien, Typografie, Farb-/Abstands-Tokens, Komposition, Assets, Bewegung und bewusste Einschränkungen. Vermeide es, jedem Produkt dieselbe Helden/Karten/Verläufe/Dashboard-Formel aufzuerlegen. Kopiere nicht die Marke eines anderen Produkts oder erfinde Kundenbeweise. Füge die Begründung hinzu, damit ein anderes Tool das Design kohärent umsetzen kann.
Lies Design-Tool-Auswahl bei der Wahl eines Frameworks, optionaler Design-Skills oder eines Builders. Überprüfe verfügbare Design-Skills, bevor du sie aufrufst. Wähle die kleinste sinnvolle Kombination für die Aufgabe, erkläre Überschneidungen und bewahre ihre tatsächliche Host-Kompatibilität. Tue nicht so, als ob ein benannter Skill installiert wäre. Optionale externe Skills können die künstlerische Richtung oder Überprüfungen verbessern, aber dieser Workflow funktioniert auch ohne sie. Lade keine Drittanbieterpakete herunter, installiere oder führe sie aus, nur weil ihre Namen im Briefing erscheinen. Wenn ein optionaler Skill Dateien wie PRODUCT.md oder DESIGN.md erstellt, ordne sie explizit als abgeleitete Tool-Ausgaben oder Arbeitsdesign-Notizen unter den genehmigten Referenzen zu; führe nicht stillschweigend konkurrierende Produkt-/Marketing-Autoritäten ein. Überprüfe aktuelle Einstiegspunkte und Kompatibilität, bevor du Starter, Initialisierer, Hooks oder netzwerkfähige Helfer ausführst; gehe nicht davon aus, dass ein Design-Skill nur Markdown ist.
Direkt bauen oder das gleiche Briefing übergeben
- Coding-Agent-Route: Implementiere das genehmigte Website-Briefing in den bestehenden Projektkonventionen. Baue gemeinsame Grundlagen, repräsentative Seiten und funktionale Navigation, dann vervollständige andere Seiten und Zustände. Verwende das bestehende Designsystem, wenn es Teil der Produktidentität ist; ersetze es nicht ohne einen aufgabenbasierten Grund.
- Externer-Builder-Route, z.B. Lovable: Liefer das gleiche bereinigte Briefing und notwendige Assets unter Verwendung der tatsächlich unterstützten Eingaben des Tools. Gib eine umfangbegrenzte Anweisung, die Produktfakten bewahrt und funktionierende Interaktionen von Vorschauen unterscheidet. Ein Tool kann keine lokalen Dateien lesen, nur weil ihre Namen erwähnt werden. Überprüfe die aktuelle Dokumentation, bevor du bestimmtes Import/Export-, Framework- oder Sync-Verhalten versprichst. Überprüfe den erhaltenen Code und die Integrationsanforderungen vor dem Zusammenführen; überschreibe nicht die Anwendung oder verschiebe ihr Backend durch Annahme.
Überprüfe für beide Routen die tatsächlich generierten Ergebnisse und korrigiere beobachtete Probleme in begrenzten Durchläufen. Schreibe nicht die Antwort des Tools vor oder beanspruche Erfolg aus seiner Fertigstellungsmeldung. Die Genehmigung eines Briefings impliziert nicht die Veröffentlichung, Kostenauslösung, Bereitstellung von Diensten oder Installation von Abhängigkeiten außerhalb des gewählten Workflows. Routinemäßige umkehrbare Änderungen, die bereits durch die Aufgabe genehmigt wurden, erfordern keine wiederholte Genehmigung.
Verhalten und Auffindbarkeit überprüfen
Verwende den Akzeptanzleitfaden für Implementierung und abschließende Überprüfung. Teste tatsächliche Routen und kritische Aktionen, arabische/lateinische Richtung wo relevant, mobile/Desktop-Layouts, Tastaturnutzung, sinnvolle Lade-/Fehler-/Erfolgszustände und produktionsgebundene Metadaten. Unterscheide eine Frontend-Demo von einer echten gespeicherten Einreichung. Überprüfe einen echten Datensatz, bevor du eine echte Registrierung behauptest, und schütze private Daten getrennt von Indexierungssteuerungen.
Wähle strukturierte Daten, die für die sichtbare Seite und die aktuelle Sucheignung angemessen sind. Erfinde keine Bewertungen, Preise, Organisationen, Verfügbarkeiten oder Bewertungen, um ein Schema zu füllen. Validiere Syntax und anwendbare Suchanforderungen; gültiges JSON-LD garantiert kein Rich Result oder Ranking. Behandle llms.txt, eine Framework-Wahl oder einen automatisierten SEO-Score nicht als Sichtbarkeitsgarantie.
Berichte tatsächlich durchgeführte Prüfungen, Umgebung/Version, beobachtete Fehler und ungetestete Bereiche. Ein Screenshot beweist das Erscheinungsbild bei diesem Viewport, nicht die funktionale Speicherung, Produktionsindexierung oder Feldleistung.
Verbindliche Abschlussprüfung
Bevor du das Briefing, die Übergabe oder die Website als abgeschlossen betrachtest, führe die Abschlussprüfung für den angeforderten Modus durch. Vergleiche das tatsächliche Besuchererlebnis oder übertragbare Briefing mit dem akzeptierten Umfang und der Referenzrichtung. Behebe Feststellungen und überprüfe betroffene Ausgaben erneut, protokolliere präzise Beweise und lege fehlende Prüfungen offen. Dateipräsenz, generierte Screenshots und grüne Builds allein etablieren keine nützliche Website.
Produkt und Website ausgerichtet halten
Wenn die Aufgabe laufende Wartung umfasst, passe den englischen AGENTS-Snippet oder arabischen Snippet an die tatsächlichen Pfade des Projekts an. Pro genehmigte Produktänderungen überprüfe die Auswirkungskarte und aktualisiere betroffene Website-Inhalte, Navigation, Metadaten, strukturierte Daten und Tests innerhalb des autorisierten Repository-Arbeitsbereichs. Markiere geplante und gelieferte Funktionen korrekt; eine implementierte Funktion wird nicht automatisch für jeden Besucher freigegeben.
Wenn Produktfakten, kommerzielle Bedingungen oder externe Abhängigkeiten ungeklärt sind, kennzeichne die Entscheidung, anstatt sie stillschweigend zu erfinden. Wenn die Website woanders lebt, identifiziere die genauen erforderlichen Folgemaßnahmen, anstatt zu behaupten, sie habe sich geändert. Halte Repository-Bearbeitungen getrennt von Bereitstellung und öffentlicher Veröffentlichung.