brainstorming

Überblick über den brainstorming skill

Wofür der brainstorming skill gedacht ist

Der brainstorming skill ist ein strukturierter Workflow vor der Implementierung, mit dem aus einer groben Idee erst ein freigegebenes Design wird, bevor überhaupt Code geschrieben wird. Seine Hauptaufgabe ist nicht, abstrakt „Ideen zu generieren“, sondern Nacharbeit zu vermeiden, indem Umfang, Annahmen, Anforderungen und Designentscheidungen früh sichtbar gemacht werden.

Für wen sich dieser brainstorming skill lohnt

Dieser brainstorming skill ist besonders hilfreich für Menschen, die häufig zu schnell von „wir sollten X bauen“ direkt in die Umsetzung springen. Besonders nützlich ist er für:

• Feature-Planung
• Komponenten-Design
• Verhaltensänderungen
• Vorschläge für interne Tools
• brainstorming for Requirements Planning

Wenn ihr bereits einen disziplinierten Spec-Prozess habt, kann dieser Skill trotzdem als leichtgewichtiger Einstieg in diesen Prozess dienen.

Was ihn von einem normalen Prompt unterscheidet

Der entscheidende Unterschied ist die harte Schranke in SKILL.md: Der Agent soll nichts implementieren, nichts scaffolden und keinen Code schreiben, bevor er ein Design vorgestellt und dafür eine Freigabe erhalten hat. Das klingt simpel, verändert das Verhalten aber deutlich im Vergleich zu gewöhnlichen „hilf mir, das zu bauen“-Prompts, bei denen Assistenten oft direkt zu Lösungen springen.

Was Nutzer vor der Installation wirklich wissen wollen

Die meisten Nutzer wollen vor allem drei Dinge schnell klären:

1. Bremst mich das aus?
2. Stellt der Skill nützliche statt generische Fragen?
3. Hilft er auch bei Diskussionen über visuelles Design?

Die Antwort lautet: Ja, der Skill fügt bewusst etwas Prozessaufwand hinzu, aber bei kleinen Ideen bleibt dieser Aufwand gering. Der Skill argumentiert ausdrücklich, dass selbst „einfache“ Arbeit einen kurzen Design-Durchlauf braucht, weil genau dort versteckte Annahmen teure Fehler verursachen.

So nutzt ihr den brainstorming skill

brainstorming-Installation und Einrichtung

Um den Skill aus dem Repository hinzuzufügen, verwendet:
npx skills add https://github.com/obra/superpowers --skill brainstorming

Nach der Installation solltet ihr zuerst diese Dateien öffnen:

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

Wenn ihr mit visueller Exploration rechnet, schaut zusätzlich in:

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

Der Kern-Workflow, den der brainstorming skill erwartet

Das Nutzungsmuster des brainstorming skill ist bewusst meinungsstark:

1. Projektkontext erkunden
2. optional den visuellen Begleiter anbieten
3. Rückfragen einzeln stellen
4. das Design verdichten
5. explizite Freigabe einholen
6. erst dann in Planung oder Implementierung übergehen

Wenn euer Agent von der Idee direkt zum Code springt, folgt er diesem Skill faktisch nicht.

Welche Eingaben ihr für bessere brainstorming-Ergebnisse liefern solltet

Der Skill funktioniert am besten, wenn ihr mehr als nur einen Feature-Titel angebt. Gute Starteingaben enthalten meist:

• das zu lösende Problem
• wer der Nutzer ist
• den aktuellen System- oder Repo-Kontext
• Einschränkungen
• wie „fertig“ aussieht
• bekannte Non-Goals

Eine schwache Eingabe:

Add notifications.

Eine stärkere Eingabe:

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

Die zweite Version gibt dem brainstorming skill genug Struktur, um präzisere Anschlussfragen zu stellen.

Wie ihr aus einer groben Idee einen starken ersten brainstorming-Prompt macht

Eine praxistaugliche Prompt-Vorlage für brainstorming:

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

Das entspricht dem vorgesehenen Ablauf des Skills und senkt die Wahrscheinlichkeit generischer Rückfragen.

Wie Rückfragen im brainstorming skill funktionieren sollten

Ein feines, aber wichtiges Detail: Der Skill erwartet Fragen eine nach der anderen, nicht als riesigen Discovery-Fragebogen. Das ist wichtig, weil Antworten oft die nächste Frage verändern. Wenn euer Agent 15 Fragen auf einmal ausspielt, verliert ihr die interaktive Verfeinerung, für die dieser brainstorming-Leitfaden gedacht ist.

Wann ihr den visuellen Begleiter verwenden solltet

Das Repository enthält einen browserbasierten visuellen Begleiter. Nutzt ihn, wenn Nutzer Optionen besser verstehen, wenn sie sie sehen:

• Wireframes
• Layout-Vergleiche
• UI-Flows
• Architekturdiagramme
• Visualisierungen von Zuständen oder Beziehungen

Nutzt ihn nicht allein deshalb, weil das Thema UI erwähnt. Eine konzeptionelle Frage wie „soll das ein Wizard oder ein Modal sein?“ lässt sich gut in Text klären. Eine Frage wie „welches dieser beiden Wizard-Layouts ist klarer?“ passt dagegen sehr gut zum visuellen Pfad.

Wie der visuelle Begleiter tatsächlich bereitgestellt wird

Die visuelle Hilfe ist nicht nur Dokumentation; es gibt auch Skripte für eine lokale Sitzung:

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh startet einen lokalen Server auf einem zufälligen hohen Port und kann Sitzungsdateien entweder unter /tmp oder in einem Projektverzeichnis wie .superpowers/brainstorm/ ablegen. Das ist nützlich, wenn Mockups sitzungsübergreifend erhalten bleiben sollen.

Praktische Umgebungs-Hinweise, bevor ihr euch auf Visuals verlasst

Der visuelle Workflow setzt eine Umgebung mit Browserzugriff voraus. Wenn ihr in einem Remote-Container, einer VM oder per SSH arbeitet, achtet besonders auf:

• --host
• --url-host
• die Persistenz des Sitzungsverzeichnisses

Für rein lokale Nutzung sind die Standardwerte unkompliziert. In geteilten oder entfernten Umgebungen solltet ihr die Netzwerkdetails vorab klären, bevor ihr euren Workflow auf Browser-Feedback aufbaut.

Der beste Datei-Lesepfad für einen schnellen Einstieg

Wenn ihr mit möglichst wenig Aufwand zu echter Nutzungsqualität kommen wollt, lest in dieser Reihenfolge:

1. SKILL.md für den Verhaltensvertrag
2. visual-companion.md dafür, wann Browser-Support hilft
3. spec-document-reviewer-prompt.md dafür, wie „gut genug zur Implementierung“ aussieht
4. scripts/start-server.sh, wenn ihr den visuellen Pfad braucht

So bekommt ihr zuerst die Entscheidungslogik und danach optional das Tooling.

Woran gute Ausgabe des brainstorming skill zu erkennen ist

Eine erfolgreiche brainstorming-Session sollte mit einem Design enden, das konkret genug zur Prüfung ist, einschließlich:

• Ziel und Nutzer
• Umfangsgrenzen
• zentrale Entscheidungen
• offene Risiken oder Annahmen
• genug Spezifität, um die Implementierung zu planen

Wenn das Ergebnis nur aus einer losen Ideensammlung besteht, wurde die Session zu früh beendet.

So nutzt ihr brainstorming for Requirements Planning

Für brainstorming for Requirements Planning verwendet ihr den Skill als Vorstufe zur Spec:

1. Problem und Randbedingungen klären
2. Design oder Form der Anforderungen entwerfen
3. Freigabe einholen
4. die Spec schreiben
5. bei Bedarf die Prompt-Vorlage für den Spec-Review ausführen

Das ist einer der stärksten Einsatzzwecke des Skills, weil Scope Drift und Unklarheiten abgefangen werden, bevor die Planung festgeschrieben wird.

brainstorming skill FAQ

Ist der brainstorming skill nur für große Projekte?

Nein. Der Skill weist die Idee ausdrücklich zurück, dass „kleine“ Aufgaben den Designschritt überspringen können. Bei einer winzigen Änderung kann das erwartete Design kurz sein, aber der Designschritt bleibt wichtig. Besonders hoch ist der Nutzen oft bei vermeintlich simplen Änderungen, bei denen Annahmen ungeprüft bleiben.

Ist das besser als gewöhnliche brainstorming-Prompts?

Meistens ja, wenn euer eigentliches Ziel nicht Ideenmenge, sondern umsetzungsreife Klarheit ist. Ein normaler brainstorming-Prompt kann viele Optionen erzeugen. Dieser brainstorming skill ist besser, wenn ihr konvergentes Denken braucht: Kontext verstehen, Optionen eingrenzen und ein freigegebenes Design erzeugen.

Ist der brainstorming skill anfängerfreundlich?

Ja, besonders für Solo-Builder, die noch keine feste Planungspraxis haben. Die Struktur gleicht einen typischen Anfängerfehler aus: die erste plausible Idee umzusetzen, ohne vorher Anforderungen oder Trade-offs zu klären.

Wann passt brainstorming eher nicht?

Überspringt oder verkürzt es, wenn:

• die Aufgabe rein mechanisch ist und bereits vollständig spezifiziert wurde
• keine Design- oder Verhaltensentscheidung ansteht
• der Nutzer bereits eine detaillierte Spec freigegeben hat und nur noch Umsetzung braucht

Prüft aber selbst dann, ob die harte Schranke mit eurem Workflow kollidiert. Dieser Skill ist absichtlich strikt.

Erzeugt dieser Skill Code?

Nein, und genau das ist beabsichtigt. Der brainstorming skill soll vor der Implementierung stoppen, bis eine Freigabe vorliegt. Wenn ihr Codegenerierung wollt, nutzt zuerst diesen Skill und gebt dann nach der Freigabe an einen Planungs- oder Implementierungs-Skill weiter.

Brauche ich den visuellen Begleiter, damit sich der Skill lohnt?

Nein. Der Browser-Pfad ist optional. Reine Textnutzung des brainstorming skill liefert schon den Großteil des Nutzens für Anforderungen, Scope und technische Trade-off-Diskussionen. Die visuellen Werkzeuge sind vor allem dann wichtig, wenn die Entscheidung selbst visuell ist.

So verbessert ihr den brainstorming skill

Gebt dem brainstorming skill mehr Projektkontext

Der schnellste Weg zu besseren Ergebnissen ist, die Diskussion in der Realität zu verankern:

• relevante Dateien oder Ordner
• bestehendes Verhalten
• jüngste Änderungen
• bekannte technische Einschränkungen
• betroffene Nutzer

Der Skill weist den Agenten selbst an, zuerst den Projektkontext zu erkunden. Helft ihm dabei, indem ihr benennt, wo dieser Kontext liegt.

Nennt Einschränkungen und Non-Goals früh

Viele schwache brainstorming-Ergebnisse entstehen durch zu unscharfe Grenzen. Sagt dem Skill, was erhalten bleiben oder vermieden werden muss:

• Abwärtskompatibilität
• Performance-Grenzen
• Compliance- oder Sicherheitsanforderungen
• Zeitplan- oder Personalgrenzen
• Features, die explizit außerhalb des Scopes liegen

So entstehen engere, entscheidungstauglichere Designs.

Fordert ein Design an, nicht nur Ideen

Wenn ihr ein Ergebnis wollt, das direkt in die Umsetzung überführt werden kann, sagt das klar. Bittet den brainstorming skill, mit Folgendem zu enden:

• einem vorgeschlagenen Design
• Annahmen
• ungeklärten Fragen
• einem expliziten Freigabe-Checkpoint

Das lenkt die Session weg von endloser Ideensammlung und hin zu einem nutzbaren Artefakt.

Nutzt stärkere Prompts für visuelles brainstorming

Bei visueller Arbeit reicht „show mockups“ nicht. Beschreibt konkret, was der Visual vergleichbar machen soll:

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

Solche Prompts helfen dem visuellen Begleiter, ausgabeorientierte Entwürfe für Entscheidungen zu erzeugen statt bloß dekorative Screens.

Achtet auf den wichtigsten Ausfallmodus: vorschnelles Lösungssuchen

Der häufigste Fehler ist, zu früh in Implementierungsdetails zu springen, bevor das Problem wirklich verstanden ist. Wenn das passiert, lenkt die Session zurück:

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

So bleibt der brainstorming-Leitfaden auf seinen eigentlichen Zweck ausgerichtet.

Verbessert die erste Ausgabe durch eine gezielte Review-Runde

Nach dem ersten Design solltet ihr eher eine fokussierte Überarbeitung anfordern, statt neu zu starten:

• Was ist mehrdeutig?
• Was ist über-engineered?
• Was würde die Implementierungsplanung blockieren?
• Was fehlt für die Freigabe?

Das spec-document-reviewer-prompt.md aus dem Repository ist hier besonders hilfreich, weil es den Review an echten Planungsblockern ausrichtet und nicht an kosmetischen Änderungen.

Haltet das brainstorming-Artefakt klein, aber entscheidungsreif

Ein häufiger Fehler ist, das Design mit unnötigen Details aufzublähen. Besseres brainstorming ist nicht längeres brainstorming. Für einfache Arbeit können wenige präzise Absätze zu Zweck, Umfang, Einschränkungen, Vorgehen und Freigabe völlig ausreichen. Der Maßstab ist nicht die Dokumentlänge, sondern ob der nächste Schritt mit weniger Rätselraten weitergehen kann.

Kombiniert brainstorming mit einem Spec-Review-Schritt

Wenn ihr diesen Skill ernsthaft einsetzt, kombiniert ihn mit einer nachgelagerten Prüfung der erzeugten Spec oder des Designs. Die enthaltene Reviewer-Vorlage prüft auf:

• Platzhalter
• Widersprüche
• mehrdeutige Anforderungen
• zu breiten Scope
• nicht angeforderte Komplexität

So wird der brainstorming skill in einem echten Delivery-Workflow wertvoller und bleibt nicht nur ein Chat-Helfer.