ziqingchuan/landingPageSkill (Landingpage erstellen)

Landingpage komponieren

Konvertiert eine user_config_info.json-Konfiguration in eine geschäftlich korrekte, visuell unverwechselbare, direkt im Browser ausführbare Einzeldatei-HTML-Seite für Bildungs-Landingpages. Der Workflow ist in sich geschlossen und benötigt kein externes System.

Konfigurationsvertrag 3.0, Kern: conversionFlow ist die einzige Quelle der Wahrheit für den Konvertierungsprozess.

Eingabe

Datei	Rolle
user_config_info.json	Tatsächliche Konfiguration des aktuellen Projekts (vom Benutzer bereitgestellt)
references/user-config-spec.md	Feldspezifikation: Feldbedeutung, Typen, erlaubte Werte, Standardwerte
references/business-rules.md	Geschäftsregeln: Invarianten für Konvertierung, Buchung, mehrere Kinder & Fächer usw.
references/frontend-design.md	Visuelle Richtung: Themen, Schriftarten, Layout, Anti-Vorlagen-Urteil
references/engineering-conventions.md	Technische Konventionen: CJK-Anpassung, i18n-Rendering-Modus, Namensisolierung, initiales Laden
references/question-bank.json	Standard-Fragenkatalog: Fragetexte, Optionen, Fachzuordnung

Die Referenzdateien sind integriert. Der Benutzer muss nur user_config_info.json bereitstellen.

Priorität

Gültige Konfiguration → Geschäftsinvarianten → Explizite Benutzerwünsche → Technische Konventionen → Ästhetische Richtung

Die Konfiguration ist eine schreibgeschützte Tatsache; sie wird nicht generiert, ergänzt oder validiert. Die Phasenreihenfolge und Knotenreihenfolge von conversionFlow sind nicht veränderbar. Bei Konflikten werden die spezifischen Felder und Regeln genannt; es wird nicht stillschweigend geraten.

Workflow

Schritt 1: Konfiguration abrufen

Lese user_config_info.json. Wenn nicht bereitgestellt, stoppe; bei Parsing-Fehler zeige die Fehlerposition an. Wenn project.notes nicht leer ist, gelten diese als ergänzende Präferenzen des Benutzers zur Struktur, zum Ton und zum visuellen Stil und beeinflussen direkt Schritt 5 (ästhetische Richtung), überschreiben jedoch keine strukturierten Felder oder Funktionsschalter.

Schritt 2: Feldspezifikation lesen

Lese user-config-spec.md vollständig und verstehe die Semantik jedes Feldes. Fokussiere auf die zweistufige Reihenfolge von conversionFlow (Phasenreihenfolge + Knotenreihenfolge) und die 5 Item-Typen (field / question / verification / booking / calendarSync). Keine Schema-Validierung durchführen.

Schritt 3: Schreibgeschütztes Geschäftsmodell erstellen

Extrahiere auf Basis der Konfiguration und der Feldspezifikation im Denkprozess das Geschäftsmodell des aktuellen Projekts:

• Fächer: Einstiegsfach (project.subject) + Zusatzfächer (extraSubjects)
• Konvertierungsprozess: Phasenreihenfolge und Knotenreihenfolge von conversionFlow; die Phase des verification-Knotens bestimmt die Position des Verifizierungscodes
• Felder: Welche aktiviert sind, welche Pflichtfelder, Zugehörigkeit (Eltern/Kind), fachabhängige Felder
• Schalter: booking / multiChild / multiSubject / syncCalendar / contactMode / flowMode
• Pre-Lead-Anforderungen: Alle Feld- und Frage-Knoten in der lead-Phase (in der Reihenfolge der Items)
• Fragenabgleich: Knoten mit kind=question verwenden questionId zum Abgleich mit question-bank.json; wähle je nach project.language die chinesischen oder englischen Texte aus; für die Übermittlung verwende optionId

Schritt 4: Geschäftsregeln lesen

Lese business-rules.md vollständig und extrahiere die unbedingt einzuhaltenden Geschäftsinvarianten. Geschäftsregeln sind Ergebnisbeschränkungen, keine Modullisten – der Agent entscheidet auf Basis dieser Einschränkungen selbstständig über die Informationsarchitektur.

Schritt 5: Ästhetische Richtung entwickeln

Lese frontend-design.md vollständig und führe den zweistufigen Designplan gemäß den Anforderungen durch:

1. Brainstorming: Farbe (4–6 Hex), Schrift (2+ Schriftrollen), Layout (ein Satz + ASCII-Wireframe), Signatur (ein einzelnes, einzigartiges Element)
2. Kritik: Selbstkritik anhand von project.theme, project.adScene, project.notes – jeder Teil, der sich wie eine generische Standardlösung liest, wird geändert; erst nach Bestätigung der Einzigartigkeit wird Code geschrieben

Schritt 6: Seiten-Code generieren

Lese zuerst engineering-conventions.md, um die durch die aktuelle Konfiguration ausgelösten technischen Einschränkungen zu verstehen (CJK-Einheiten, i18n-Rendering-Modus, Namensisolierung, initiales Laden). Diese sind Codequalitätsbarrieren und ändern keine Geschäftsergebnisse.

Gib eine vollständige Einzeldatei-HTML aus:

• <head> mit Meta, Titel, Google Fonts CDN-Einbindung, inline <style>; <body> mit inline <script>
• Keine externen Build-Tools, npm-Pakete oder lokalen Dateien
• CSS inline mit Beachtung der Selektorspezifität; JS inline, das den gesamten, von der Konfiguration geforderten Geschäftsablauf implementiert
• Alle Interaktionen im Browser ausführbar (Formularübermittlung kann gemockt werden, aber mit deutlicher Kennzeichnung)
• Dekorative Elemente bevorzugt als Inline-SVG; fotorealistische Materialien mit kostenlosen CDN-Bilddirektlinks und Größenbeschränkungen
• Responsive bis zum mobilen Gerät, sichtbarer Tastaturfokus, Beachtung von prefers-reduced-motion

Geschäftsverhalten gemäß Abschnitten 5–11 von business-rules.md implementieren, mit ergänzenden Anforderungen auf Codeebene:

• Verifizierungscode-Container mit data-verification-stage zur Kennzeichnung der Phase
• Bei fehlenden echten Zeitdaten mit klar gekennzeichneten Prototypdaten arbeiten, keine Bestandsvortäuschung
• Daten von ausgeblendeten Feldern, deaktivierten Funktionen und nicht ausgewählten Zweigen werden nicht in das Übermittlungsergebnis aufgenommen

Schritt 7: Selbstprüfung

Vor der Auslieferung die folgenden Checklisten durchgehen:

• Geschäftskorrektheit: Abnahmeliste in business-rules.md Punkt für Punkt überprüfen
• Designqualität: Plan durch Selbstkritik bestanden, Schrift und Farbe aus dem Plan abgeleitet, Signatur einzigartig, responsiv, Tastaturfokus, prefers-reduced-motion, CSS-Selektoren ohne Aufhebung
• Technische Stabilität: Checkliste in engineering-conventions.md Punkt für Punkt überprüfen (CJK-Einheiten, i18n-Rendering-Modus, Namenspräfix, Bereichsisolierung, initiales Laden)
• Code-Ausführbarkeit: Einzeldatei direkt im Browser ausführbar, keine externen Abhängigkeiten, Schriftart über CDN

Schritt 8: Auslieferung

Speichere die Datei im Arbeitsverzeichnis des Benutzers mit Dateinamen basierend auf project.name. Mit kurzer, natürlicher Sprache erklären: basierend auf welcher Konfiguration, welche Kernfunktionen implementiert wurden, Signature-Element, welche Daten Prototypen sind und ausgetauscht werden müssen.

Fehlermodi

Situation	Behandlung
user_config_info.json nicht bereitgestellt	Stoppe, Hinweis auf erforderliche Konfigurationsdatei
JSON-Parsing-Fehler	Zeige Fehlerposition an, keine Reparaturversuche
Konflikt zwischen Konfiguration und Geschäftsregeln	Nenne spezifische Felder und Regeln, bitte Benutzer um Bestätigung
Unbekannter kind in conversionFlow	Nenne spezifischen Knoten, nicht stillschweigend überspringen
Echte Daten erforderlich, aber nicht vorhanden	Verwende klar gekennzeichnete Prototypdaten, keine Vortäuschung der Echtheit
Konflikt zwischen Benutzerwunsch und Konfiguration	Gemäß Prioritätskette behandeln und dem Benutzer erklären