Brainstorming Von Ideen zu Entwürfen

Helfen Sie dabei, Ideen durch einen natürlichen, kooperativen Dialog in ausgereifte Entwürfe und Spezifikationen umzusetzen.

Beginnen Sie damit, den aktuellen Projektkontext zu verstehen, und stellen Sie dann nacheinander Fragen, um die Idee zu verfeinern. Sobald Sie verstanden haben, was Sie entwickeln, präsentieren Sie das Design und holen Sie die Zustimmung der Nutzer ein.

Anti-Muster: „Das ist zu einfach, um einen Entwurf zu benötigen“

Jedes Projekt durchläuft diesen Prozess. Eine To-do-Liste, ein Dienstprogramm mit einer einzigen Funktion, eine Konfigurationsänderung – alles. Gerade bei „einfachen“ Projekten verursachen unhinterfragte Annahmen den größten Arbeitsaufwand. Der Entwurf kann kurz sein (ein paar Sätze bei wirklich einfachen Projekten), aber du MUSST ihn präsentieren und die Zustimmung einholen.

Checkliste

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

1. Projektkontext erkunden – Dateien, Dokumente und aktuelle Commits prüfen
2. Biete den visuellen Begleiter „just-in-time“ an – NICHT im Voraus. Sobald eine Frage zum ersten Mal auftaucht, bei der eine visuelle Darstellung tatsächlich klarer wäre als eine Beschreibung, biete ihn dann an (in einer eigenen Meldung); nach der Genehmigung öffnet sich der entsprechende Browser-Tab für dich. Wenn sich nie eine visuelle Frage ergibt, biete ihn niemals an. Siehe den Abschnitt „Visueller Begleiter“ weiter unten.
3. Stellen Sie klärende Fragen – jeweils eine nach der anderen, um Zweck, Einschränkungen und Erfolgskriterien zu verstehen
4. Schlagen Sie 2–3 Ansätze vor – mit Vor- und Nachteilen sowie Ihrer Empfehlung
5. Präsentieren Sie das Design – in Abschnitten, die der jeweiligen Komplexität angepasst sind; holen Sie nach jedem Abschnitt die Zustimmung des Nutzers ein
6. Erstellen Sie ein Design-Dokument – speichern Sie es unter „docs/superpowers/specs/YYYY-MM-DD--design.md“ und committen Sie es
7. Selbstprüfung der Spezifikation – kurze Inline-Prüfung auf Platzhalter, Widersprüche, Mehrdeutigkeiten und Umfang (siehe unten)
8. Benutzer überprüft die geschriebene Spezifikation – bitte den Benutzer, die Spezifikationsdatei zu überprüfen, bevor du fortfährst
9. Übergang zur Umsetzung – die „Writing-Plans“-Fähigkeit nutzen, um einen Umsetzungsplan zu erstellen

Prozessablauf

digraph brainstorming {
    "Projektkontext erkunden" [shape=box];
    "Klärende Fragen stellen" [shape=box];
    "2–3 Ansätze vorschlagen" [shape=box];
    „Entwurfsabschnitte präsentieren“ [shape=box];
    „Nutzer genehmigt den Entwurf?“ [shape=diamond];
    „Entwurfsdokument verfassen“ [shape=box];
    „Spezifikation selbst überprüfen\n(Inline korrigieren)“ [shape=box];
    „Überprüft der Nutzer die Spezifikation?“ [shape=diamond];
    „Fähigkeit ‚Schreibpläne erstellen‘ aufrufen“ [shape=doublecircle];

    „Projektkontext erkunden“ -> „Klärende Fragen stellen“;
    „Klärende Fragen stellen“ -> „2–3 Ansätze vorschlagen“;
    „2–3 Ansätze vorschlagen“ -> „Entwurfsabschnitte präsentieren“;
    „Entwurfsabschnitte präsentieren“ -> „Genehmigt der Nutzer den Entwurf?“;
    „Genehmigt der Nutzer den Entwurf?“ -> „Entwurfsabschnitte präsentieren“ [label="nein, überarbeiten"];
    „Genehmigt der Nutzer den Entwurf?“ -> „Entwurfsdokument verfassen“ [label="ja"];
    „Entwurfsdokument verfassen“ -> „Spezifikation selbst überprüfen\n(Korrekturen direkt einfügen)“;
    „Spezifikation selbst überprüfen\n(Korrekturen direkt einfügen)“ -> „Prüft der Nutzer die Spezifikation?“;
    „Überprüft der Benutzer die Spezifikation?“ -> „Designdokument verfassen“ [label="Änderungen angefordert"];
    „Überprüft der Benutzer die Spezifikation?“ -> „Skill ‚writing-plans‘ aufrufen“ [label="genehmigt"];
}

Der Endzustand ist der Aufruf von „writing-plans“. Rufen Sie NICHT „frontend-design“, „mcp-builder“ oder irgendeine andere Implementierungs-Skill auf. Die EINZIGE Skill, die Sie nach „ brainstorming “ aufrufen, ist „writing-plans“.

Der Prozess

Das Konzept verstehen:

• Überprüfen Sie zunächst den aktuellen Projektstatus (Dateien, Dokumente, letzte Commits)
• Bevor du detaillierte Fragen stellst, schätze den Umfang ein: Wenn die Anfrage mehrere unabhängige Teilsysteme beschreibt (z. B. „Erstelle eine Plattform mit Chat, Dateispeicher, Abrechnung und Analytik“), weise sofort darauf hin. Verbringe keine Zeit damit, Details eines Projekts zu ergründen, das zunächst zerlegt werden muss.
• Wenn das Projekt für eine einzelne Spezifikation zu groß ist, helfen Sie dem Nutzer, es in Teilprojekte zu zerlegen: Was sind die unabhängigen Teile, wie hängen sie zusammen, in welcher Reihenfolge sollten sie umgesetzt werden? Führen Sie dann für das erste Teilprojekt ein Brainstorming im Rahmen des normalen Design-Ablaufs durch. Jedes Teilprojekt durchläuft seinen eigenen Zyklus aus Spezifikation → Planung → Umsetzung.
• Bei Projekten mit angemessenem Umfang stellen Sie jeweils eine Frage nach der anderen, um die Idee zu verfeinern
• Bevorzugen Sie nach Möglichkeit Multiple-Choice-Fragen, aber offene Fragen sind ebenfalls in Ordnung
• Nur eine Frage pro Nachricht – wenn ein Thema näher beleuchtet werden muss, teilen Sie es in mehrere Fragen auf
• Konzentrieren Sie sich auf das Verständnis: Zweck, Einschränkungen, Erfolgskriterien

Ansätze ausloten:

• Schlagen Sie 2–3 verschiedene Ansätze mit ihren jeweiligen Vor- und Nachteilen vor
• Stellen Sie die Optionen im Gespräch vor und nennen Sie dabei Ihre Empfehlung und die Begründung
• Stellen Sie Ihre empfohlene Option an den Anfang und erklären Sie, warum

Präsentation des Entwurfs:

• Sobald Sie der Meinung sind, dass Sie verstanden haben, was Sie entwickeln, präsentieren Sie den Entwurf
• Passen Sie die Länge jedes Abschnitts an dessen Komplexität an: ein paar Sätze, wenn es einfach ist, bis zu 200–300 Wörter, wenn es nuanciert ist
• Fragen Sie nach jedem Abschnitt, ob es bisher richtig aussieht
• Behandeln Sie folgende Themen: Architektur, Komponenten, Datenfluss, Fehlerbehandlung, Tests
• Seien Sie bereit, zurückzugehen und Dinge zu klären, falls etwas nicht einleuchtet

Entwerfen Sie mit Blick auf Isolation und Klarheit:

• Teilen Sie das System in kleinere Einheiten auf, die jeweils einen klaren Zweck haben, über klar definierte Schnittstellen kommunizieren und unabhängig voneinander verstanden und getestet werden können
• Für jede Einheit sollten Sie folgende Fragen beantworten können: Was macht sie, wie wird sie verwendet und wovon hängt sie ab?
• Kann jemand verstehen, was eine Einheit tut, ohne ihre internen Abläufe zu lesen? Kannst du die internen Abläufe ändern, ohne dass die Verbraucher davon beeinträchtigt werden? Wenn nicht, müssen die Abgrenzungen überarbeitet werden.
• Kleinere, klar abgegrenzte Einheiten lassen sich zudem leichter bearbeiten – man kann Code besser nachvollziehen, wenn man den gesamten Kontext auf einen Blick erfassen kann, und Änderungen sind zuverlässiger, wenn Dateien fokussiert sind. Wenn eine Datei zu groß wird, ist das oft ein Zeichen dafür, dass sie zu viele Aufgaben erfüllt.

Arbeiten in bestehenden Codebasen:

• Mache dich mit der aktuellen Struktur vertraut, bevor du Änderungen vorschlägst. Halte dich an bestehende Muster.
• Wenn bestehender Code Probleme aufweist, die die Arbeit beeinträchtigen (z. B. eine zu groß gewordene Datei, unklare Abgrenzungen, verworrenen Zuständigkeiten), beziehe gezielte Verbesserungen in den Entwurf ein – so wie ein guter Entwickler den Code verbessert, an dem er arbeitet.
• Schlagen Sie keine Refactorings vor, die in keinem Zusammenhang stehen. Konzentrieren Sie sich darauf, was dem aktuellen Ziel dient.

Nach dem Design

Dokumentation:

• Schreiben Sie das validierte Design (Spezifikation) in die Datei „docs/superpowers/specs/YYYY-MM-DD--design.md“
  • (Benutzereinstellungen für den Speicherort der Spezifikation haben Vorrang vor dieser Standardeinstellung)
• Verwende die Fertigkeit „Elements of Style: Writing Clearly and Concisely“, sofern verfügbar
• Committe das Design-Dokument in Git

Selbstüberprüfung der Spezifikation: Betrachten Sie das Spezifikationsdokument nach dem Verfassen noch einmal mit unvoreingenommenem Blick:

1. Platzhalter-Check: Gibt es „TBD“, „TODO“, unvollständige Abschnitte oder vage Anforderungen? Korrigieren Sie diese.
2. Interne Konsistenz: Widersprechen sich Abschnitte? Stimmt die Architektur mit den Funktionsbeschreibungen überein?
3. Umfangsprüfung: Istder Umfang für einen einzigen Implementierungsplan ausreichend fokussiert oder muss er aufgeschlüsselt werden?
4. Überprüfung auf Mehrdeutigkeit: Könnte eine Anforderung auf zwei verschiedene Arten interpretiert werden? Wenn ja, wähle eine aus und formuliere sie eindeutig.

Beheben Sie etwaige Probleme direkt im Text. Eine erneute Überprüfung ist nicht erforderlich – einfach korrigieren und weitermachen.

Benutzer-Review-Gate: Nachdem der Spezifikations-Review-Zyklus abgeschlossen ist, bitten Sie den Benutzer, die schriftliche Spezifikation zu überprüfen, bevor Sie fortfahren:

„Die Spezifikation ist geschrieben und in . Bitte prüfe sie und lass mich wissen, ob du Änderungen vornehmen möchtest, bevor wir mit der Erstellung des Implementierungsplans beginnen.“

Warten Sie auf die Antwort des Nutzers. Falls er Änderungen wünscht, nehmen Sie diese vor und wiederholen Sie den Spezifikationsprüfungszyklus. Fahren Sie erst fort, wenn der Nutzer seine Zustimmung erteilt hat.

Umsetzung:

• Rufen Sie die Skill „writing-plans“ auf, um einen detaillierten Umsetzungsplan zu erstellen
• Rufen Sie KEINE anderen Skills auf. „writing-plans“ ist der nächste Schritt.

Wichtige Grundsätze

• Jedes Mal nur eine Frage – Überfordern Sie den Nutzer nicht mit mehreren Fragen
• Vierfachauswahl bevorzugt – Wenn möglich, leichter zu beantworten als offene Fragen
• YAGNI konsequent anwenden – Entfernen Sie unnötige Funktionen aus allen Entwürfen
• Alternativen prüfen – Schlagen Sie immer 2–3 Ansätze vor, bevor Sie sich festlegen
• Schrittweise Validierung – Entwurf präsentieren, Zustimmung einholen, bevor man weitermacht
• Seid flexibel – Geht zurück und klärt Dinge, wenn etwas keinen Sinn ergibt

Visuelle Ergänzung

Ein browserbasiertes Hilfsmittel zur Darstellung von Mockups, Diagrammen und visuellen Optionen während des „ brainstorming “. Verfügbar als Tool – nicht als Modus. Die Nutzung des Hilfsmittels bedeutet, dass es für Fragen zur Verfügung steht, bei denen eine visuelle Darstellung von Vorteil ist; es bedeutet NICHT, dass jede Frage über den Browser abgewickelt wird.

Die Begleitfunktion anbieten (just-in-time): Bieten Sie sie NICHT von vornherein an. Warten Sie, bis eine Frage tatsächlich besser visuell dargestellt als verbal erklärt werden kann – eine echte Frage zu Mockups, Layouts oder Diagrammen, nicht nur ein UI-Thema. Wenn dies zum ersten Mal der Fall ist, bieten Sie sie dann als eigenständige Mitteilung an:

„Der nächste Teil wäre vielleicht einfacher, wenn ich es dir zeige – ich kann im Laufe des Gesprächs Mockups, Diagramme und Vergleiche in einem Browser-Tab zusammenstellen. Das ist noch neu und kann viele Tokens verbrauchen. Soll ich das tun? Ich öffne es für dich.“

Dieses Angebot MUSS eine eigenständige Nachricht sein. Nur das Angebot – keine klärende Frage, Zusammenfassung oder andere Inhalte. Warte auf die Antwort des Nutzers. Wenn er zustimmt, starte den Server mit „--open“, damit sich sein Browser automatisch auf dem ersten Bildschirm öffnet. Wenn er ablehnt, fahre nur mit Text fort und biete es nicht erneut an, es sei denn, er spricht es selbst an.

Entscheidung pro Frage: Auch nachdem der Nutzer zugestimmt hat, entscheide für JEDE EINZELNE FRAGE, ob der Browser oder das Terminal verwendet werden soll. Der Test: Würde der Nutzer dies besser verstehen, wenn er es sieht, anstatt es zu lesen?

• Verwenden Sie den Browser für Inhalte, die visuell sind – Mockups, Wireframes, Layout-Vergleiche, Architekturdiagramme, visuelle Entwürfe im Nebeneinander-Vergleich
• Verwenden Sie das Terminal für Inhalte, die aus Text bestehen – Fragen zu Anforderungen, konzeptionelle Entscheidungen, Abwägungslisten, A/B/C/D-Textoptionen, Entscheidungen zum Umfang

Eine Frage zu einem UI-Thema ist nicht automatisch eine visuelle Frage. „Was bedeutet ‚Persönlichkeit‘ in diesem Zusammenhang?“ ist eine konzeptionelle Frage – verwende das Terminal. „Welches Assistenten-Layout funktioniert besser?“ ist eine visuelle Frage – verwende den Browser.

Wenn sie dem Begleitmaterial zustimmen, lesen Sie bitte den ausführlichen Leitfaden, bevor Sie fortfahren: skills/brainstorming/visual-companion.md