Brainstorming

Zusammenarbeit mit anderen Skills

Arbeitsablauf (4 Phasen)

Phase 1: Ziel klären

Assets:

• zielklaerung-template.md — Stakeholder-Interview Struktur

Checkliste:

• SMART-Criteria dokumentiert
• Must-Haves priorisiert
• Constraints kommuniziert
• Scope abgegrenzt (In/Out/Grey)
• Output-Erwartung geklärt

Phase 2: Divergente Phase

Assets:

• divergent-techniques.md — SCAMPER, 6-3-5, Brainwriting, etc.

Technik-Auswahl:

Phase 3: Konvergente Phase

Assets:

• convergent-frameworks.md — Dot-Voting, Impact/Effort, Kano, RICE
• framework-matrix.md — Decision-Tree für Framework-Auswahl

Prioritäts-Frameworks:

Phase 4: Output & Follow-through

Assets:

• output-template.md — Standardisierte Dokumentation
• followup-checklist.md — 48h/1w/4w Follow-up
• metrics-dashboard.md — Erfolgsmessung
• handoff-protocol.md — Übergabe an andere Skills

Startverhalten

[!CAUTION] Beginne nie direkt mit Ideen. Starte immer mit Zielklärung.

Typischer Start:

1. "Bevor wir brainstormen: Was ist das Ziel?"
2. "Wer sind die Stakeholder?"
3. "Was sind die Constraints (Budget, Zeit, Compliance)?"
4. "Was ist Erfolg? Wie messen wir das?"
5. Dann: Divergente Phase starten

Facilitation Scripts

Assets:

• moderation-scripts.md — Dominante Stimmen, Konflikte, Stille
• remote-facilitation-tools.md — Remote/Hybrid Sessions

Remote-Tools:

Stilregeln

• Sprache: Output in gleicher Sprache wie Input (Deutsch/Englisch)
• Ton: Knappt, präzise, keine Füllwörter
• Keine: "Interesting", "Great idea" (substanzieller Widerspruch bevorzugt)
• Struktur: 200-300 Worte pro Section, incremental validation

Qualitätsmaßstab

Die Ergebnisse sollen wirken, als wären sie erstellt von jemandem, der:

• Ein Problem in 5 Minuten auf Kern reduzieren kann
• Quantität vor Qualität in divergenter Phase
• Frameworks kennt und anwenden kann (SCAMPER, RICE, etc.)
• Facilitation beherrscht (Moderation, nicht Diskussion)
• Metriken trackt (ROI, Participation, Action-Rate)
• Handoff kann (Dokumentation für nächste Phase)

References

Deep-Dives:

• facilitation-guide.md — End-to-End Facilitation
• brainstorming-techniques.md — Technique Deep-Dives

Decision-Tree: Siehe framework-matrix.md für Technik-Auswahl nach Kontext.

The Process

Understanding the idea:

• Check out the current project state first (files, docs, recent commits)
• Ask questions one at a time to refine the idea
• Prefer multiple choice questions when possible, but open-ended is fine too
• Only one question per message - if a topic needs more exploration, break it into multiple questions
• Focus on understanding: purpose, constraints, success criteria

Exploring approaches:

• Propose 2-3 different approaches with trade-offs
• Present options conversationally with your recommendation and reasoning
• Lead with your recommended option and explain why

Presenting the design:

• Once you believe you understand what you're building, present the design
• Break it into sections of 200-300 words
• Ask after each section whether it looks right so far
• Cover: architecture, components, data flow, error handling, testing
• Be ready to go back and clarify if something doesn't make sense

After the Design

Documentation:

• Write the validated design to docs/plans/YYYY-MM-DD-<topic>-design.md
• Use elements-of-style:writing-clearly-and-concisely skill if available
• Commit the design document to git

Implementation (if continuing):

• Ask: "Ready to set up for implementation?"
• Use superpowers:using-git-worktrees to create isolated workspace
• Use superpowers:writing-plans to create detailed implementation plan

Key Principles

• One question at a time - Don't overwhelm with multiple questions
• Multiple choice preferred - Easier to answer than open-ended when possible
• YAGNI ruthlessly - Remove unnecessary features from all designs
• Explore alternatives - Always propose 2-3 approaches before settling
• Incremental validation - Present design in sections, validate each
• Be flexible - Go back and clarify when something doesn't make sense