GoCodeAlone/claude-superpowers

Ideen in Designs verwandeln – Brainstorming

Übersicht

Hilft dabei, Ideen durch natürliche, kollaborative Dialoge in vollständige Designs und Spezifikationen umzuwandeln.

Beginne damit, den aktuellen Projektkontext zu verstehen, stelle dann Fragen mittels adaptiver Bündelung, um die Idee zu verfeinern. Sobald du verstehst, was du baust, präsentiere das Design und hole die Benutzerfreigabe ein.

Anti-Pattern: „Das ist zu einfach, um ein Design zu brauchen“

Jedes Projekt durchläuft diesen Prozess. Eine Todo-Liste, ein Ein-Funktions-Dienstprogramm, eine Konfigurationsänderung – alle. „Einfache“ Projekte sind genau die, bei denen ungeprüfte Annahmen die meiste verschwendete Arbeit verursachen. Das Design kann kurz sein (ein paar Sätze für wirklich einfache Projekte), aber du MUSST es präsentieren und die Freigabe einholen.

Checkliste

Du MUSST für jeden dieser Punkte eine Aufgabe erstellen und sie der Reihe nach abschließen:

1. Projektkontext erkunden – Dateien, Dokumentation, letzte Commits prüfen
2. Klärende Fragen stellen – Adaptive Bündelung: zusammenhängende Fragen gruppieren, um Roundtrips zu reduzieren; gezielte Einzelfragen für Nachfragen
3. 2–3 Ansätze vorschlagen – mit Vor- und Nachteilen und deiner Empfehlung
4. Design präsentieren – in Abschnitten, skaliert auf ihre Komplexität, nach jedem Abschnitt Benutzerfreigabe einholen
5. Designdokument schreiben – nach docs/plans/YYYY-MM-DD-<thema>-design.md speichern und committen
6. Zur Implementierung übergehen – die "Schreibpläne"-Fähigkeit aufrufen, um einen Implementierungsplan zu erstellen

Prozessablauf

digraph brainstorming {
    "Projektkontext erkunden" [shape=box];
    "Klärende Fragen stellen" [shape=box];
    "2–3 Ansätze vorschlagen" [shape=box];
    "Design-Abschnitte präsentieren" [shape=box];
    "Benutzer genehmigt Design?" [shape=diamond];
    "Designdokument schreiben" [shape=box];
    ""Schreibpläne"-Fähigkeit aufrufen" [shape=doublecircle];

    "Projektkontext erkunden" -> "Klärende Fragen stellen";
    "Klärende Fragen stellen" -> "2–3 Ansätze vorschlagen";
    "2–3 Ansätze vorschlagen" -> "Design-Abschnitte präsentieren";
    "Design-Abschnitte präsentieren" -> "Benutzer genehmigt Design?";
    "Benutzer genehmigt Design?" -> "Design-Abschnitte präsentieren" [label="nein, überarbeiten"];
    "Benutzer genehmigt Design?" -> "Designdokument schreiben" [label="ja"];
    "Designdokument schreiben" -> ""Schreibpläne"-Fähigkeit aufrufen";
}

Der Endzustand ist das Aufrufen von "Schreibpläne". Rufe NICHT "Frontend-Design", "MCP-Builder" oder eine andere Implementierungsfähigkeit auf. Die EINZIGE Fähigkeit, die du nach dem Brainstorming aufrufst, ist "Schreibpläne".

Der Prozess

Die Idee verstehen:

• Überprüfe zuerst den aktuellen Projektzustand (Dateien, Dokumentation, letzte Commits)

• Stelle Fragen mittels adaptiver Bündelung – gruppiere zusammenhängende Fragen, um Roundtrips zu reduzieren:

  • Erste Bündelung: umfasst Zweck, Einschränkungen, Umfang und Technologieentscheidungen
  • Nachfragen: Gezielte Einzelfragen basierend auf interessanten oder mehrdeutigen Antworten

  <host: claude-code>

  • Verwende wenn möglich Multiple-Choice-Optionen (AskUserQuestion unterstützt 2–4 Optionen pro Frage)
  • AskUserQuestion unterstützt bis zu 4 Fragen pro Formular – nutze dies, um Roundtrips zu reduzieren

  <host: codex, opencode, cursor>

  • Präsentiere Optionen als nummerierte Liste und bitte den Benutzer, mit der gewählten Nummer zu antworten
  • Gruppiere nicht mehr als 3 Fragen pro Durchgang, um den Chat nicht zu überlasten

• Konzentriere dich auf das Verständnis: Zweck, Einschränkungen, Erfolgskriterien

Ansätze erkunden:

• Schlage 2–3 verschiedene Ansätze mit Vor- und Nachteilen vor
• Präsentiere Optionen im Gesprächston mit deiner Empfehlung und Begründung
• Beginne mit deiner empfohlenen Option und erkläre warum

Das Design präsentieren:

• Sobald du glaubst zu verstehen, was du baust, präsentiere das Design
• Skaliere jeden Abschnitt entsprechend seiner Komplexität: ein paar Sätze bei Einfachheit, bis zu 200–300 Wörter bei Nuancen
• Frage nach jedem Abschnitt, ob er bisher richtig aussieht
• Behandle: Architektur, Komponenten, Datenfluss, Fehlerbehandlung, Tests
• Sei bereit, zurückzugehen und zu klären, wenn etwas keinen Sinn ergibt

Nur-Design-Modus

Wenn der Benutzer Design-Exploration ohne Ausführung wünscht, übergibt er --design-only an das Brainstorming.

Verhalten unter --design-only:

1. Führe den vollständigen Brainstorming-Ablauf aus (Kontext erkunden → Fragen → Ansätze → Design → Designdokument schreiben → committen).
2. Gib beim Aufrufen von "Schreibpläne" das Flag --design-only weiter.
3. "Schreibpläne" beachtet das Flag: Ausrichtungsprüfung BESTANDEN → STOPP (keine Ausführung gestartet). Bei Ausrichtungsprüfung NICHT BESTANDEN überarbeitet "Schreibpläne" und prüft erneut gemäß seiner normalen Fehlerbehandlung, stoppt dann – es wird dennoch keine Ausführung gestartet. Bei anhaltendem Fehlschlag (nach max. 2 Überarbeitungszyklen) eskalieren an den Benutzer mit einer Zusammenfassung der ungelösten Abweichung – es wird in keinem Fall eine Ausführung gestartet.
4. Der Pipeline endet mit einem committierten Designdokument + Plan in docs/plans/.

Standard (kein Flag): Brainstorming → "Schreibpläne" → Ausrichtungsprüfung → Subagenten-getriebene Entwicklung → … (autonome Übergabe an die Ausführung).

Nach dem Design

Dokumentation:

• Schreibe das validierte Design nach docs/plans/YYYY-MM-DD-<thema>-design.md
• Verwende die Fähigkeit "Elemente des Stils: klar und prägnant schreiben", falls verfügbar
• Committe das Designdokument in Git

Autonome Übergabe:

• Dies ist der letzte Interaktionspunkt des Benutzers – alles danach läuft autonom
• Rufe die "Schreibpläne"-Fähigkeit mit autonomen Kontext auf: das Design ist genehmigt, keine weitere Benutzereingabe erforderlich
• Die "Schreibpläne"-Fähigkeit bevorzugt den Plan-Modus von Claude (Claude Code), falls verfügbar, und fällt in anderen Umgebungen auf seinen integrierten Planungsprozess zurück
• Die Pipeline ab hier: "Schreibpläne" → Ausrichtungsprüfung → Teamausführung → PR-Erstellung → PR-Überwachung
• Rufe KEINE andere Fähigkeit auf. "Schreibpläne" ist der nächste Schritt. Es kümmert sich um den Rest der autonomen Pipeline.

Schlüsselprinzipien

• Adaptive Fragenbündelung – Gruppiere zusammenhängende Fragen, um Roundtrips zu reduzieren; verwende gezielte Einzelfragen für Nachfragen
• Multiple Choice bevorzugt – Einfacher zu beantworten als offene Fragen, wenn möglich
• YAGNI rigoros – Entferne unnötige Funktionen aus allen Designs
• Alternativen erkunden – Schlage immer 2–3 Ansätze vor, bevor du dich festlegst
• Inkrementelle Validierung – Präsentiere das Design, hole die Freigabe ein, bevor es weitergeht
• Sei flexibel – Gehe zurück und kläre, wenn etwas keinen Sinn ergibt
• Designfreigabe = Autonomieübergabe – Nach der Designfreigabe läuft die Pipeline ohne Benutzereingabe