Panel-Brainstorm → Interaktives Entscheidungsboard

Panel Brainstorm → Interaktives Entscheidungsboard

Wenn eine LOCAL.md-Datei neben dieser SKILL.md liegt, lies sie zuerst – sie enthält die spezifischen Details dieses Workspace (Pfade, Werkzeuge, Beispiele) und überschreibt die unten stehenden generischen Standardeinstellungen.

Führe ein Persona-Panel über Codex / Antigravity / Claude-Credit-Pools aus, um fundierte Produktideen zu generieren, diese mit einem adversarialen CPO-Durchgang zu stress-testen, eine deduplizierte Liste von ~30 Ideen mit einem drahtgerahmten Top 5 zu synthetisieren und ein interaktives Entscheidungsboard (Implementieren / Zurückhalten / Ablehnen pro Idee) zu veröffentlichen, dessen kopierte Zusammenfassung als Entscheidungsdokument ins Chat zurückkommt.

Referenzausgabe (ein echtes Panel, anonymisiert): assets/decision-board-reference.html.

Wann NICHT verwenden

• Eine einzelne, gut abgegrenzte Feature-Anfrage → baue/plane es einfach (oder superpowers:brainstorming inline).
• Code-Review oder Promotions-Entscheidungen für einen bestehenden Branch → dev-to-prod-promotion-review.
• Reine Forschungsfragen → deep-research.

Ablauf

1. Verankere dich zuerst (Haupt-Thread)

Lese den eigentlichen Code/das Feature, über das gebrainstormt wird. Schreibe eine 3–6-zeilige Zusammenfassung des aktuellen Zustands (was es heute tut, wichtige Dateien, bekannte Grenzen). Jeder Persona-Prompt enthält diese Zusammenfassung plus die konkreten Dateipfade, die gelesen werden sollen – das ist es, was die Ideen fundiert und nicht generisch hält.

2. Gestalte das Panel

5–7 Personas, jede mit einem Namen, einer Berufsbezeichnung und einer Linse, die unterschiedliche Ideen hervorbringt – nicht unterschiedliche Formulierungen derselben Linse. Die bewährte Mischung:

Persona-Archetyp	Linse	Gutes Backend
Staff Engineer ("Dex")	Günstig & wirkungsvoll basierend auf existierendem Code	codex
Growth PM ("Priya")	Aktivierung, Gewohnheitsschleifen, Messung	codex
UX-Designer ("Wren")	Verlorene Nutzer, Wegfindung, Barrierefreiheit	antigravity (≤1 leg)
Power-User-Betreiber ("Marisol")	Der tatsächliche Tag eines vielbeschäftigten Betreibers	claude
Nervöser Neuling ("Jomar")	Verwirrung am dritten Tag, Beruhigung, Sprache	claude
KI-Stratege ("Kade")	Agentische Grenze, abgebildet auf bestehende Maschinerie, Risiken	claude

Tausche Archetypen aus, um sie an das Thema anzupassen (z. B. eine Kundenpersona, einen Buchhalter). Behalte mindestens eine Benutzer-Persona (keine Entwickler) und eine skeptikerähnliche Linse.

Jeder Persona-Auftrag: "BRAINSTORM-AUFGABE (schreibe ein Markdown-Dokument, ändere KEINEN App-Code) … schlage genau 8 Ideen vor … für jede: kurzer Name, Einzeiler-Pitch, warum/Moment, den es bedient, wie es funktionieren würde (begründet in den Dateien, die du gelesen hast), Aufwand S/M/L. Schreibe in docs/<thema>-ideen/<persona>.md. Diese Datei ist deine EINZIGE Lieferung."

3. Führe es als parallelen Fan-Out aus

Verwende, was immer du an parallelem Ausführer hast: ein Multi-Backend-Fan-Out-Werkzeug, das jede Persona als unabhängigen Hintergrund-Job in einem eigenen Git-Worktree (Codex / Antigravity / Claude) ausführt, oder native Hintergrund-Subagenten (max. 3 gleichzeitig, Wellen, wenn mehr). Zusätzliche Punkte speziell für Panels:

• Ein adversarialer Überprüfungsdurchgang (ein letzter Job, der jedes Persona-Dokument liest) mit einem Produktpanel-Fokus, kein Code-Review: "Du bist ein skeptischer Chief Product Officer, der ein Produktpanel leitet … kritisiere die Ideen jedes Panelisten hinsichtlich Realismus und Wirkung, weise auf Überschneidungen hin, ende mit deinen Top-8-Ranking." Die CPO-Urteile werden später als Annotationen pro Idee verwendet.
• Führe es im Hintergrund aus; überwache die Fertigstellung.

4. Überprüfe die Lieferungen – Backends können lügen

Überprüfe nach dem Lauf, ob die Ausgabedatei jeder Persona tatsächlich existiert (ls die Worktrees). Antigravity kann status: done melden, aber nichts geschrieben haben. Führe jede fehlende Persona als nativen Hintergrund-Subagenten erneut aus (gleicher Prompt, "gib die Ideen als deine letzte Nachricht zurück, schreibe keine Dateien") – dauert ~1 Minute.

Außerdem: Die endgültige Rangliste der Überprüfung kann in den Berichtsdateien des Ausführers abgeschnitten sein. Die Kritiken pro Idee überleben normalerweise; führe die endgültige Rangliste selbst durch.

5. Synthetisiere

• Dedupliziere ~48 rohe → ~30 Ideen, gruppiert in 5–6 Themen; behalte die Persona-Zuordnung bei (Konvergenz = mehrere Personas, die dasselbe vorschlagen, ist das stärkste Rangsignal).
• Wähle ein Top 5 aus nach: Konvergenz → CPO-Urteil → Passung zu bestehendem Code.
• Notiere, was das Panel gestrichen hat und warum (eine Zeile) – der Benutzer möchte die Streichungen sehen.
• Persona-Dokumente leben in den Worktrees des Ausführers, die bereinigt werden; falls es sich lohnt, sie zu behalten, kopiere sie vor der Bereinigung heraus.

6. Erstelle das interaktive Entscheidungsboard (Artifact)

Passe assets/decision-board-reference.html an – behalte sein CSS-Kit und das gesamte <script> wörtlich, außer STORE_KEY (muss pro Board eindeutig sein, sonst überschreiben sich zwei Boards gegenseitig die Entscheidungen). Lade die artifact-design-Fähigkeit, bevor du schreibst.

Erforderliche Elemente (das dev-to-prod-promotion-review-Muster):

• Klebriger Live-Zähler – Implementieren / Zurückhalten / Ablehnen / Unentschieden Zählungen.
• Top-5-Karten mit einem CSS-only Drahtrahmen der Änderung (die Referenz hat ein wiederverwendbares Drahtrahmen-Kit: .wf, .frame, .side, .bub, .rankrow, .spot, .note) + Persona-Zuordnung + einem CPO-Check:-Callout.
• 3-Wege-Umschalter (✓ Implementieren / ◦ Zurückhalten / ✕ Ablehnen) auf jeder Top-5-Karte UND jeder Zeile der 30-Ideen-Tabelle. Entscheidungen leben auf Blatt-Ideen-Granularität: Eine Bündelkarte setzt data-key plus data-also="iX,iY", sodass die Entscheidung über die Karte auch ihre konstituierenden Ideen entscheidet, und die Tabellenzeilen bleiben individuell anpassbar. Ein erneuter Klick auf die aktive Auswahl hebt sie auf.
• localStorage-Persistenz, verschlüsselt mit dem eindeutigen STORE_KEY.
• Entscheidungszusammenfassung-Textarea + Kopier-Button – Artifacts haben keine sendPrompt-Brücke; der kopierte Text, der zurück ins Chat eingefügt wird, IST der Rückkanal. Füge einen Reset-Button hinzu.

Überprüfe vor der Veröffentlichung: Diene die Datei über einen lokalen python3 -m http.server (die file://-Vorschau im Browser-Pane ist unzuverlässig) und teste Klicks mit javascript_tool: Bündel-Klick setzt konstituierende Ideen, Zähler aktualisiert, localStorage persistiert, Reset löscht. Mojibake in der lokalen Vorschau ist nur der fehlende Charset-Header – das veröffentlichte Artifact setzt einen.

Veröffentliche mit dem Artifact-Tool; veröffentliche denselben Dateipfad erneut, um die URL zu behalten.

7. Berichte und sammle Entscheidungen

Abschließende Chat-Nachricht: Top 5 in einer Zeile pro Karte + Artifact-Link + Hinweis, dass Entscheidungen zurück ins Chat kopiert werden. Wenn der Benutzer die Zusammenfassung wieder einfügt, behandle sie als Entscheidungsdokument: gleiche sie ehrlich mit deiner eigenen Rangliste ab (eine überraschende Ablehnung ist ein Signal, kein Rauschen), plane/führe dann die IMPLEMENTIEREN-Liste aus und parke ZURÜCKHALTEN-Elemente, wo sie hingehören.

Häufige Fehler

Fehler	Behebung
Personas ohne Dateipfade zum Lesen	Generische Ideen – bette immer aktuelle Zustandszusammenfassung + Pfade ein
agy's done-Status vertrauen	Überprüfe, ob die Ausgabedatei existiert; führe Leg als nativen Subagenten erneut aus
Entscheidungen nur auf Bündel-Granularität	Blatt-Ideen entscheiden; Bündel verteilen sich über data-also
Wiederverwendung eines STORE_KEY	Zwei Boards überschreiben sich gegenseitig die localStorage-Entscheidungen
Worktrees vor dem Kopieren von Persona-Dokumenten bereinigen	Dokumente liegen auf Worktree-Branches – kopiere sie zuerst heraus, falls behaltenswert
CPO-Durchgang überspringen	Unsortierte Wunschliste; die Kritiken sind die Hälfte des Werts
Warten auf die Rangliste des CPO	Sie wird abgeschnitten; bewerte selbst aus Konvergenz + Urteilen