slice-mockup-html

Mockup in HTML umwandeln (Slice)

Ein Mockup originalgetreu in HTML kopieren; es nicht neu gestalten. Ein korrektes Ergebnis, über das Mockup gelegt, zeigt nahezu keinen Unterschied. Kreativität, „Verbesserungen“ und zusätzliche Funktionen gelten als Fehler.

Arbeitsablauf (in der Reihenfolge, nicht vorausspringen)

1. Mockup empfangen

Bestätigen, dass das Mockup tatsächlich existiert (prüfen Sie /mnt/user-data/uploads und die Konversation); falls nicht, danach fragen, nie raten. Wenn es viele Seiten/Frames hat, fragen, welche erstellt werden sollen.

Unterstützte Eingaben: PNG, SVG, Figma via MCP (JPG wird wie PNG behandelt). Bei jedem anderen Format den Benutzer bitten, PNG oder SVG zu exportieren. Wie jede Eingabe gelesen wird, steht in references/mockup-audit.md. Für Figma zuerst die Fähigkeit figma:figma-design-to-code laden, bevor get_design_context aufgerufen wird.

2. Die zwei Fragen stellen

Beide Fragen zusammen stellen, vor der Auditierung und vor dem Codieren. Eine Frage überspringen, wenn der Benutzer sie bereits beantwortet hat. Verwenden Sie ask_user_input_v0, falls verfügbar (ein Aufruf, zwei Fragen); andernfalls als kurzen Nur-Text fragen.

1. Ausgabeformat: Einzeldatei (HTML, CSS, JS inline in einer index.html, plus assets/) oder Separate Dateien (index.html, css/style.css, js/main.js, plus assets/)
2. CSS: Vanilla CSS, Bootstrap via CDN oder Tailwind via CDN

Nach den Antworten references/output-structure.md lesen sowie die passende Datei: references/vanilla.md, references/bootstrap.md oder references/tailwind.md. Die anderen beiden nicht lesen.

3. Vor dem Codieren auditieren

references/mockup-audit.md lesen und den Audit-Spezifikation erstellen (Canvas, Container, Raster, Farben, Schriftarten, Abstände, Radien, Schatten, Assets, sichtbare Interaktionen), jeder Wert als gemessen oder geschätzt markiert. Dem Benutzer nur eine Zusammenfassung zeigen, wenn eine Entscheidung nötig ist (nicht identifizierbare Schriftart, fehlendes Asset); andernfalls fortfahren.

4. Code schreiben

• Regeln: references/responsive-and-fidelity.md (pixelgenau und responsiv), references/code-standards.md (semantisches HTML, BEM), references/anti-slop.md (Verbote). Diese während des Schreibens anwenden, nicht danach.
• Werte bei der Mockup-Breite müssen exakt den Audit-Werten entsprechen (px, nicht auf einen Framework-Raster gerundet).
• JS nur für interaktive Komponenten, die im Mockup sichtbar sind, gemäß dem Inhaltstest in anti-slop.md (das Verhalten nur dann umsetzen, wenn das Mockup den benötigten Inhalt hat; andernfalls statisch lassen und melden); keine zusätzlichen Bibliotheken über das hinaus, was das gewählte Framework erfordert.

5. Verifizieren

Die Verifizierungsschritte in references/responsive-and-fidelity.md befolgen, dann die abschließende Prüfung in references/anti-slop.md durchführen. Wenn die Sandbox nicht rendern kann, dies klar sagen.

6. Ausliefern

In /mnt/user-data/outputs/ speichern und mit present_files teilen. Bei mehr als einer Datei ein einzelnes .zip-Archiv erstellen mit der Ordnerstruktur (damit Asset-Pfade gültig bleiben) und zusätzlich index.html präsentieren.

Anschließend einen Bericht von maximal etwa 6 Zeilen geben, nur das, was der Benutzer wissen muss: nicht identifizierte Schriftarten und ihre Ersatzwerte, geschätzte Werte, Platzhalter-Assets, Icons, die nicht nachgebildet werden konnten oder das Größenbudget überschreiten, umgesetztes interaktives Verhalten oder statisch gelassen wegen fehlenden Inhalts, sowie Tablet-/Mobilteile, die abgeleitet wurden, weil das Mockup sie nicht zeigt. Keine Funktionsvorschläge, Verbesserungsideen oder Eigenlob.

Kernprinzipien

• Genauigkeit über alles. Wenn das Mockup schwach aussieht, exakt so kopieren.
• Nichts hinzufügen, was im Mockup nicht vorhanden ist; nicht stillschweigend raten: jede Annahme mit visueller Auswirkung kommt in den Bericht.
• Text exakt kopieren, einschließlich Groß-/Kleinschreibung, Zeichensetzung und Zahlen; unleserlichen Text kennzeichnen.