bishoe01/blueprint-extractor

Extrahieren

Erstelle eine fundierte DESIGN.md von einer öffentlichen Website. Extrahiere beobachtbare Designmuster; klone die Website nicht als ausführbaren Code und erhebe keinen Anspruch auf offizielle Markenrichtlinien.

Befehlsverhalten

Wenn der Benutzer /extract <url> eingibt, behandle es als Aufforderung, diesen Workflow sofort auszuführen.

Wenn der Benutzer nur /extract eingibt, frage nach der öffentlichen HTTPS-URL und starte die Extraktion erst, wenn sie angegeben wird.

Standardausgabe:

• Beweissammlung: .blueprint-extractor/<slug>/
• Abschlussdokument: DESIGN.md im aktuellen Projekt des Benutzers, sofern kein anderer Pfad gewünscht wird

Workflow

1. Validiere die Ziel-URL.
2. Erstelle einen Beweisordner unter .blueprint-extractor/<slug>/ im Projekt des Benutzers.
3. Sammle Beweise aus öffentlichen Seitendaten:
   • HTML-Titel und Metadaten
   • verknüpftes und eingebettetes CSS
   • berechnete Stile repräsentativer Elemente
   • Desktop-Screenshot bei 1440x900, wenn Browser-Tools verfügbar sind
   • mobiler Screenshot bei 390x844, wenn Browser-Tools verfügbar sind
4. Extrahiere nur konkrete Tokens aus abgerufenen CSS, berechneten Stilen oder aufgezeichneten Screenshots.
5. Schreibe blueprint.json und sources.json, bevor du den endgültigen Text verfasst.
6. Synthetisiere DESIGN.md unter Verwendung des exakten 9-Abschnitts-Vertrags in references/DESIGN_TEMPLATE.md.
7. Führe vor der Fertigstellung einen Selbstüberprüfungsdurchlauf durch:
   • verbessere den Implementierungsnutzen mit beobachteten Komponentenrezepten;
   • verbessere die qualitative Themensprache, wenn sie durch Screenshots gestützt wird;
   • trenne extrahierte Beweise von durch Screenshots abgeleitetem Verhalten und Implementierungsanleitungen;
   • entferne allgemeine Produktbehauptungen, die im extrahierten CSS nicht sichtbar oder vorhanden sind;
   • bewahre die Domäne, Informationsarchitektur und Kernworkflows des Zielprojekts; übertrage nur die visuelle Sprache;
   • abstrahiere Quell-Domänenkomponenten vor der Wiederverwendung, z. B. „Playlist“ zu „Sammlungsliste“ oder „Albumcover“ zu „visuelles Thumbnail“;
   • halte nicht unterstützte Beispiele aus DESIGN.md heraus, es sei denn, sie sind als qualitativ oder abgeleitet markiert.
8. Validiere das endgültige Markdown gegen die Vorlage und die Beweise.
9. Gib den Ausgabepfad und etwaige Vertrauenswarnungen in der endgültigen Antwort an.

URL-Sicherheit

Lehne die Anfrage mit einer kurzen Erklärung ab, wenn die URL unsicher oder nicht zulässig ist:

• nicht https://
• localhost, Loopback, private IP, Link-Local oder privater Hostname
• zugriffsgeschützte oder hinter einer Paywall befindliche Inhalte
• Nicht-HTML-Antwort
• nicht erreichbar, leer oder zu viele Weiterleitungen
• Aufforderung, sich anzumelden, private Dashboards zu scrapen, Figma zu extrahieren oder ausführbaren Code zu klonen

Folge keinen Formularen, Anmeldeabläufen, Checkout-Prozessen, destruktiven Aktionen oder benutzerspezifischen Seiten.

Extraktion

Wenn scripts/extract-blueprint.mjs existiert und die Abhängigkeiten verfügbar sind, führe es zuerst aus und verwende seine Artefakte als Quelle der Wahrheit. Wenn es nicht verfügbar ist, verwende verfügbare Browser-, HTTP- und Dateisystem-Tools, um manuell gleichwertige Beweise zu sammeln.

Bevorzuge deterministische Beweise gegenüber visuellem Raten:

• Farben müssen aus CSS, berechneten Stilen, SVG-Attributen oder Screenshot-Stichproben stammen.
• Schriftfamilien müssen aus CSS, berechneten Stilen oder @font-face stammen.
• Umbruchpunkte müssen aus Media Queries stammen oder explizit als aus Screenshots abgeleitet markiert sein.
• Abstände, Radien, Schatten, Rahmen und Bewegungen müssen CSS oder berechnete Stile zitieren.
• Wenn nur Screenshots verfügbar sind, halte Beobachtungen qualitativ und vermeide erfundene numerische Tokens.

Lies references/EXTRACTION_SCHEMA.md, bevor du blueprint.json und sources.json erstellst oder bearbeitest. Lies references/FAILURE_MODES.md, wenn die Extraktion teilweise oder blockiert ist. Lies references/QUALITY_CHECKLIST.md, bevor du eine generierte DESIGN.md als gutes Beispiel oder veröffentlichungsreife Ausgabe betrachtest.

Syntheseregeln

Verwende die angeforderte Sprache des Benutzers. Wenn keine Sprache angefordert wird, schreibe DESIGN.md auf Englisch.

Die endgültige DESIGN.md muss genau diese H2-Abschnitte in dieser Reihenfolge enthalten:

1. 1. Visuelles Thema & Atmosphäre
2. 2. Farbpalette & Rollen
3. 3. Typografieregeln
4. 4. Komponentenstile
5. 5. Layoutprinzipien
6. 6. Tiefe & Erhebung
7. 7. Do's and Don'ts
8. 8. Responsives Verhalten
9. 9. Agent-Prompt-Anleitung

Füge keinen Abschnitt „Quellen“, „Vertrauen“ oder „Anhang“ zu DESIGN.md hinzu. Platziere Vertrauenswarnungen in der endgültigen Assistentenantwort oder in der Beweissammlung.

Jeder konkrete Token in DESIGN.md muss auf blueprint.json zurückverfolgt werden können. Markiere unsichere Erkenntnisse als qualitative Beobachtungen anstatt als exakte Werte.

Mach aus dem endgültigen Dokument keine trockene Token-Deponie. Konvertiere Beweise in wiederverwendbare Designanleitungen:

• Nenne den Site-Archetyp nur, wenn er von der erfassten Seite sichtbar ist, z. B. „Dashboard-Shell“, „redaktionelle Landingpage“, „Handelskatalog“, „Mediaplayer“ oder „Dokumentationsseite“.
• Behandele bekannte Marken konservativ: Importiere keine bekannten Produktmuster, Markenüberlieferungen oder Behauptungen über offizielle Systeme, es sei denn, die erfasste Seite, das CSS oder die berechneten Stichproben unterstützen sie.
• Bewahre das Domänenmodell, die Informationsstruktur und die Benutzerworkflows der Ziel-App. Die Quellseite liefert visuelle Sprache, nicht die Erlaubnis, das Zielprojekt in die Produktkategorie der Quellseite zu konvertieren.
• Trenne übertragbare Designmerkmale von nicht übertragbaren Quell-Domänenobjekten. Übertrage Farbe, Typografie, Abstände, Dichte, Form, Oberflächenschichtung und Interaktionsgefühl; übertrage keine Domänenobjekte wie Tracks, Playlists, Warenkörbe, Dokumentationsseiten, Dashboards oder Checkout-Abläufe, es sei denn, der Benutzer fordert explizit diese Produktstruktur an.
• Wenn eine Quellkomponente nützlich ist, formuliere sie als domänenneutrales Muster: „Sammlungs-/Navigationssidebar“ statt „Playlist-Sidebar“, „wiederholtes Inhaltselement“ statt „Track-Zeile“, „visuelles Thumbnail oder Akzentblock“ statt „Albumcover“.
• Bewahre die Unterscheidung zwischen beobachteten Tokens, durch Screenshots abgeleitetem Layoutverhalten und Implementierungsanleitungen im Text.
• Verwandle beobachtete wiederkehrende Komponenten in kompakte Rezepte: Zweck, Oberfläche, Typografie, Abstand, Radius, Rahmen/Schatten, Interaktion.
• Bevorzuge Muster, die sich über die gesamte Seite verallgemeinern lassen, gegenüber einmaligen dekorativen Werten.
• Unterscheide extrahierte Umbruchpunkte von Implementierungskomfort-Umbruchpunkten.
• Verwende 7. Do's and Don'ts für prägnante Einschränkungen, die wahrscheinliche Fehlinterpretationen verhindern, einschließlich übermäßiger Verwendung von Akzentfarben, Hinzufügen nicht unterstützter Komponenten, Importieren des Domänenmodells der Quellseite oder Ändern der Produktkategorie des Zielprojekts.
• Gestalte 9. Agent-Prompt-Anleitung praktisch: Kurze Farbreferenz, Beispiel-Komponenten-Prompts und Iterationsanleitung, wenn die Beweise sie unterstützen.
• Halte die Anleitung inspiriert durch und implementierungsbereit, ohne einen Agenten anzuweisen, die Zielseite zu klonen.

Validierung

Bevor du abschließt:

• Bestätige, dass DESIGN.md am vorgesehenen Ausgabepfad existiert.
• Bestätige, dass die H2-Abschnittsnamen und deren Reihenfolge mit references/DESIGN_TEMPLATE.md übereinstimmen.
• Bestätige, dass jeder Hex-Farbwert, jede Schriftfamilie, jeder Umbruchpunkt, jeder Radius, jeder Schatten und jeder Abstandswert in blueprint.json vorkommt oder explizit als abgeleitet/qualitativ markiert ist.
• Bestätige, dass die Ausgabe references/QUALITY_CHECKLIST.md erfüllt, wenn ein Beispiel oder Release-Kandidat erstellt wird.
• Wenn die Validierung fehlschlägt, korrigiere die Beweise oder stufe nicht unterstützte Werte herab, bevor du das Ergebnis präsentierst.