ne11nn/comparison-lab

Was dieser Skill tut

Verwandelt "Vergleiche einige Optionen für X" in ein echtes Instrument. Du erzeugst mehrere echt unterschiedliche, recherchierte Varianten von X, stellst jede in einem eigenen Bereich auf einer gemeinsam nutzbaren Vergleichstafel dar und übergibst sie einem Menschen zum Vergleichen, Gewinner-Auswählen und Feedback-Geben. Deren Auswahl kommt zu dir zurück und du vertiefst die Gewinner.

Es funktioniert für alles: alternative Lösungsansätze, UI-/Komponentendesigns, Test-/Evaluierungsstrategien und generierte Medien (Code, Bilder, Audio, Text). Die Tafel ist eine abhängigkeitsfreie, eigenständige HTML-Datei, die in jedes Projekt eingefügt werden kann.

$ARGUMENTS ist das, was verglichen werden soll. Falls es vage ist (vergleiche was, variiere entlang welcher Dimension, für welche Subjekte), stelle 1-2 klärende Fragen, bevor du generierst.

Kernprinzipien (das Rückgrat – nicht überspringen)

1. Echte, unterschiedliche Varianten – keine Knopf-Drehereien. Jede Variante ist eine echte, benannte Technik. Wenn sich zwei Varianten nur durch einen Parameterwert unterscheiden, sind sie ein Ansatz, zweimal abgetastet – fasse sie zusammen. Test: Wenn du zwei Varianten mit demselben Satz beschreiben kannst und nur eine Zahl austauschst, sind sie nicht unterschiedlich.
2. Recherche IST der Kalibrierungsschritt. Wenn das Fachgebiet eine Literatur oder etablierte Praktiken hat, recherchiere die tatsächlichen benannten Techniken, BEVOR du die Varianten entwirfst – verwende WebSearch / docs / references/. Das Erraten des Menüs aus der Phantasie führt zu Über- oder Unterschießen. (Siehe reference.md §1 für fachspezifische Rechercheaufforderungen.)
3. Kontrollierter Vergleich. Friere jede Eingabe ein; variiere NUR die eine zu testende Dimension. Gleicher Seed/Szenario/Aufforderung/Kopie über jede Karte in einer Zeile hinweg. Gib die eingefrorenen Eingaben im Ziel der Zeile an. Eine Zeile = eine variierte Dimension.
4. Objektive Badges. Wo immer etwas messbar ist, befestige einen farbcodierten Metrik-Badge pro Karte (Abstand zum Ziel, Bestehensrate, Latenz, Bündelgröße, Kontrastverhältnis, …), sodass die Auswahl evidenzbasiert ist und nicht auf Bauchgefühl beruht.
5. Störfaktoren isolieren – mehrere Ansichten eines Artefakts. Wenn mehr als eine Ansicht desselben Ergebnisses sehenswert ist, gib der Karte einen content.views-Umschalter (z. B. Notation / Klavierrolle / Audio / Roh / Diff). Der klassische Fall ist ROH vs. VERARBEITET – stelle das rohe Artefakt neben das verarbeitete, damit der Mensch erkennen kann, welche Stufe einer Übersetzungs-/Neufärbungs-/Normalisierungs-/Serialisierungs-/Komprimierungspipeline ein schlechtes Ergebnis verursacht hat; content.raw ist die 2-Ansichten-Abkürzung dafür. Täusche niemals einen Umschalter vor. Füge nur dann eine Ansicht hinzu, wenn sie sich wirklich unterscheidet – wenn verarbeitet und roh identisch herauskommen (eine originalgetreue Transformation), entferne den Umschalter. Ein nutzloser Umschalter ist schlimmer als keiner; die Tafel reduziert byte-identische Ansichten automatisch und blendet den Umschalter bei ≤1 Ansicht automatisch aus.
6. Ehrlichkeit von Metrik vs. Artefakt. Stelle das echte Artefakt neben seine Metrik-Badges und lass Widersprüche sichtbar sein. Wenn die Notation deutlich eine erniedrigte Terz hat, aber der „Abstands“-Badge 0 anzeigt, ist dieser Widerspruch die Erkenntnis – es bedeutet, dass die Metrik etwas ignoriert. Dies sichtbar zu machen ist der Punkt; verstecke das Artefakt nicht hinter der Zahl und stimme die Zahl nicht ab, um sie anzupassen.
7. Echter-Inhalt-Schranke. Jedes Panel zeigt echte AUSGABE – niemals einen Platzhalter, eine Hülse oder einen Byte-Größen-Check. Überprüfe, ob der tatsächliche Inhalt gerendert wird. Bei Audio muss der Inhalt tatsächlich KLINGEN – überprüft mit blockierter Beispielquelle (reference.md §9 Offline-Tor) –, nicht nur rendern.
8. Eine gemeinsam nutzbare Oberfläche. Gib eine einzelne Tafel aus, die der Mensch öffnet (eine Datei oder ein Link), keine verstreuten Artefakte.
9. Checkpoint-Disziplin. Baue zuerst den riskantesten / repräsentativsten Ausschnitt (ein Subjekt, eine Zeile, mit echtem Inhalt + Audio/Wiedergabe, falls relevant). Zeige ihn dem Menschen und hole Feedback, BEVOR du auf jede Dimension skalierst.
10. Schließe den Kreislauf. Der Mensch wählt Gewinner aus und hinterlässt Feedback AUF der Tafel; dieser Export kommt zu dir zurück, um zu verfeinern. Dann vertiefe die Gewinner.
11. Gewinner pro Subjekt + Fusion. Wenn sich die beste Variante je nach Testsubjekt unterscheidet, zeige die Gewinner pro Subjekt an und füge eine Fusions-/Syntheserunde hinzu, die die gewinnenden Merkmale kombiniert, anstatt einen globalen Gewinner zu erzwingen. Der Sinn mehrerer Subjekte ist es aufzuzeigen, dass ein einzelner Ansatz selten überall gewinnt – ehre das, anstatt es wegzumitteln.

Arbeitsablauf

1. Kläre den Vergleich. Aus $ARGUMENTS lege fest: was wird verglichen, die einzelne Dimension, die pro Zeile variiert, und die kontrollierten Subjekte/Seeds (2 ist ein guter Standard). Frage nur, wenn es wirklich mehrdeutig ist.

2. Recherchiere die echten Varianten. Wenn das Fachgebiet etablierte Techniken hat, schlage sie zuerst nach (reference.md §1 hat Rechercheaufforderungen). Erstelle eine kurze Liste von 2-6 benannten, wirklich unterschiedlichen Ansätzen pro Zeile. Lehne zwei ab, die sich nur durch einen Parameter unterscheiden.

3. Generiere echte Inhalte für jede Variante. Für jedes (Subjekt, Zeile, Variante) erzeuge das tatsächliche Artefakt und wähle seine Inhaltsart: html (UI/Text), code, image, iframe, audio (inkl. WebAudio-Synth) oder passfail (Tests/Evaluierungen). Siehe reference.md §2 für die Modalitätstabelle. Um mehrere Ansichten einer Ausgabe anzubieten, setze content.views auf eine Liste benannter Ansichten (die erste ist die Standardeinstellung; identische Ansichten werden reduziert, der Umschalter blendet sich bei ≤1 aus) – oder verwende die content.raw-2-Ansichten-Abkürzung, wo eine Pipeline die Wahrheit verbergen könnte (Prinzip 5). Füge objektive badges hinzu, wo immer etwas messbar ist, und zeige sie neben dem echten Artefakt, damit Widersprüche sichtbar werden (Prinzipien 4, 6).

Rendering echter Domänenartefakte (Notation, Diagramme, Zeichnungen): der zuverlässige Weg ist, in einem kopflosen Browser in ein <svg> zu rendern, svg.outerHTML zu nehmen und es über die html-Inhaltsart einzubetten (Inline-SVG – NIEMALS als <img>-data-URI, die den SVG-Namensraum fallen lässt und defekt rendert). Zeichensatz-Renderer (z. B. VexFlow/Bravura) benötigen die Schriftart als base64-@font-face, die sowohl auf der Renderseite als auch auf der Tafel inline eingebunden ist, wobei document.fonts.ready abgewartet werden muss, bevor gerendert und ein Screenshot gemacht wird. template/render-artifacts.example.mjs ist eine Kopier-und-Anpassungs-Hilfe genau dafür; reference.md §6 enthält das vollständige Rezept und die Fallstricke.

4. Baue die Tafel aus der Vorlage. Kopiere template/comparison-lab.html in das Projekt (irgendwo serverbar, oder irgendwo für die file://-Nutzung). Schreibe deinen Datensatz in eine data.json daneben unter Verwendung des Schemas in template/README.md. Baue KEINE neue Benutzeroberfläche von Hand – die Vorlage liefert bereits die Haftnotiz-Tafel, Badges, Umschalter, Schaltflächen und Export.

• Über http(s) bereitgestellt: data.json wird automatisch abgerufen.
• Doppelklick (file://): füge den Datensatz in den <script id="inline-data">-Block im HTML ein (das Abrufen einer benachbarten Datei ist unter file:// blockiert).

5. Überprüfe, ob es echte Inhalte rendert. Öffne die Tafel und bestätige, dass jedes Panel tatsächliche Ausgabe zeigt (nicht den Platzhalter), Badges farbig sind, alle views/roh-Umschalter dort funktionieren, wo sie vorhanden sind (und dort fehlen, wo es keine echte zweite Ansicht gibt), und Auswählen/Feedback/Export funktionieren. Wenn du Zugriff auf einen kopflosen Browser hast, erstelle einen Screenshot – auch in Telefonbreite (die Tafel ist Mobile-First). Behebe alles, das wie ein Entwurf wirkt.

6. Checkpoint – teile den riskantesten Ausschnitt. Übergib dem Menschen die Tafel (Link oder Datei) mit dem ersten vollständig gebauten Subjekt/Zeile. Hole Feedback, bevor du auf den Rest skalierst. Dies ist Prinzip 9 – baue nicht still alles.

7. Sammle Auswahlen und vertiefe Gewinner. Der Mensch wählt Gewinner aus und hinterlässt Notizen, klickt dann auf Export picks + feedback (Markdown oder JSON). Nimm das zurück und vertiefe die gewählten Varianten – verfeinere, härte oder produktionisiere, was sie ausgewählt haben.

Die Tafel-Benutzeroberfläche (was die Vorlage mitbringt)

Ein sauberes weißes Board aus Haftnotiz-Karten – kontrastreicher schwarzer Text, dezenter Schatten, pastellfarbener Kopfstreifen pro Karte, gerade und ausgerichtet. Kalibriert an echten Haftnotiz-/Kanban-Boards.

• Kopfzeile: Titel, eingefrorene Einleitung, ein Subjekt/Seed-Umschalter (Schaltflächen, die die kontrollierte Eingabe umschalten), eine Badge-Legende, Zurücksetzen und Export picks + feedback.
• Jede Karte (Haftnotiz): Variantenbezeichnung, einzeilige Technik-Beschreibung, ein generischer Inhaltsbereich (rendert Inline-HTML/SVG, <img>, sandboxed <iframe>, <audio>/Synth, <pre><code> oder eine Bestanden/Nicht bestanden-Checkliste – angetrieben durch die Daten), farbcodierte Metrik-Badges und ein optionaler benannter Ansichts-Umschalter (eine Pillen-Reihe), wenn die Daten content.views oder content.raw bereitstellen.
• Schaltflächen pro Karte: ★ Auswählen (schaltet eine Gewinner-Markierung um), ✎ Feedback (Inline-Notiz), plus Inhaltsaktionen, die der aktiven Ansicht folgen (▶ Abspielen, ⤢ Öffnen, ⧉ Kopieren).
• Export gibt die Auswahlen + Notizen des Menschen als kopierbares Markdown oder JSON aus. Auswahlen + Notizen bleiben in localStorage erhalten.
• Null Abhängigkeiten, null Netzwerk – funktioniert durch Öffnen der Datei. Mobile-First: Karten reduzieren sich auf einem Telefon auf eine Spalte, Antippziele sind ≥40px, der Subjekt-Umschalter bleibt in der klebrigen Kopfzeile erreichbar, der Fließtext bleibt lesbar. Maus- und berührungsfreundlich, respektiert prefers-reduced-motion.

Dateien

Datei	Zweck
template/comparison-lab.html	Die Tafel. In sich geschlossen (Inline-CSS + Vanilla JS), Mobile-First. Kopieren wie es ist; nicht neu bauen.
template/data.sample.json	Arbeitsdatensatz, der die Allgemeingültigkeit beweist (html, code, passfail, image+raw, ein N-View content.views-Umschalter, Audio über 2 Subjekte). Kopieren → data.json, bearbeiten.
template/render-artifacts.example.mjs	Kopier-und-Anpassungs-Hilfe zum Rendern echter Domänenartefakte (Notation/Diagramme/Zeichnungen) in die Tafel – bündele deinen Renderer, binde eine Glyphen-Schriftart ein, extrahiere Inline-SVG kopflos, injiziere + erstelle Screenshot. Bearbeite die ADAPT THIS-Blöcke.
template/README.md	Wie man data.json befüllt; das vollständige Schema, Feld für Feld (inkl. content.views); das Exportformat.
reference.md	Tiefergehende Variantengestaltung + fachspezifische Rechercheaufforderungen (§1), die Modalitäts-Rendering-Tabelle (§2), Badges (§3), Schema-Hinweis (§4), das durchgearbeitete Musikbeispiel inkl. der Roh-vs-Verarbeitet-Geschichte (§5), Rendering echter Artefakte + die kopflose Hilfe (§6), das content.views-Schema + die Lektion Metrik-vs-Artefakt (§7) und eine Mobile-First-Checkliste (§8).

Hinweise

• Dies ist ein Ansatz-Skill (wie Brainstorming) – sowohl per Schrägstrich aufrufbar als auch modellaufrufbar. Setze disable-model-invocation nicht.
• Kopiere die HTML-Vorlage wörtlich – die gesamte UI-Arbeit ist erledigt. Deine Aufgabe sind die Daten: echte Varianten + echte Inhalte + Badges.
• Versende KEINE Tafel mit nahezu identischen Varianten. Wenn du nicht jede Variante als eine eigene Technik benennen kannst, hast du Schritt 2 nicht ausgeführt.
• Täusche KEINEN Inhalt vor. Ein Platzhalter-Panel macht den Zweck zunichte (Prinzip 7).
• Versende KEINEN nutzlosen Umschalter. Füge eine views/raw-Ansicht nur hinzu, wenn sie sich wirklich unterscheidet – identische Ansichten werden automatisch reduziert, aber entwirf für einen echten Unterschied (Prinzip 5).
• Für größere interaktive Vorschauen bevorzuge iframe mit srcdoc gegenüber einem riesigen html-String. Für gerendertes SVG bette es über die html-Art ein, nicht als <img>-data-URI (reference.md §6).
• Halte generierte Medien inline (data:-URIs, WebAudio-Synth), damit die Tafel eine einzige gemeinsam nutzbare, offlinefähige Datei bleibt.